Hacker News Reader

Comment by aerovistae | Hacker News Reader

Is it actually as fast as C? That seems like quite a claim.

It's fast as C in the same way Java and Go are as fast as C. To put it in more concrete terms, it's worst cases on the same order of magnitude as C at least for non-specialized usecases. Whereas dynamic languages are usually many orders of magnitude slower. Comparing "the speed of languages" is largely bullshit and you need to be comparing a specific problem.

Crystal certainly has the genes required to be as fast as Go, and I think very few people are unhappy with Go's performance. Currently the major difference between Crystal and Go's single-threaded performance is the GC and thats not too bad. Parallelism is coming soon.

You could say that Crystal and Go (by default) is faster than C (by default) for IO bound workflows because of how IO is handled in Crystal and Go. But most people look at micro-benchmarks which don't reflect the difficulty of achieving C's performance in C.

Any statically typed language that doesn't do anything really stupid will be as fast as C when using the same backend (LLVM here) and the same type of coding (e.g. not taking into advantage high level libs that abstract everything, but doing regular stuff like loops, bit mangling, string processing, etc).

Pascal, Rust, ADA, and lots of others all are (or can be, when programmed properly with comparable constructs) "as fast as C" (and in some cases, e.g. when avoiding aliasing issues) faster.

My Crystal test code with primes managed to run 4x faster than the D version and 1.15x faster then the Go version when built with the --release switch, but when I ran it up to 100k it filled up all my 8GB of memory and started swapping. The D and Go versions run fine up to 100k without any issues and without filling up the memory. Running it up to 100k probably also causes integer overflow and I couldn't make the range iterations work with uint64 as I'm not quite familiar with the language.

Crystal https://p.thorsen.pm/f4b376d71d1a

Dlang https://p.thorsen.pm/f5f7d6b09480

Golang https://p.thorsen.pm/369b79e836a8

You should definitely consider using Set(Int32) instead of Hash(Int32, Bool). Not sure why it is using so much RAM but I strongly encourage you to submit this as an issue on the crystal lang github.

The problem is that not all the languages tested have a Set type. This is why all the implementations use a Hash or map or associative array type, which are roughly the same thing. Othwerwise we are comparing apples with oranges. I also refuse to use anything which is not included in the standard library. The program does really basic stuff, so all of its building blocks should be in the core language. This is why the Rust implementation is slower than D or Go - because it uses HashMap which is slower than D's associative arrays or Go's maps.

I reported it and it turns out that the integer overflow generated the memory consumption issue. After modifying the code it's speed is par with Go.

It uses LLVM like Swift, Rust, & Julia. I'm not sure if it can beat highly optimized C code, but generally is in the neighborhood of C, while letting you code like a rubyist. This is similar to how Nim lets you write code similar to Python and it then transpiles to C or C++ code to be compiled by gcc or Js to be run in the browser.

Remember C compilers used to generate pretty crappy code, it took them a couple of years to improve.

Same applies to any other language.

Reply on news.ycombinator.com