Newest at the top
| 2024-11-01 21:31:02 +0100 | <zzz> | y |
| 2024-11-01 21:30:48 +0100 | todi | (~todi@p57803331.dip0.t-ipconnect.de) todi |
| 2024-11-01 21:30:41 +0100 | merijn | (~merijn@128-137-045-062.dynamic.caiway.nl) (Ping timeout: 248 seconds) |
| 2024-11-01 21:30:17 +0100 | <tomsmeding> | can you try my last paste? |
| 2024-11-01 21:29:56 +0100 | <zzz> | i consistently get better results for compiled rnf |
| 2024-11-01 21:29:29 +0100 | <zzz> | one file for each version |
| 2024-11-01 21:29:28 +0100 | <tomsmeding> | zzz: https://paste.tomsmeding.com/WGmJJRuD |
| 2024-11-01 21:29:12 +0100 | <zzz> | tomsmeding: oh, i did that so i could easily share it. i ran separate files |
| 2024-11-01 21:28:52 +0100 | <monochrom> | That is strange. |
| 2024-11-01 21:28:26 +0100 | <tomsmeding> | are you perhaps testing one version with it all in one file and one version split over multiple files? |
| 2024-11-01 21:28:08 +0100 | <tomsmeding> | zzz: if I compile your code as-is (but do put it all in one file), I get similar timings too |
| 2024-11-01 21:27:47 +0100 | <zzz> | monochrom: 8GB Ram :) |
| 2024-11-01 21:26:57 +0100 | <monochrom> | OK I'll stop until I think up a better joke! |
| 2024-11-01 21:26:18 +0100 | <monochrom> | What if the web browser already eats up 0.4999GB and the OS eats up the rest :) |
| 2024-11-01 21:25:47 +0100 | <zzz> | tomsmeding: i don't understand why in your test the difference between deepseq and rnf disappears |
| 2024-11-01 21:25:10 +0100 | <tomsmeding> | case 1 and 2 run lean |
| 2024-11-01 21:25:06 +0100 | <tomsmeding> | monochrom: that would be for case 3 only |
| 2024-11-01 21:24:54 +0100 | <EvanR> | intel celery |
| 2024-11-01 21:24:48 +0100 | <monochrom> | OK now I'm hoping "oh it only has 0.5GB RAM so yeah it's thrashing" |
| 2024-11-01 21:24:26 +0100 | <tomsmeding> | but yeah with a CPU of that class I would not expect a 7x difference, but I guess it could be |
| 2024-11-01 21:24:20 +0100 | <zzz> | 4 cores |
| 2024-11-01 21:24:12 +0100 | <zzz> | plugged in, not sure if it's throttling |
| 2024-11-01 21:23:38 +0100 | <tomsmeding> | that can still mean various CPUs it seems |
| 2024-11-01 21:23:36 +0100 | <EvanR> | "did you check if it's plugged in" |
| 2024-11-01 21:22:54 +0100 | <zzz> | HP ProBook 440 G4 |
| 2024-11-01 21:22:23 +0100 | <zzz> | tomsmeding: not sure, it's not mine. sec |
| 2024-11-01 21:21:52 +0100 | <monochrom> | I was hoping "brand new laptop using the brand new intel lake cpus so yeah it's a well-known regression" >:)\ |
| 2024-11-01 21:21:36 +0100 | <tomsmeding> | O.o |
| 2024-11-01 21:21:24 +0100 | <dolio> | I was helping someone out a week or so ago, and they were doing something on their laptop, and my 10 year old desktop might have been that much faster when I tried it. |
| 2024-11-01 21:21:18 +0100 | <tomsmeding> | what model number? |
| 2024-11-01 21:21:08 +0100 | <zzz> | tomsmeding: old hp laptop, core i5 7th gen |
| 2024-11-01 21:20:45 +0100 | <tomsmeding> | zzz: if it's a laptop, are you sure it's not throttling? Is the power cable attached? If it's intel, is turbo boost enabled and does the cpu reach similar frequencies for both tests? |
| 2024-11-01 21:20:19 +0100 | <dolio> | I don't know about that. |
| 2024-11-01 21:20:03 +0100 | <tomsmeding> | my CPU is like 7x as fast as yours? That feels unlikely |
| 2024-11-01 21:19:44 +0100 | <tomsmeding> | okay so they are at least the same but 1. why are they slower than your code, and 2. what CPU is that, I know mine is fairly fast but _this_ fast? |
| 2024-11-01 21:19:09 +0100 | <zzz> | Range (min … max): 4.137 s … 4.276 s 10 runs |
| 2024-11-01 21:19:06 +0100 | <zzz> | Time (mean ± σ): 4.208 s ± 0.048 s [User: 4.195 s, System: 0.006 s] |
| 2024-11-01 21:19:04 +0100 | <zzz> | Benchmark 2: ./hs/test 2 |
| 2024-11-01 21:18:59 +0100 | <zzz> | Range (min … max): 4.106 s … 4.249 s 10 runs |
| 2024-11-01 21:18:56 +0100 | <zzz> | Time (mean ± σ): 4.171 s ± 0.038 s [User: 4.115 s, System: 0.051 s] |
| 2024-11-01 21:18:56 +0100 | <zzz> | Benchmark 1: ./hs/test 1 |
| 2024-11-01 21:18:41 +0100 | <zzz> | tomsmeding: |
| 2024-11-01 21:17:35 +0100 | <haskellbridge> | <zwro> "the problem with common sense is that it's not common at all" — someone |
| 2024-11-01 21:16:46 +0100 | <monochrom> | Stepping back a step, people even hold opposite opinions on whether you should let GHC optimize or you should distrust GHC and optimize by hand. |
| 2024-11-01 21:15:30 +0100 | <monochrom> | GHC out-smarts common sense in some cases and defies common senses in some others. Also people hold opposite "common" senses. |
| 2024-11-01 21:13:46 +0100 | <dolio> | evaluate returns the value it evaluates, too. |
| 2024-11-01 21:13:38 +0100 | <EvanR> | like scanl with tuples |
| 2024-11-01 21:13:34 +0100 | <tomsmeding> | we're talking maximum residency of 2 GB and productivity of <25%, versus maximum residency of 40KB and productivity >99% |
| 2024-11-01 21:13:27 +0100 | <EvanR> | it's a situation like this that I half expect ghc to pull some kind of magic and be efficient regardless of common sense |
| 2024-11-01 21:12:56 +0100 | <tomsmeding> | monochrom: and if it really doesn't matter, then how do you explain 'evaluate (force x) >> pure ()' taking more than 4x as long as 'evaluate (rnf x)' and thrashing the GC meanwhile? :p |