Newest at the top
| 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 |
| 2024-11-01 21:12:25 +0100 | <monochrom> | OK OK this one is "... seq x" so yeah you're right. |
| 2024-11-01 21:12:11 +0100 | <EvanR> | foo and bar are the same object in this case |
| 2024-11-01 21:11:59 +0100 | <tomsmeding> | mind that this is evaluate, hence seq#, not seq -- not sure if that matters |
| 2024-11-01 21:11:56 +0100 | <monochrom> | "foo seq bar" returns a pointer to bar but not foo. |
| 2024-11-01 21:11:44 +0100 | <EvanR> | yes it's cheap but you can't have discarded the entire thing prior to the simple check |
| 2024-11-01 21:11:34 +0100 | <tomsmeding> | monochrom: sure, but does not keep a reference to the value? |
| 2024-11-01 21:11:12 +0100 | <monochrom> | Nah the extra seq is at worst just an extra check "oh this is already a value, moving on". |
| 2024-11-01 21:11:00 +0100 | <tomsmeding> | zzz: can you reproduce the difference between 1 and 2 with my code? |
| 2024-11-01 21:10:48 +0100 | <tomsmeding> | zzz: that's version 3 explained |
| 2024-11-01 21:10:38 +0100 | <tomsmeding> | hence the memory use |
| 2024-11-01 21:10:34 +0100 | <tomsmeding> | that's... a fair point: you have to hold on to the root of the data structure to WHNF it |
| 2024-11-01 21:10:23 +0100 | <EvanR> | meanwhile it's being deepseqqed |
| 2024-11-01 21:10:13 +0100 | <EvanR> | sure but it means you have to still have it when it's time to do that |
| 2024-11-01 21:09:59 +0100 | <tomsmeding> | 'evaluate' only does WHNF |
| 2024-11-01 21:09:44 +0100 | <EvanR> | force x = x `deepseq` x = rnf x `seq` x. So 'evaluate'ing force something involves evaluating something to some extent twice |
| 2024-11-01 21:08:53 +0100 | <zzz> | ah ok |