OCaml kicks ass on Tim Bray's Wide Finder 2 benchmark challenge. Again.

Re:OCaml kicks ass on Tim Bray's Wide Finder 2 benchmark cha... by mfp on Monday October 27, 2008 @10:44PM (#345949)

IO was only (barely) disk-bound when you gave a full core to the reader (i.e., you have to be careful not to use HW threads on the same core). This is not a problem specific to OCaml --- I reproduced it with a standalone program written in C that simply read the file: as soon as you have more stuff running on the same core (in different hardware threads), the IO performance drops. See http://groups.google.com/group/wide-finder/browse_thread/thr...

Also, and this came as quite a surprise, it turns out that mmap is slower than read(2) on the T2K.

[ Parent | on HN ]

Re:OCaml kicks ass on Tim Bray's Wide Finder 2 benchmark cha... by iigs on Tuesday October 28, 2008 @02:22AM (#346107)

Wow, interesting. Thanks for the info and the link. This is a surprising and disappointing aspect of this CPU.

Do you know if there's something about this (seemingly trivial) workload that is pathologically bad for this processor, or do you believe that the CPU is just wimpy? I've only ever had a glossy spec-sheet-level introduction to these at work. Given this load I don't see the value of "4 threads per core" that they proclaim on http://www.sun.com/processors/UltraSPARC-T1/specs.xml

[ Parent | on HN ]

Re:OCaml kicks ass on Tim Bray's Wide Finder 2 benchmark cha... by mfp on Tuesday October 28, 2008 @08:15PM (#346963)

It's just that the hardware threads are slow, I think --- compiling stuff on the T2K also took forever. It also seems to me that there's seemingly little value in having 4 threads per core: it forces you to parallelize programs that ran fine with normal cores just to match the performance you'd get without hardware threads...

[ Parent | on HN ]