Newest at the top
2025-02-26 12:59:57 +0100 | <Athas> | If gradbench handled the OOM a little more gracefully, then I'd prefer this solution. It looks nice. |
2025-02-26 12:58:34 +0100 | <Athas> | A little more than 2x. |
2025-02-26 12:58:16 +0100 | <Athas> | But it's certainly a lot faster. |
2025-02-26 12:58:06 +0100 | <Athas> | Yeah, it OOM'ed again. |
2025-02-26 12:57:54 +0100 | <tomsmeding> | except that hessianProduct also doesn't use ReverseDouble! |
2025-02-26 12:57:49 +0100 | <Athas> | Memory usage isn't promising. |
2025-02-26 12:57:36 +0100 | <tomsmeding> | so this seems consistent, to me |
2025-02-26 12:57:10 +0100 | <tomsmeding> | the FFI code is specifically for ReverseDouble; I guess `Reverse s SparseDouble` only benefits from being specialised to Double in Haskell-land, not fro mthe FFI code |
2025-02-26 12:56:26 +0100 | <tomsmeding> | oh I guess `hessian'` |
2025-02-26 12:55:56 +0100 | <Athas> | We'll see if the memory issue has also been solved. |
2025-02-26 12:55:49 +0100 | <Athas> | The commented-out code seems to perform quite OK now: https://github.com/gradbench/gradbench/blob/main/tools/haskell/src/GradBench/KMeans.hs#L78-L95 |
2025-02-26 12:55:46 +0100 | <tomsmeding> | *faster |
2025-02-26 12:55:42 +0100 | <tomsmeding> | What function from Numeric.AD.Double aer you using in the version that doesn't get vaster? |
2025-02-26 12:55:28 +0100 | <tomsmeding> | interesting! |
2025-02-26 12:55:14 +0100 | <Athas> | When I use that version, I do see significant speedup with +ffi. |
2025-02-26 12:55:13 +0100 | <tomsmeding> | something something hessian jacobian product? |
2025-02-26 12:55:02 +0100 | <Athas> | But now I have an interesting result. Do you remember I had a version that "ought" to be faster, but wasn't? |
2025-02-26 12:54:58 +0100 | <tomsmeding> | the whole point of Numeric.AD.Double is that it optimises the `Reverse s Double` case |
2025-02-26 12:54:58 +0100 | Googulator78 | (~Googulato@2a01-036d-0106-0c81-ad7c-ac56-196b-c9a2.pool6.digikabel.hu) |
2025-02-26 12:54:51 +0100 | <Athas> | tomsmeding: yes, but I'm just using a single exported function from Numeric.AD.Double. |
2025-02-26 12:54:44 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-02-26 12:54:36 +0100 | Googulator78 | (~Googulato@2a01-036d-0106-0c81-ad7c-ac56-196b-c9a2.pool6.digikabel.hu) (Quit: Client closed) |
2025-02-26 12:54:33 +0100 | <tomsmeding> | Athas: aren't you doing reverse-then-forward in kmeans? i.e. your reverse mode is not actually on Doubles, but on dual numbers? |
2025-02-26 12:53:53 +0100 | <Athas> | Oh, this is interesting. I don't see tape_backPropagate when I use Numeric.AD.Double in my kmeans implementation, but I do see it when I use it for the dummy 'hello' benchmark. |
2025-02-26 12:53:45 +0100 | <tomsmeding> | well, I put a newline and an indent after the `:`, but otherwise, yes, that's exactly what I did |
2025-02-26 12:52:30 +0100 | alfiee | (~alfiee@user/alfiee) (Ping timeout: 244 seconds) |
2025-02-26 12:52:29 +0100 | <Athas> | And 'constraints: ad +ffi' in my cabal.project is enough? |
2025-02-26 12:52:10 +0100 | LainExperiments2 | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
2025-02-26 12:51:50 +0100 | <tomsmeding> | it worked for me! |
2025-02-26 12:51:42 +0100 | <Athas> | I assume cabal's logic for recompiling dependencies on flag changes is sound, right? |
2025-02-26 12:51:19 +0100 | <Athas> | It does not. |
2025-02-26 12:50:53 +0100 | <tomsmeding> | that distinguishes between an ad +ffi and an ad -ffi build for me |
2025-02-26 12:50:21 +0100 | <tomsmeding> | Athas: if you `nm` your executable, does it reference `tape_backPropagate`? |
2025-02-26 12:49:40 +0100 | LainExperiments3 | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
2025-02-26 12:48:28 +0100 | alfiee | (~alfiee@user/alfiee) alfiee |
2025-02-26 12:46:39 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
2025-02-26 12:46:27 +0100 | <Athas> | tomsmeding: I don't see any difference, but perhaps I am holding it wrong. |
2025-02-26 12:44:40 +0100 | LainExperiments | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
2025-02-26 12:44:20 +0100 | LainExperiments2 | (~LainExper@user/LainExperiments) LainExperiments |
2025-02-26 12:43:10 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 272 seconds) |
2025-02-26 12:41:24 +0100 | LainExperiments3 | (~LainExper@user/LainExperiments) LainExperiments |
2025-02-26 12:33:48 +0100 | plitter | (~plitter@user/plitter) plitter |
2025-02-26 12:33:00 +0100 | merijn | (~merijn@77.242.116.146) merijn |
2025-02-26 12:31:01 +0100 | Everything | (~Everythin@46.211.65.235) (Ping timeout: 248 seconds) |
2025-02-26 12:27:28 +0100 | xff0x | (~xff0x@2405:6580:b080:900:17f4:b7d4:84ba:3a30) (Ping timeout: 245 seconds) |
2025-02-26 12:23:10 +0100 | LainExperiments4 | (~LainExper@user/LainExperiments) (Ping timeout: 240 seconds) |
2025-02-26 12:20:18 +0100 | LainExperiments | (~LainExper@user/LainExperiments) LainExperiments |
2025-02-26 12:20:17 +0100 | merijn | (~merijn@77.242.116.146) (Ping timeout: 252 seconds) |
2025-02-26 12:15:23 +0100 | Digit | (~user@user/digit) (Ping timeout: 245 seconds) |
2025-02-26 12:12:53 +0100 | Digitteknohippie | (~user@user/digit) Digit |