On 11/15/13 9:47 AM, bearophile wrote:
Ary Borenszweig:

Here's what I was able to do in some minutes:

---
if ARGV.length != 1
  puts "missing argument: n"
  exit 1
end

n = ARGV[0].to_i
str = "1"
buffer = String::Buffer.new(20)
n.times do
  puts str.length
  str.each_chunk do |digit, count|
    buffer << '0' + count
    buffer << digit
  end
  str = buffer.to_s
  buffer.clear
end

With n=70 it takes about 4.89s. With n=45 it takes about 0.012s.

This program is much longer in number of tokens to the first D program.
You can write a D program about as fast as this in about the same number
of tokens.

No. I just counted the tokens and D has more tokens:

http://pastebin.com/XZFf8dsj

It's even longer if I keep all the programs arguments checking (ARGV). If I remove that, the program has 45 tokens. The D version has 81 tokens. And without the imports, D still has 68 tokens.

(well, I didn't count newlines as tokens, so maybe that's unfair because newlines in Crystal are significant)

Yes, it's not as functional as D. But only because the language is still young.


Perhaps I should add an intermediate third version that shows code
that's not as extreme as the two versions there. Thank you for the
implicit suggestion.


And with Crystal you could do the second version as well, because you
have access to low level stuff like pointers.

In Crystal do you have final switches, gotos, etc too?

No. In this D will always be better, if you really want your program to have gotos.

And also, the language is pretty new so there's still
a lot of optimizations to be done.

And LDC2 will improve in the meantime.

And so LLVM, which is what Crystal uses as a backend.



I also thought ranges were pretty fast because of their nature.

It also matters a lot how you use them, this is normal in computer
programming.

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?



Why are they slow in this example?

Just because the first example is not written for speed, I didn't even
add run-time timings for it at first. And it's not that slow.

Ah, I thought you did. So I misunderstood your timings. Sorry.


Bye,
bearophile

Reply via email to