Look and think good things about D

Ary Borenszweig ary at esperanto.org.ar
Fri Nov 15 07:17:06 PST 2013


On 11/15/13 10:33 AM, bearophile wrote:
> Ary Borenszweig:
>
>> And so LLVM, which is what Crystal uses as a backend.
>
> LDC2 uses the same back end :-)
>
>
>> But I thought ranges were meant to be fast. No allocations and all of
>> that. In fact, I was kind of sad that Crystal doesn't have a similar
>> concept so it could never get as fast as D ranges. But if D ranges are
>> not fast, what's the point of having them and making everyone use them?
>
> If you use ranges badly you will get a slow program, if you use them
> well with a good back-end, you will have a fast program.
>
> I have written a third intermediate program, it's longer than yours, and
> it seems much slower than your code:
>
>
> void main(in string[] args) {
>      import std.stdio, std.conv, std.algorithm, std.array;
>
>      immutable n = (args.length == 2) ? args[1].to!uint : 10;
>      if (n == 0)
>          return;
>
>      auto seq = "1";
>      writefln("%2d: n. digits: %d", 1, seq.length);
>      foreach (immutable i; 2 .. n + 1) {
>          Appender!string result;
>          foreach (immutable digit, immutable count; seq.group) {
>              result ~= "123"[count - 1];
>              result ~= digit;
>          }
>          seq = result.data;
>          writefln("%2d: n. digits: %d", i, seq.length);
>      }
> }
>
>
> On my system it runs in 0.34 seconds for n=50. Could you compare some of
> the timings of the various D/Crystal versions on your system (using ldc2
> for D)?

Sure.

This last version you wrote, compiling it with "-enable-inlining 
-release -O3", takes 0.054s (please tell me if I'm missing some flags, 
in Crystal I just used --release). The Crystal version takes 0.031s. I 
also tried with n=70. In D: 9.265s. In Crystal: 4.863s.

I couldn't compile the first version written in D because I get:

Error: pure function '__lambda1' cannot call impure function 'join'

(I think you mentioned this in another post in this thread)

The super-optimized D version, with n=70, takes 1.052s. This is the fastest.

However, I'm starting to think that all those immutable, final switches 
and gotos are useless if they don't give a performance benefit (well, 
final switches do give you more safety). Maybe it's just that D/ldc 
doesn't use the immutability information and everything else to do 
aggressive optimizations?


More information about the Digitalmars-d mailing list