www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Benchmark of D against other languages

reply "cym13" <cpicard openmailbox.org> writes:
I found this repository (reddit!) that hosts common benchmarks 
for many languages such as D, Nim, Go, python, C, etc... It uses 
only standard structures not to influence the benchmark.

https://github.com/kostya/benchmarks
Mar 31 2015
next sibling parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks 
 for many languages such as D, Nim, Go, python, C, etc... It 
 uses only standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
Can you provide the Reddit link? Right off on the Brainfuck example, the author used a class instead of a struct, and none of the methods were marked final.
Mar 31 2015
parent reply "cym13" <cpicard openmailbox.org> writes:
On Tuesday, 31 March 2015 at 18:32:25 UTC, Meta wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks 
 for many languages such as D, Nim, Go, python, C, etc... It 
 uses only standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
Can you provide the Reddit link? Right off on the Brainfuck example, the author used a class instead of a struct, and none of the methods were marked final.
Here it is: http://www.reddit.com/r/programming/comments/30y9mk I don't think the author is an experienced D programmer, but that's maybe why I find it interesting. That shows what a new naïve user can expect as a first result.
Mar 31 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/31/15 11:35 AM, cym13 wrote:
 On Tuesday, 31 March 2015 at 18:32:25 UTC, Meta wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks for
 many languages such as D, Nim, Go, python, C, etc... It uses only
 standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
Can you provide the Reddit link? Right off on the Brainfuck example, the author used a class instead of a struct, and none of the methods were marked final.
Here it is: http://www.reddit.com/r/programming/comments/30y9mk I don't think the author is an experienced D programmer, but that's maybe why I find it interesting. That shows what a new naïve user can expect as a first result.
Oh boy all classes with one-liner non-final methods. Manu must be dancing a gig right now :o). -- Andrei
Mar 31 2015
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/31/15 11:44 AM, Andrei Alexandrescu wrote:
 On 3/31/15 11:35 AM, cym13 wrote:
 On Tuesday, 31 March 2015 at 18:32:25 UTC, Meta wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks for
 many languages such as D, Nim, Go, python, C, etc... It uses only
 standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
Can you provide the Reddit link? Right off on the Brainfuck example, the author used a class instead of a struct, and none of the methods were marked final.
Here it is: http://www.reddit.com/r/programming/comments/30y9mk I don't think the author is an experienced D programmer, but that's maybe why I find it interesting. That shows what a new naïve user can expect as a first result.
Oh boy all classes with one-liner non-final methods. Manu must be dancing a gig right now :o). -- Andrei
(gigue?)
Mar 31 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/31/15 11:45 AM, Andrei Alexandrescu wrote:
 On 3/31/15 11:44 AM, Andrei Alexandrescu wrote:
 On 3/31/15 11:35 AM, cym13 wrote:
 On Tuesday, 31 March 2015 at 18:32:25 UTC, Meta wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks for
 many languages such as D, Nim, Go, python, C, etc... It uses only
 standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
Can you provide the Reddit link? Right off on the Brainfuck example, the author used a class instead of a struct, and none of the methods were marked final.
Here it is: http://www.reddit.com/r/programming/comments/30y9mk I don't think the author is an experienced D programmer, but that's maybe why I find it interesting. That shows what a new naïve user can expect as a first result.
Oh boy all classes with one-liner non-final methods. Manu must be dancing a gig right now :o). -- Andrei
(gigue?)
Let's see: https://github.com/kostya/benchmarks/pull/4
Mar 31 2015
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/31/2015 08:46 PM, Andrei Alexandrescu wrote:
 
 Let's see: https://github.com/kostya/benchmarks/pull/4
Please fire up a profiler, you never know anything.
Mar 31 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/31/15 11:47 AM, Martin Nowak wrote:
 On 03/31/2015 08:46 PM, Andrei Alexandrescu wrote:
 Let's see: https://github.com/kostya/benchmarks/pull/4
Please fire up a profiler, you never know anything.
True. I don't have time to put this on my plate, does anyone? -- Andrei
Mar 31 2015
parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/31/2015 09:07 PM, Andrei Alexandrescu wrote:
 
 True. I don't have time to put this on my plate, does anyone? -- Andrei
Very little, here is my outcome. - brainfuck => better backend, better AA The switch in the run loop doesn't use a switch table. A lot of time is also spent on AA lookup. - base64 => Base64.decode could be optimized It's already quite OK, but a few things could be done better. https://issues.dlang.org/show_bug.cgi?id=14384 - JSON => replace std.json, better AA and GC std.json is horribly bad + slow AA + slow GC. It got almost 3x faster with the new GC changes though. - matmul => need linear algebra library Can use std.numeric.dotProduct making it 33% faster. https://github.com/kostya/benchmarks/pull/6 A good linear algebra library could radically improve this. - havlak => alternative memory management, better AA and GC Got ~30% faster by the recent GC improvements. People too often new classes/create arrays like crazy (in loops). Using alternative memory management schemes is non-obvious or simply too hard. Action Points: - I'll ask him to use dmd 2.067.0 and add ldc. - We should finally acknowledge that dmd's backend has no future for optimized code. - D's AA is really slow, because of the C-ish interface. Making AA's a library type is mandatory, but difficult (already failed thrice). I outlined clear acceptance criteria for a good AA implementation here https://github.com/D-Programming-Language/druntime/pull/934#issuecomment-65916801. I currently lean towards adding a new implementation as `AA!(Key, Value)` while slowly deprecating any semantic of the builtin AA that can't be supported in a library implementation, then switching the implementations. Changing the builtin AA to a library type would break a lot of code, because of the subtle semantic/attribute differences. - We have a phobos candidate for a std.json replacement that comes with a pull parser, we should move it to std.experimental asap. http://code.dlang.org/packages/std_data_json - The GC can never be fast enough, but we're already working on it. - Make GC alternatives more prominent, e.g. tell people to favor structs over classes. - Add getOrSet to AA Simple optimization for a common use-case. https://issues.dlang.org/show_bug.cgi?id=14386 - Use open addressing for AA Considerable speeds up AA, fairly simple to implement. https://issues.dlang.org/show_bug.cgi?id=14385 Now I spent way more than 1 hour on this ;). -Martin
Mar 31 2015
prev sibling next sibling parent "ixid" <adamsibson hotmail.com> writes:
 Oh boy all classes with one-liner non-final methods. Manu must 
 be dancing a gig right now :o). -- Andrei
Jig. =)
Mar 31 2015
prev sibling next sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 3/31/15 3:44 PM, Andrei Alexandrescu wrote:
 On 3/31/15 11:35 AM, cym13 wrote:
 On Tuesday, 31 March 2015 at 18:32:25 UTC, Meta wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks for
 many languages such as D, Nim, Go, python, C, etc... It uses only
 standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
Can you provide the Reddit link? Right off on the Brainfuck example, the author used a class instead of a struct, and none of the methods were marked final.
Here it is: http://www.reddit.com/r/programming/comments/30y9mk I don't think the author is an experienced D programmer, but that's maybe why I find it interesting. That shows what a new naïve user can expect as a first result.
Oh boy all classes with one-liner non-final methods. Manu must be dancing a gig right now :o). -- Andrei
But in Crystal he also uses classes and doesn't mark methods as final. And it's faster than D. This is not to start a war, maybe one day I'll have to use D in my workplace so it better be nice and fast (so it's better if all tools are good). At least in this case, the compiler should detect that the class isn't inherited and that you are creating an executable out of the program, so it's can't be a library, and mark the methods as final. And with escape analysis (something that Crystal also lacks, but other languages have) the compiler could figure out that the class doesn't need to be allocated on the heap. In short, I think we need smarter compiler, not more keywords to optimize our code.
Mar 31 2015
parent reply "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 31 March 2015 at 22:15:58 UTC, Ary Borenszweig wrote:
 But in Crystal he also uses classes and doesn't mark methods as 
 final. And it's faster than D.
Not familiar with their way of doing. Can you explain the crystal semantic ?
Mar 31 2015
parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 3/31/15 7:27 PM, deadalnix wrote:
 On Tuesday, 31 March 2015 at 22:15:58 UTC, Ary Borenszweig wrote:
 But in Crystal he also uses classes and doesn't mark methods as final.
 And it's faster than D.
Not familiar with their way of doing. Can you explain the crystal semantic ?
You can read how method dispatch works here: http://crystal-lang.org/2015/03/04/crystal-0.6.1-released.html#method-dispatch
Mar 31 2015
prev sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:

 Oh boy all classes with one-liner non-final methods. Manu must 
 be dancing a gig right now :o). -- Andrei
Yes, the right default for D language should be final, because lot of programmers are lazy and they don't add attributes. Bye, bearophile
Apr 01 2015
parent "Namespace" <rswhite4 gmail.com> writes:
On Wednesday, 1 April 2015 at 08:52:06 UTC, bearophile wrote:
 Andrei Alexandrescu:

 Oh boy all classes with one-liner non-final methods. Manu must 
 be dancing a gig right now :o). -- Andrei
Yes, the right default for D language should be final, because lot of programmers are lazy and they don't add attributes. Bye, bearophile
As soon as we have a possibility to revoke attributes, that's not that bad. Just a little anecdote like "use final:" and everyone should understand and use it. How often have we had the debate of final as default? ;) Let's not lead to more pointless debates.
Apr 01 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks 
 for many languages such as D, Nim, Go, python, C, etc... It 
 uses only standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
dmd in benchmark => worthless there really needs to be a big red warning that dmd is just the reference implementation and use LDC/GDC for performance.
Mar 31 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Tuesday, 31 March 2015 at 23:53:07 UTC, weaselcat wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks 
 for many languages such as D, Nim, Go, python, C, etc... It 
 uses only standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
dmd in benchmark => worthless there really needs to be a big red warning that dmd is just the reference implementation and use LDC/GDC for performance.
all this benchmark made me realize is that other languages and compilers are dog slow. Removed everything except ruby, crystal, C, CPP, nim, and D(dmd and ldc), and go to save myself time. The rust version the code is for is outdated, so I couldn't do rust. base64 Crystal encode: 1333333600, 00:00:01.2094060 decode: 1000000000, 00:00:02.4451890 3.66s, 60.4Mb Go encode: 1333333600, 4.6449 decode: 1000000000, 20.7173 25.38s, 94.7Mb Cpp encode: 1333333600, 4.54 decode: 1000000000, 3.69 8.31s, 67.5Mb C encode: 1333333600, 1.19 decode: 1000000000, 2.58 3.78s, 32.8Mb D - DMD encode: 1333333600, 1.911 decode: 1000000000, 6.041 7.96s, 89.5Mb D - LDC encode: 1333333600, 1.677 decode: 1000000000, 1.916 3.61s, 53.4Mb D - GDC encode: 1333333600, 1.319 decode: 1000000000, 2.065 3.40s, 46.7Mb Nim encode: 1368421200, 1.77194 decode: 1000000000, 2.78278 4.56s, 101.9Mb Ruby encode: 1333333600, 1.69567271 decode: 1000000000, 1.837302336 3.57s, 130.3Mb winner: GDC Crystal ZYXWVUTSRQPONMLKJIHGFEDCBA 8.02s, 2.1Mb Go ZYXWVUTSRQPONMLKJIHGFEDCBA 9.57s, 1.7Mb Cpp ZYXWVUTSRQPONMLKJIHGFEDCBA 5.81s, 1.3Mb D ZYXWVUTSRQPONMLKJIHGFEDCBA 10.01s, 2.4Mb D - LDC ZYXWVUTSRQPONMLKJIHGFEDCBA 6.56s, 9.2Mb D - GDC ZYXWVUTSRQPONMLKJIHGFEDCBA 7.40s, 2.4Mb Nim Gcc ZYXWVUTSRQPONMLKJIHGFEDCBA 4.68s, 1.5Mb Nim Clang ZYXWVUTSRQPONMLKJIHGFEDCBA 3.68s, 1.4Mb Ruby 40+ seconds at third letter, ctrl-c winner: nim clang notes: LDC's memory usage?? json: test file is missing? matmul: Crystal -143.5 5.88s, 73.1Mb Go -143.500167 5.95s, 76.6Mb C -143.500167 5.36s, 69.6Mb D -143.500167 5.50s, 72.5Mb LDC -143.500167 4.97s, 80.9Mb GDC -143.500167 4.32s, 74.4Mb Nim -143.50017 5.77s, 133.8Mb Ruby ctrl-c after a couple minutes winner: D gdc LDC flags: -O5 -release -inline -boundscheck=off GDC flags: -O3 -frelease -finline -fno-bounds-check posting this knowing that andrei is about to yell at me for not posting this in the reddit thread ;)
Mar 31 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 1 April 2015 at 02:17:29 UTC, weaselcat wrote:
 ...
forgot to label second test, it's the brainfuck one. p.s., D loses because of AA slowness.
Mar 31 2015
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 3/31/15 7:17 PM, weaselcat wrote:
 posting this knowing that andrei is about to yell at me for not posting
 this in the reddit thread ;)
Yep, while reading I had this loaded in my chamber: "Remember that statistically NOBODY is on forum.dlang.org and EVERYBODY is on reddit!" -- Andrei
Mar 31 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Tue, 2015-03-31 at 19:52 -0700, Andrei Alexandrescu via Digitalmars-d wr=
ote:
 On 3/31/15 7:17 PM, weaselcat wrote:
 posting this knowing that andrei is about to yell at me for not=20
 posting
 this in the reddit thread ;)
=20 Yep, while reading I had this loaded in my chamber: "Remember that=20 statistically NOBODY is on forum.dlang.org and EVERYBODY is on=20 reddit!"=20 -- Andrei
Not "everybody". --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 01 2015
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/15 3:06 AM, Russel Winder via Digitalmars-d wrote:
 On Tue, 2015-03-31 at 19:52 -0700, Andrei Alexandrescu via Digitalmars-d wrote:
 On 3/31/15 7:17 PM, weaselcat wrote:
 posting this knowing that andrei is about to yell at me for not
 posting
 this in the reddit thread ;)
Yep, while reading I had this loaded in my chamber: "Remember that statistically NOBODY is on forum.dlang.org and EVERYBODY is on reddit!" -- Andrei
Not "everybody".
"Everybody" compared to "nobody". It's a statistics thing :o). -- Andrei
Apr 01 2015
parent reply Russel Winder via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Wed, 2015-04-01 at 07:48 -0700, Andrei Alexandrescu via Digitalmars-d wr=
ote:

 "Everybody" compared to "nobody". It's a statistics thing :o).=20
You keep pulling me up for linguistic and logical inexactness, I feel=20 no compunction=E2=80=A6 I trust your bit of the Alexandrescu tribe is doing well given the=20 recent change of state. --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.winder ekiga.n= et 41 Buckmaster Road m: +44 7770 465 077 xmpp: russel winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder
Apr 01 2015
parent reply "novice2" <sorry noem.ail> writes:
I am sorry for so dumb question, but:
when peoples talking about D and speed,
then they always say "mark method final".
Can DMD compiler do it itself, as one of optimizations?
Apr 01 2015
next sibling parent "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 1 April 2015 at 20:31:18 UTC, novice2 wrote:
 I am sorry for so dumb question, but:
 when peoples talking about D and speed,
 then they always say "mark method final".
 Can DMD compiler do it itself, as one of optimizations?
afaik there's no reason the compiler couldn't infer it for executables, but I could easily be wrong.
Apr 01 2015
prev sibling next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/01/2015 10:31 PM, novice2 wrote:
 Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization. It requires another compiler/linker phase, so it's not easy to achieve, maybe the LDC/GDC people have LTO running? GCC5 comes with a big announcement about devirtualization. https://www.gnu.org/software/gcc/gcc-5/changes.html#general
Apr 01 2015
next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 1 April 2015 at 22:15:42 UTC, Martin Nowak wrote:
 On 04/01/2015 10:31 PM, novice2 wrote:
 Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization. It requires another compiler/linker phase, so it's not easy to achieve, maybe the LDC/GDC people have LTO running? GCC5 comes with a big announcement about devirtualization. https://www.gnu.org/software/gcc/gcc-5/changes.html#general
Do you know if LLVM is getting anything similar?
Apr 01 2015
parent "deadalnix" <deadalnix gmail.com> writes:
On Wednesday, 1 April 2015 at 22:30:55 UTC, weaselcat wrote:
 On Wednesday, 1 April 2015 at 22:15:42 UTC, Martin Nowak wrote:
 On 04/01/2015 10:31 PM, novice2 wrote:
 Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization. It requires another compiler/linker phase, so it's not easy to achieve, maybe the LDC/GDC people have LTO running? GCC5 comes with a big announcement about devirtualization. https://www.gnu.org/software/gcc/gcc-5/changes.html#general
Do you know if LLVM is getting anything similar?
Yes, there is active dev in LLVM to achieve the same kind of results.
Apr 01 2015
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Martin Nowak:

 GCC5 comes with a big announcement about devirtualization.
 https://www.gnu.org/software/gcc/gcc-5/changes.html#general
I have a small question. That page says: " A new set of built-in functions for arithmetics with overflow checking has been added: __builtin_add_overflow, __builtin_sub_overflow and __builtin_mul_overflow and for compatibility with clang also other variants. These builtins have two integral arguments (which don't need to have the same type), the arguments are extended to infinite precision signed type, +, - or * is performed on those, and the result is stored in an integer variable pointed to by the last argument. If the stored value is equal to the infinite precision result, the built-in functions return false, otherwise true. The type of the integer variable that will hold the result can be different from the types of the first two arguments. The following snippet demonstrates how this can be used in computing the size for the calloc function: void * calloc (size_t x, size_t y) { size_t sz; if (__builtin_mul_overflow (x, y, &sz)) return NULL; void *ret = malloc (sz); if (ret) memset (res, 0, sz); return ret; } On e.g. i?86 or x86-64 the above will result in a mul instruction followed by a jump on overflow. " Now both GCC and Clang have intrinsics to perform safe integral operations. In recent versions of druntime/dmd there are functions to perform some safe integer operations. So is the API very well compatible with those intrinsics? Bye, bearophile
Apr 01 2015
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/02/2015 01:39 AM, bearophile wrote:
 built-in functions for arithmetics with overflow checking
Your persistent interest in integer overflow checks make we wonder if you were responsible for this? http://www.around.com/ariane.html
Apr 01 2015
parent "bearophile" <bearophileHUGS lycos.com> writes:
Martin Nowak:

 Your persistent interest in integer overflow checks make we 
 wonder if you were responsible for this?
 http://www.around.com/ariane.html
I am not responsible for that, but I try to not be responsible for future molecular biology mistakes equivalent to that Ariane fiasco. Bye, bearophile
Apr 02 2015
prev sibling next sibling parent reply Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 April 2015 at 08:15, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 04/01/2015 10:31 PM, novice2 wrote:
 Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization. It requires another compiler/linker phase, so it's not easy to achieve, maybe the LDC/GDC people have LTO running? GCC5 comes with a big announcement about devirtualization. https://www.gnu.org/software/gcc/gcc-5/changes.html#general
It is impossible to do a good job. There are 2 conditions that break most opportunities that the compiler may have to improve this: 1) The class is a pointer (duh, in D, all classes are pointers, so that condition is implicit). 2) That DLL's exist. If a DLL may exist, and a class is a pointer (it is), sourced from an 'impure' location, then it is impossible for the compiler to generally do anything at all about final. It may theoretically be able to do something in the case where the class is proofably contained within a 'scope' confined space/function, but that particular case is almost mutually exclusive with cases where polymorphism is actually useful in the first place, so it's not really practical. I also imagine the complexity in the compiler would be off the charts. Basically, if it is _possible_ for a class pointer to come in contact with dynamically loaded code, the compiler must conservatively abandon any attempt to optimise. virtual by default is completely wrong for D. And don't say 'speculative' devirtualisation. What an abomination! Just fix the problem; don't have every function be virtual in the first place!
Apr 02 2015
next sibling parent reply "lobo" <swamplobo gmail.com> writes:
On Thursday, 2 April 2015 at 09:06:52 UTC, Manu wrote:
 On 2 April 2015 at 08:15, Martin Nowak via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 04/01/2015 10:31 PM, novice2 wrote:
 Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization. It requires another compiler/linker phase, so it's not easy to achieve, maybe the LDC/GDC people have LTO running? GCC5 comes with a big announcement about devirtualization. https://www.gnu.org/software/gcc/gcc-5/changes.html#general
It is impossible to do a good job. There are 2 conditions that break most opportunities that the compiler may have to improve this: 1) The class is a pointer (duh, in D, all classes are pointers, so that condition is implicit). 2) That DLL's exist. If a DLL may exist, and a class is a pointer (it is), sourced from an 'impure' location, then it is impossible for the compiler to generally do anything at all about final. It may theoretically be able to do something in the case where the class is proofably contained within a 'scope' confined space/function, but that particular case is almost mutually exclusive with cases where polymorphism is actually useful in the first place, so it's not really practical. I also imagine the complexity in the compiler would be off the charts. Basically, if it is _possible_ for a class pointer to come in contact with dynamically loaded code, the compiler must conservatively abandon any attempt to optimise. virtual by default is completely wrong for D. And don't say 'speculative' devirtualisation. What an abomination! Just fix the problem; don't have every function be virtual in the first place!
+1 Even an escape would be useful so one can do this: final class Hack { virtual void func() {} } It would then be trivial to stick a final in front of the class. It would also be required to declare final when instantiating the class, to work with third-party libraries that don't use final, i.e. auto klass = new final Class(); I'm not a language developer and I don't know D that well yet so I'll stop there before I embarrass myself too much! :D bye, lobo
Apr 02 2015
parent Daniel =?UTF-8?B?S296w6Fr?= via Digitalmars-d writes:
On Thu, 02 Apr 2015 11:00:12 +0000
lobo via Digitalmars-d <digitalmars-d puremagic.com> wrote:

 On Thursday, 2 April 2015 at 09:06:52 UTC, Manu wrote:
 On 2 April 2015 at 08:15, Martin Nowak via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On 04/01/2015 10:31 PM, novice2 wrote:
 Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization. It requires another compiler/linker phase, so it's not easy to achieve, maybe the LDC/GDC people have LTO running? GCC5 comes with a big announcement about devirtualization. https://www.gnu.org/software/gcc/gcc-5/changes.html#general
It is impossible to do a good job. There are 2 conditions that break most opportunities that the compiler may have to improve this: 1) The class is a pointer (duh, in D, all classes are pointers, so that condition is implicit). 2) That DLL's exist. If a DLL may exist, and a class is a pointer (it is), sourced from an 'impure' location, then it is impossible for the compiler to generally do anything at all about final. It may theoretically be able to do something in the case where the class is proofably contained within a 'scope' confined space/function, but that particular case is almost mutually exclusive with cases where polymorphism is actually useful in the first place, so it's not really practical. I also imagine the complexity in the compiler would be off the charts. Basically, if it is _possible_ for a class pointer to come in contact with dynamically loaded code, the compiler must conservatively abandon any attempt to optimise. virtual by default is completely wrong for D. And don't say 'speculative' devirtualisation. What an abomination! Just fix the problem; don't have every function be virtual in the first place!
+1 Even an escape would be useful so one can do this: final class Hack { virtual void func() {} } It would then be trivial to stick a final in front of the class. It would also be required to declare final when instantiating the class, to work with third-party libraries that don't use final, i.e. auto klass = new final Class(); I'm not a language developer and I don't know D that well yet so I'll stop there before I embarrass myself too much! :D bye, lobo
final class Hack { virtual void func() {} } I do not see how this would help? If you make class Hack final, you can not use inheritence anymore so having virtual void func() does not make sense to me. class Hack { final: // some final methods virtual void func() {} } makes more sense ;)
Apr 02 2015
prev sibling parent reply "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 2 April 2015 at 09:06:52 UTC, Manu wrote:
 virtual by default is completely wrong for D.

 And don't say 'speculative' devirtualisation. What an 
 abomination!
 Just fix the problem; don't have every function be virtual in 
 the
 first place!
I'm not sure why you don't use struct in the first place ?
Apr 02 2015
parent Manu via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 3 April 2015 at 05:00, deadalnix via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Thursday, 2 April 2015 at 09:06:52 UTC, Manu wrote:
 virtual by default is completely wrong for D.

 And don't say 'speculative' devirtualisation. What an abomination!
 Just fix the problem; don't have every function be virtual in the
 first place!
I'm not sure why you don't use struct in the first place ?
It's not a reference type. Class is the natural reference type, and people naturally want to use it. I have no control over that. I have said before, most of my anecdotes are simply what has happened in my presence, despite my coaching otherwise. Also, it's useful to have a virtual or 2... and I mean that, _1 or 2_, among 10's of other properties and methods. As I've said before, my experience has demonstrated to me precisely what I predicted; that even when coached to write final everywhere, nobody EVER did that in my presence... not once. Never. It's completely unnatural for programmers to do this, and therefore the default is wrong. I don't make this argument based on what I do/don't do, so your assertion about what I should/shouldn't do is irrelevant, I've said this many times before. I make this argument in relation to _what I have to clean up_, and D has made my life significantly harder in this regard than C++, which was already a nightmare. Not only is it harder and more time-wasting to discover mis-virtuals, but in the case you're dealing with libs, it's also a breaking change to fix it, and that's a very serious problem. Anyway, we're done with this.
Apr 06 2015
prev sibling parent Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 2 April 2015 at 00:15, Martin Nowak via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On 04/01/2015 10:31 PM, novice2 wrote:
 Can DMD compiler do it itself, as one of optimizations?
You could do it as part of LTO or whole program optimization. It requires another compiler/linker phase, so it's not easy to achieve, maybe the LDC/GDC people have LTO running? GCC5 comes with a big announcement about devirtualization. https://www.gnu.org/software/gcc/gcc-5/changes.html#general
I've always said: Use LTO at your own risk. It has been broken for months at a time because I simply do not have time to give it the TLC it needs. I expect that devirtualisation capabilities to be a little more limiting than advertised by GCC, as you do not get these sorts of optimisations for free (may need some extra support from respective frontends). Regards Iain
Apr 02 2015
prev sibling parent Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/01/2015 10:31 PM, novice2 wrote:
 Can DMD compiler do it itself, as one of optimizations?
Even more interesting a complete blog post about devirtualization. http://hubicka.blogspot.de/2014/02/devirtualization-in-c-part-4-analyzing.html
Apr 01 2015
prev sibling parent reply Iain Buclaw via Digitalmars-d <digitalmars-d puremagic.com> writes:
On 1 April 2015 at 04:17, weaselcat via Digitalmars-d
<digitalmars-d puremagic.com> wrote:
 On Tuesday, 31 March 2015 at 23:53:07 UTC, weaselcat wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks for many
 languages such as D, Nim, Go, python, C, etc... It uses only standard
 structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
dmd in benchmark => worthless there really needs to be a big red warning that dmd is just the reference implementation and use LDC/GDC for performance.
all this benchmark made me realize is that other languages and compilers are dog slow. Removed everything except ruby, crystal, C, CPP, nim, and D(dmd and ldc), and go to save myself time. The rust version the code is for is outdated, so I couldn't do rust.
[snip] Out of curiousity, which version of GDC are you using there? Looking at the results published on github look worrying, given that they used an outdated (by our community's standards) version of Phobos with GDC (2.058, if memory serves well). If more recent versions (DMD 2.067, LDC 0.15) are behind by a second or more, that might suggest that somewhere, something went horribly wrong in the library. Iain.
Apr 02 2015
parent "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 2 April 2015 at 21:55:59 UTC, Iain Buclaw wrote:
 On 1 April 2015 at 04:17, weaselcat via Digitalmars-d
 <digitalmars-d puremagic.com> wrote:
 On Tuesday, 31 March 2015 at 23:53:07 UTC, weaselcat wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common 
 benchmarks for many
 languages such as D, Nim, Go, python, C, etc... It uses only 
 standard
 structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
dmd in benchmark => worthless there really needs to be a big red warning that dmd is just the reference implementation and use LDC/GDC for performance.
all this benchmark made me realize is that other languages and compilers are dog slow. Removed everything except ruby, crystal, C, CPP, nim, and D(dmd and ldc), and go to save myself time. The rust version the code is for is outdated, so I couldn't do rust.
[snip] Out of curiousity, which version of GDC are you using there? Looking at the results published on github look worrying, given that they used an outdated (by our community's standards) version of Phobos with GDC (2.058, if memory serves well). If more recent versions (DMD 2.067, LDC 0.15) are behind by a second or more, that might suggest that somewhere, something went horribly wrong in the library. Iain.
gdc (GCC) 4.9.2 I'm not sure how to get GDC to show which D version it's based on - but I think it's 2.065. I'm using the latest one available in Arch repos.
Apr 02 2015
prev sibling next sibling parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 03/31/2015 08:20 PM, cym13 wrote:
 https://github.com/kostya/benchmarks
We made a massive jump towards the upper ranks. https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-benchb https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-mandelb https://github.com/kostya/benchmarks/tree/master/base64#user-content-benchmark https://github.com/kostya/benchmarks/tree/master/json#user-content-benchmark https://github.com/kostya/benchmarks/tree/master/matmul#user-content-benchmark https://github.com/kostya/benchmarks/tree/master/havlak#user-content-benchmark https://github.com/kostya/benchmarks ¹: Nim outperforms anything else on brainfuck by a large margin because it has the fastest hash table (open addressing, storing values in head). https://github.com/Araq/Nim/blob/57fa8c6d3f535acc79ef8a67a6ef7aef0c7519da/lib/pure/collections/tables.nim#L73 http://code.dlang.org/packages/std_data_json. ³: Places 2, 3, and 4 thanks to std.numeric.dotProduct. An optimized
Apr 01 2015
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/15 3:49 PM, Martin Nowak wrote:
 On 03/31/2015 08:20 PM, cym13 wrote:
 https://github.com/kostya/benchmarks
We made a massive jump towards the upper ranks.
[snip] This is amazing work. Thanks! -- Andrei
Apr 01 2015
prev sibling next sibling parent reply "weaselcat" <weaselcat gmail.com> writes:
On Wednesday, 1 April 2015 at 22:49:55 UTC, Martin Nowak wrote:
 On 03/31/2015 08:20 PM, cym13 wrote:
 https://github.com/kostya/benchmarks
We made a massive jump towards the upper ranks. https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-benchb https://github.com/kostya/benchmarks/tree/master/brainfuck#user-content-benchmark-mandelb https://github.com/kostya/benchmarks/tree/master/base64#user-content-benchmark https://github.com/kostya/benchmarks/tree/master/json#user-content-benchmark https://github.com/kostya/benchmarks/tree/master/matmul#user-content-benchmark https://github.com/kostya/benchmarks/tree/master/havlak#user-content-benchmark https://github.com/kostya/benchmarks ¹: Nim outperforms anything else on brainfuck by a large margin because it has the fastest hash table (open addressing, storing values in head). https://github.com/Araq/Nim/blob/57fa8c6d3f535acc79ef8a67a6ef7aef0c7519da/lib/pure/collections/tables.nim#L73 http://code.dlang.org/packages/std_data_json. ³: Places 2, 3, and 4 thanks to std.numeric.dotProduct. An optimized
the benchmark pointed out two sore areas in D(AA and std.json,) would be nice to see AA get updated as I often completely avoid using the built-in AA.
Apr 01 2015
parent reply Martin Nowak <code+news.digitalmars dawg.eu> writes:
On 04/02/2015 03:35 AM, weaselcat wrote:
 
 the benchmark pointed out two sore areas in D(AA and std.json,) would be
 nice to see AA get updated as I often completely avoid using the
 built-in AA.
I filed two ERs already, both are pretty isolated and not too hard to implement. I hope I don't have to do that myself. https://issues.dlang.org/show_bug.cgi?id=14385 https://issues.dlang.org/show_bug.cgi?id=14386 The real fix a.k.a. library AA is a much harder problem.
Apr 01 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 2 April 2015 at 03:55:53 UTC, Martin Nowak wrote:
 On 04/02/2015 03:35 AM, weaselcat wrote:
 
 the benchmark pointed out two sore areas in D(AA and 
 std.json,) would be
 nice to see AA get updated as I often completely avoid using 
 the
 built-in AA.
I filed two ERs already, both are pretty isolated and not too hard to implement. I hope I don't have to do that myself. https://issues.dlang.org/show_bug.cgi?id=14385 https://issues.dlang.org/show_bug.cgi?id=14386 The real fix a.k.a. library AA is a much harder problem.
was it a conscious decision to make the AA [] operator not work like map/etc in C++?
Apr 01 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 2 April 2015 at 04:11:02 UTC, weaselcat wrote:
 was it a conscious decision to make the AA [] operator not work 
 like map/etc in C++?
What do you mean?
Apr 01 2015
parent reply "weaselcat" <weaselcat gmail.com> writes:
On Thursday, 2 April 2015 at 04:32:26 UTC, Martin Nowak wrote:
 On Thursday, 2 April 2015 at 04:11:02 UTC, weaselcat wrote:
 was it a conscious decision to make the AA [] operator not 
 work like map/etc in C++?
What do you mean?
accessing a non-existing element in C++'s map/unordered_map inserts the default instead of raising an exception int main(int argc, char *argv[]) { std::unordered_map<std::string, int> test; std::cout << test["hello"] << std::endl; return 0; } prints 0 void main() { int[string] test; writeln(test["hello"]); } core.exception.RangeError source/main.d(9): Range violation
Apr 01 2015
parent "bearophile" <bearophileHUGS lycos.com> writes:
weaselcat:

 was it a conscious decision to make the AA [] operator not 
 work like map/etc in C++?
What do you mean?
accessing a non-existing element in C++'s map/unordered_map inserts the default instead of raising an exception int main(int argc, char *argv[]) { std::unordered_map<std::string, int> test; std::cout << test["hello"] << std::endl; return 0; } prints 0 void main() { int[string] test; writeln(test["hello"]); } core.exception.RangeError source/main.d(9): Range violation
Yes, it was a conscious decision, because here C++ behaves in a very bug-prone way. Sometimes C++ is a bad example to follow (like with permutations generations, that currently is not a Range in Phobos for the wrong reasons). Bye, bearophile
Apr 02 2015
prev sibling parent reply "anonymous" <a b.xy> writes:
On Wednesday, 1 April 2015 at 22:49:55 UTC, Martin Nowak wrote:
 ³: Places 2, 3, and 4 thanks to std.numeric.dotProduct. An 
 optimized

According to https://github.com/JuliaLang/julia#Required-Build-Tools-External-Libraries building Julia requires OpenBlas or Intel MKL. So the native julia matrix-matrix-multiplication is most probably just a call to a highly optimized BLAS gemm + some overhead. => beeing faster than Julia native would require to be as least fast as openBLAS/Intel MKL gemm. It would be nice to have such a good matrix multiplication in Phobos but I think there are more important things to work on (GC, AA, ...), Dstep + cblas.h works quite well although code calling it involves pointers :)
Apr 02 2015
parent reply "Martin Nowak" <code dawg.eu> writes:
On Thursday, 2 April 2015 at 08:32:13 UTC, anonymous wrote:
 It would be nice to have such a good matrix multiplication in
 Phobos but I think there are more important things to work on
 (GC, AA, ...),
I'm not asking for a linear algebra library in phobos, although we need one in dub and should consider having one in Phobos at some point too. But it would be nice if std.numeric came with a multiply(T)(T[][] a, T[][] b, T[][] result) to complement dotProduct and the built-in vector ops. As you've seen dotProduct set us far ahead of C.
 Dstep + cblas.h works quite well although code calling it
 involves pointers :)
How hard would it be to turn that into a lib.
Apr 02 2015
parent "anonymous" <a b.xy> writes:
On Thursday, 2 April 2015 at 09:09:04 UTC, Martin Nowak wrote:
 I'm not asking for a linear algebra library in phobos, although 
 we need one in dub and should consider having one in Phobos at 
 some point too.
 But it would be nice if std.numeric came with a 
 multiply(T)(T[][] a, T[][] b, T[][] result) to complement 
 dotProduct and the built-in vector ops.
 As you've seen dotProduct set us far ahead of C.
Sounds good: - a matrix multiplication in phobos that is faster than a naive implementation but does not try to beat BLAS gemm. - a dub LA library around BLAS. There is http://code.dlang.org/packages/cblas but it seems to be not much more than dstep + cblas.h
 How hard would it be to turn that into a lib.
Don't know, I perhaps try. I have a working prototype of a BFGS non-linear optimizer currently calling BLAS via array.ptr and the vague plan to make it opensource. If that ever happens, a LA library around BLAS would be a great co-product.
Apr 02 2015
prev sibling parent reply "Laeeth Isharc" <nospamlaeeth nospam.laeeth.com> writes:
On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks 
 for many languages such as D, Nim, Go, python, C, etc... It 
 uses only standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
Thanks for this. BTW, some of these benchmarks were taken from attractivechaos here. He seems to be working in bioinformatics and does not consider himself a programmer by profession. But has written some libraries others use, and is clearly bright and thoughtful. He is pro-D and sad people have not recognized its qualities. https://attractivechaos.wordpress.com/ From 2010: "Although I do not use D, I always see it as one of the most attractive programming languages, smartly balancing efficiency, simplicity and extensibility. At the same time, I keep getting frustrated when I see such an elegant thing fade away gradually given that a) D has dropped out of top 20 in TIOBE Programming Community Index and b) it was not evaluated by the Computer Language Benchmarks Game any more. Most programmers know why this happens. I am simply frustrated. D is falling while Go is rising. I do appreciate the philosophy behind the design of Go and trust Rob Pike and Ken Thompson to deliver another great product, but right now I do not see Go as a replacement of any mainstream programming languages as long as it is way slower than Java, not to speak C/C++. To me, Go’s rising is merely due to the support from Google. It is good as a research project, but it needs time to reach the critical mass in practice. While reading the Computer Language Benchmarks Game, I am really amazed by LuaJIT. Probably I am going to try it some day." Some of his posts on efficiency of data structures are worth reading, particularly on hash tables, btrees/redblack trees/sorting (might be old to you, but there was some new stuff for me): https://attractivechaos.wordpress.com/tag/benchmark/ Speed and memory. The larger the hash table, the fewer collisions may occur and the faster the speed. For the same hash library, increasing memory always increases speed. When we compare two libraries, both speed and memory should be considered. C vs. C++. All C++ implementations have similar API. It is also very easy to use for any type of keys. Both C libraries, ghthash and glib, can only keep pointers to the keys, which complicates API and increases memory especially for 64-bit systems where a pointer takes 8 bytes. In general, C++ libraries is perferred over C ones. Surprisingly, on 32-bit Mac OS X, glib outperforms TR1 and STL for string input. This might indicate that the glib implementation itself is very efficient, but just the lack of functionality in C affects the performance. Generic programming in C. Except my khash.h, all the other C hash libraries use (void*) to achieve generic typing. Using void* is okey for strings, but will cause overhead for integers. This is why all C libraries, except khash.h, is slower than C++ libraries on integer keys, but close to on string keys. Open addressing vs. chaining hash. Khash and google hash implement open addressing hash while the remaining implement chaining hash. In open addressing hash, the size of each bucket equals the size of a key plus 0.25 byte. Google sparsehash further compresses unused bucket to 1 bit, achieving high memory efficiency. In chaining hash, the memory overhead of each bucket is at least 4 bytes on 32bit machines, or 8 bytes on 64bit machines. However, chaining hash is less affected when the hash table is nearly full. In practice, both open addressing and chaining hash occupy similar memory under similar speed. Khash takes less peak memory mainly due to its advanced technique in rehashing which reduces memory usage. So far as speed is concerned, chaining hash may have fewer comparison between keys. We can see this from the fact that the speed of chaining hash approaches that of open addressing hash on string keys but much slower on integer keys. Memory usage of search trees. B-tree is the winner here. Each element in the B-tree only needs one additional pointer. When there are enough elements, a B-tree is at least halfly full; on average it should be around 75% full. And so on 64-bit systems, for a B-tree with N elements, we need additional N*8/0.75=10N bytes memory. Splay tree will need N*8*2=16N extra space. RB tree is the worst. Other issues. a) Google hash becomes unbearably slow when I try to put a lot of strings in the hash table. All the other libraries do not have this problem. b) Google hash performs more comparisons than khash. This is obvious because google-dense is clearly faster on integer keys but comparable to khash on string keys. Concluding remarks C++ hash library is much easier to use than C libraries. This is definitely where C++ is preferred over C. TR1 hash implementation is no faster than STL implementation. They may outperform one another under certain input or settings. SGI hash_map is faster and takes less memory than STL map. Unless ordering is important, hash_map is a better container than map. Google hash is a worthy choice when we understand why it is slow for many string keys. My khash library, which is a single-file C++ template header, achieves good balance between speed and memory. All my source codes are available at the Programs page. Update C interface can be elegant, too, if we implement it cleverly. See this post. I realize that we just need one lookup to achieve “insert if absent; delete otherwise”. This further improves the speed for all C++ libraries. I have analyzed google dense hash table in this post which explains why it is faster than khash on integer keys but close to or slower than on string keys.
Apr 02 2015
next sibling parent Ary Borenszweig <ary esperanto.org.ar> writes:
On 4/2/15 11:20 PM, Laeeth Isharc wrote:
 On Tuesday, 31 March 2015 at 18:20:05 UTC, cym13 wrote:
 I found this repository (reddit!) that hosts common benchmarks for
 many languages such as D, Nim, Go, python, C, etc... It uses only
 standard structures not to influence the benchmark.

 https://github.com/kostya/benchmarks
Thanks for this. BTW, some of these benchmarks were taken from attractivechaos here. He seems to be working in bioinformatics and does not consider himself a programmer by profession. But has written some libraries others use, and is clearly bright and thoughtful. He is pro-D and sad people have not recognized its qualities. https://attractivechaos.wordpress.com/
He contributed some samples and pull requests to the Crystal repository and he's always very humble and does good observations and suggestions. I don't recall seeing him say anything bad about any language: just some benchmarks and how they behave, let the benchmarks (and code) speak for him :-)
Apr 04 2015
prev sibling parent "Isaac Gouy" <igouy2 yahoo.com> writes:
On Friday, 3 April 2015 at 02:20:24 UTC, Laeeth Isharc wrote:
 not evaluated by the Computer Language Benchmarks Game any more.
iirc Some people in the D community were going to make their own measurements of benchmarks game tasks and publish them. Has that happened? I just noticed someone has used the benchmarks game measurement scripts (and even the PHP scripts!) to show a bunch of Python language implementations -- http://python.milde.cz/u64q/performance.php?test=nbody
Apr 27 2015