Logs: freenode/#haskell
| 2021-03-04 19:54:27 | <monochrom> | But you could argue that CJK evolved from pictures. |
| 2021-03-04 19:54:59 | × | chenshen quits (~chenshen@2620:10d:c090:400::5:dc3c) (Quit: My MacBook Pro has gone to sleep. ZZZzzz…) |
| 2021-03-04 19:55:07 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2021-03-04 19:57:21 | × | pfurla_ quits (~pfurla@ool-182ed2e2.dyn.optonline.net) (Quit: gone to sleep. ZZZzzz…) |
| 2021-03-04 19:57:51 | → | bodisiw joins (~bodiskw@cpe-74-138-114-237.kya.res.rr.com) |
| 2021-03-04 20:00:30 | → | chenshen joins (~chenshen@2620:10d:c090:400::5:dc3c) |
| 2021-03-04 20:01:09 | × | Boomerang quits (~Boomerang@2a05:f6c7:2179:0:64:db14:2c3a:3ba3) (Remote host closed the connection) |
| 2021-03-04 20:02:48 | <rednaZ[m]> | Thanks koz_ and tomsmeding . Interesting how you treat the "because". tomsmeding switches the order so he can make to sentences using "Therefore" which is allowed to start a sentence while "because" is apparently not, which is weird, is it not? koz_ simply drops "because". |
| 2021-03-04 20:03:33 | <koz_> | The thing is, the whole 'never start a sentence with because' is a pointless rule. |
| 2021-03-04 20:03:36 | <tomsmeding> | rednaZ[m]: "Because of that, ..." |
| 2021-03-04 20:03:40 | <koz_> | In this case, however, you need no conjunction anyway. |
| 2021-03-04 20:03:42 | <dolio> | You can start a sentence with, "because," but it means something different than, "therefore." |
| 2021-03-04 20:03:45 | × | bodisiw quits (~bodiskw@cpe-74-138-114-237.kya.res.rr.com) (Quit: Leaving) |
| 2021-03-04 20:03:50 | → | raehik joins (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) |
| 2021-03-04 20:03:51 | <koz_> | Because it's rather clear what the connection between those sentences is. |
| 2021-03-04 20:04:17 | <rednaZ[m]> | tomsmeding: That is just another way of saying "Therefore". |
| 2021-03-04 20:04:20 | <rednaZ[m]> | xD |
| 2021-03-04 20:04:28 | <tomsmeding> | of course :p |
| 2021-03-04 20:05:19 | → | o1lo01ol1o joins (~o1lo01ol1@bl11-140-216.dsl.telepac.pt) |
| 2021-03-04 20:05:21 | × | petersen quits (~petersen@redhat/juhp) (Ping timeout: 264 seconds) |
| 2021-03-04 20:05:38 | <dolio> | Basically, if you start a sentence with, "because," you are just switching the order of conjoined clauses in the sentence. |
| 2021-03-04 20:05:45 | → | Franciman joins (~francesco@host-82-49-79-189.retail.telecomitalia.it) |
| 2021-03-04 20:06:30 | → | pera joins (~pera@unaffiliated/pera) |
| 2021-03-04 20:06:58 | → | kiweun joins (~kiweun@dsl-173-206-6-91.tor.primus.ca) |
| 2021-03-04 20:07:07 | → | petersen joins (~petersen@redhat/juhp) |
| 2021-03-04 20:07:16 | × | Mrbuck quits (~Mrbuck@gateway/tor-sasl/mrbuck) (Quit: WeeChat 1.9.1) |
| 2021-03-04 20:07:40 | → | howdoi joins (uid224@gateway/web/irccloud.com/x-bgmkvjlbzdbxvlqi) |
| 2021-03-04 20:10:10 | <rednaZ[m]> | koz_: I think, you have got a good point. |
| 2021-03-04 20:10:41 | → | gitgood joins (~gitgood@82-132-217-85.dab.02.net) |
| 2021-03-04 20:11:00 | <d34df00d> | Interestingly, the C(++) version of the above is slower. |
| 2021-03-04 20:12:06 | <average> | the old Haskell oneup / oneupmanship / lifesmanship trick ? "The C++ version is slower than our Haskell version" |
| 2021-03-04 20:12:55 | <average> | "In Haskell, we have faster linear algebra routines than those of Kazushige Gotō hand-optimized in assembly" |
| 2021-03-04 20:12:57 | <d34df00d> | Ah, because I return an std::pair, so the vector gets copied... |
| 2021-03-04 20:13:16 | <d34df00d> | But I'm not sure how to avoid that without making the code non-idiomatic. |
| 2021-03-04 20:13:28 | <tomsmeding> | d34df00d: std::move() ? |
| 2021-03-04 20:13:47 | <average> | "Our Haskell programs are faster on a regular computer than the same versions optimized for Quantum computers" |
| 2021-03-04 20:13:50 | <d34df00d> | For some reason it actually pessimizes code with my clang. |
| 2021-03-04 20:13:59 | <tomsmeding> | show code? |
| 2021-03-04 20:14:51 | <d34df00d> | Ah, hold on, I've put my timing thing in the wrong place. Now it's about the same speed (as expected). |
| 2021-03-04 20:15:09 | <d34df00d> | Although still a bit worse with gcc than with clang, but whatever. |
| 2021-03-04 20:15:50 | <dolio> | People are forced to try to beat C and C++ in Haskell, because other people claim they can't use anything with 'less perfromance' than C++ for anything. Then if you do beat it, the second group reveals they were lying about that being a reason for not using Haskell. |
| 2021-03-04 20:16:13 | <edwardk> | dolio++ |
| 2021-03-04 20:16:20 | <d34df00d> | eww mutation |
| 2021-03-04 20:16:22 | <tomsmeding> | d34df00d: interesting you see a difference between the two, usually it's hard to find programs where they don't perform roughly equally |
| 2021-03-04 20:16:24 | × | m0rphism1 quits (~m0rphism@HSI-KBW-085-216-104-059.hsi.kabelbw.de) (Quit: WeeChat 2.7.1) |
| 2021-03-04 20:16:38 | <edwardk> | to be fair most of the my haskell beats your c examples take ridiculously tuned haskell and run it against unoptimized c |
| 2021-03-04 20:16:40 | <d34df00d> | tomsmeding: I mean, I was forced to rewrite my Haskell implementation in ST. |
| 2021-03-04 20:17:06 | <d34df00d> | But yea, experience shows that ST is usually about the same speed as the equivalent C++ version. |
| 2021-03-04 20:17:29 | <d34df00d> | Unless the compiler can take opportunity of SIMD (say, with -march=native), which never worked for me in haskell even with -fllvm for some reason. |
| 2021-03-04 20:17:30 | → | m0rphism joins (~m0rphism@HSI-KBW-085-216-104-059.hsi.kabelbw.de) |
| 2021-03-04 20:17:39 | <monochrom> | d34df00d: I would use simply C and start with simply "int dropNoise(const char *in, int n, char *out)" |
| 2021-03-04 20:17:45 | <d34df00d> | Maybe I'm just passing the parameters to the llvm optimizer/compiler worng. |
| 2021-03-04 20:17:47 | → | kritzefitz joins (~kritzefit@212.86.56.80) |
| 2021-03-04 20:18:11 | <monochrom> | And it's what I mean by "C is easier, C++ has too much infrastruture" |
| 2021-03-04 20:18:41 | <maerwald> | optimizing haskell is a zic-zac game :) |
| 2021-03-04 20:18:51 | → | bahamas joins (~lucian@unaffiliated/bahamas) |
| 2021-03-04 20:19:22 | × | stree quits (~stree@68.36.8.116) (Ping timeout: 260 seconds) |
| 2021-03-04 20:19:31 | <swarmcollective> | Of course, runtime performance matters, but I worry more about the ability for team members to produce code that is easily reasoned, easily maintained, and contains as few defects as possible. For that, it seems that Haskell works well. |
| 2021-03-04 20:19:33 | <d34df00d> | Dang, I just noticed I can replace byte >= 0xd0 && byte <= 0xd7 with byte.&. 0xd0 == 0xd0, but it has no effect on the performance :( |
| 2021-03-04 20:19:38 | <d34df00d> | So much for cunning bit tricks! |
| 2021-03-04 20:19:49 | × | bobiusbillius quits (~bobiusbil@2a00:23c7:9909:5b01:1037:bcdb:7c3:6458) (Ping timeout: 272 seconds) |
| 2021-03-04 20:20:18 | <maerwald> | swarmcollective: depends what you mean with reasoning |
| 2021-03-04 20:20:21 | × | agander quits (~agander@185.94.193.150) (Remote host closed the connection) |
| 2021-03-04 20:20:34 | <monochrom> | gcc beats ghc on contrived microbenchmarks like "compute x mod 7 for a million x's" but it's only because gcc replaces "mod 7" by a bit-shift-and-multiply trick. |
| 2021-03-04 20:20:41 | <d34df00d> | Yeah, I find it hard to reason with your average manager that it's as easy to find haskell folks as it is for c++ folks. |
| 2021-03-04 20:20:44 | <heck-to-the-gnom> | d34df00d: That's a good thing actually, that means that the compiler is optimizing things nicely |
| 2021-03-04 20:21:32 | <tomsmeding> | d34df00d: are you on linux? if so, you could try using 'perf stat' to determine whether your program is bottlenecked on memory IO or on execution units on the CPU |
| 2021-03-04 20:21:45 | <monochrom> | And if your alternate contrived microbenchmark is "for i=0 to N do nothing" gcc also beats ghc by replacing your loop with "i = N+1". |
| 2021-03-04 20:21:51 | <tomsmeding> | if memory, then saving one inner-loop instruction may not help :) |
| 2021-03-04 20:22:02 | <average> | monochrom: why doesn't GHC do that too ? |
| 2021-03-04 20:22:18 | <monochrom> | GHC has a real life and a real job. |
| 2021-03-04 20:22:20 | × | elfets quits (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) (Read error: Connection reset by peer) |
| 2021-03-04 20:22:26 | <d34df00d> | Well, I'm processing roughly gigabyte per sec (the test file is 16 megs, on tmpfs, mmapped in case of haskell, and it takes about 15 secs to process), so I guess it's CPU-bound. Also, there's no room for instruction-level parallelism really, I think. |
| 2021-03-04 20:22:31 | <geekosaur> | what it takes to write that loop to begin with tells ghc that it's needed |
| 2021-03-04 20:22:32 | → | elfets joins (~elfets@ip-37-201-23-96.hsi13.unitymediagroup.de) |
| 2021-03-04 20:22:41 | <geekosaur> | so it believes you |
| 2021-03-04 20:22:44 | <d34df00d> | s/15 secs/15 msecs/ |
| 2021-03-04 20:22:49 | × | AndChat-33024 quits (~AndChat33@148.252.129.66) (Ping timeout: 265 seconds) |
| 2021-03-04 20:22:54 | → | bobiusbillius joins (~bobiusbil@92.40.176.1.threembb.co.uk) |
| 2021-03-04 20:23:11 | <tomsmeding> | d34df00d: makes sense |
| 2021-03-04 20:24:13 | <d34df00d> | Although I bet somebody will come up with some cunning broadword programming trick. |
| 2021-03-04 20:24:29 | × | raehik quits (~raehik@cpc95906-rdng25-2-0-cust156.15-3.cable.virginm.net) (Ping timeout: 260 seconds) |
| 2021-03-04 20:25:24 | <monochrom> | To be fair IMO strength reduction for "mod literal" is worthwhile because there are some real applications, though niche, that has it in hot spots. |
| 2021-03-04 20:25:30 | × | forgottenone quits (~forgotten@176.88.30.190) (Quit: Konversation terminated!) |
| 2021-03-04 20:25:34 | × | heatsink quits (~heatsink@2600:1700:bef1:5e10:b42a:6451:2211:3708) (Remote host closed the connection) |
| 2021-03-04 20:25:51 | <d34df00d> | The most examples I've seen of gcc beating anything (from ghc to clang) is on code that's very much tailored to the gcc's optimizer. |
| 2021-03-04 20:25:55 | <monochrom> | But "optimizing" no-op loops is just ivory tower thinking. |
| 2021-03-04 20:26:14 | <monochrom> | Either that, or cheating benchmarks. |
| 2021-03-04 20:26:26 | <geekosaur> | except when it breaks the linux kernel busy-waiting :) |
| 2021-03-04 20:26:31 | <d34df00d> | Most production code I wrote in C++ without caring about any single compiler performed better in clang than in gcc for the last maybe 4 or 5 years at least. |
| 2021-03-04 20:26:41 | <dolio> | I guess the question is why gcc does it, then. :) |
| 2021-03-04 20:26:49 | <monochrom> | And yes I get to say that some things gcc does is ivory tower irrelevancies. Bite me. |
| 2021-03-04 20:27:07 | <d34df00d> | Why, I agree. |
| 2021-03-04 20:28:46 | → | jneira joins (501e6551@gateway/web/cgi-irc/kiwiirc.com/ip.80.30.101.81) |
| 2021-03-04 20:29:33 | ← | drozdziak1 parts (~drozdziak@vps-520f86fd.vps.ovh.net) ("WeeChat 2.9") |
| 2021-03-04 20:30:02 | → | heatsink joins (~heatsink@2600:1700:bef1:5e10:b42a:6451:2211:3708) |
| 2021-03-04 20:31:06 | × | jamm_ quits (~jamm@unaffiliated/jamm) (Remote host closed the connection) |
| 2021-03-04 20:32:00 | → | stree joins (~stree@68.36.8.116) |
| 2021-03-04 20:32:14 | × | cgadski quits (~textual@87.196.80.116) (Quit: My MacBook has gone to sleep. ZZZzzz…) |
| 2021-03-04 20:33:38 | → | bob23 joins (62940397@098-148-003-151.res.spectrum.com) |
All times are in UTC.