13 ms·

The claim is "fast as C", so I was surprised that the performance comparison was with Ruby, not with C. On my machine, the Ruby Fibonacci program executes in 4

by Athas 10y ago

The claim is "fast as C", so I was surprised that the performance comparison was with Ruby, not with C. On my machine, the Ruby Fibonacci program executes in 47.5s, while a corresponding C program executes in 0.88s - that's a factor 54 difference, while the article reports a factor 35 for Crystal. That's good, but what causes the difference? This benchmark is pretty much all function call overhead, so I doubt it's representative of real performance-sensitive code. The Crystal website itself makes a more modest claim than "fast as C" under its language goals: "Compile to efficient native code", which it clearly does.

Svenskunganka 10y ago
There's some benches between various languages, including Crystal as well, for those interested https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks EDIT: There's also this: https://github.com/nsf/pnoise https://github.com/nsf/pnoise
- rogerdpack 10y ago
  Here's a small HTTP style benchmark across various languages (a bit limited, but still interesting): https://github.com/costajob/app-servers https://github.com/costajob/app-servers
bluetomcat 10y ago
All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as much as possible. You craft your own data structures suited for the problem at hand, rather than using the standard "one size fits all" ones. Compare that to the "new this, new that" style of programming that's prevalent today.
- progman 10y ago
  There actually is one high-level Python-like language that really is almost "as fast as C". http://nim-lang.org http://nim-lang.org I am using it for years already, and it is really performant, somewhere between C and Rust. I am still wondering why so few people use it. Benchmark: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks Nim vs Rust: http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs... Performance discussion: http://forum.nim-lang.org/t/2261 http://forum.nim-lang.org/t/2261 Embedded Nim: https://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/ Nim on LLVM: https://github.com/arnetheduck/nlvm https://github.com/arnetheduck/nlvm
  - def- 10y ago
    > I am still wondering why so few people use it. While Nim is my favorite language, I can understand that it has a small userbase, for these reasons: 1. No major backer like Google for Go or Mozilla for Rust 2. No killer feature like "memory safety and performance without GC" for Rust, instead a mix of all the reasonable down-to-earth features I want in a programming language 3. Some unique decisions instead of what you're used to from other languages, for example partial case sensitivity
    - untothebreach 10y ago
      I used both nim (back when it was still nimrod) and rust for a while, before eventually settling on rust. I tried to give nim a chance, and was told that "they will grow on you" ("they" being the things you mentioned that were "unique decisions instead of what you're used to from other languages"). They never did, and though I got used to avoiding the problems I initially had with them, the language just never "felt good" to me.
    - valarauca1 10y ago
      4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12
exDM69 10y ago
> That's good, but what causes the difference? Could it be startup time? That's less of an issue when the application has started up. A fibonacci application is not a very good benchmark anyway.
SparkyMcUnicorn 10y ago
From this quote it sounds like the more CPU intensive it is, the more you can expect when comparing to Ruby. >Remember: The cake is a lie, and so are benchmarks. You won’t have 35x increase in performance all the time, but you can expect 5x or more in complex applications, more if it’s CPU intensive.
igouy 10y ago
> I doubt it's representative of real performance-sensitive code Two data points (one-off timings of a few lines of code doing the same work load) just don't make for a comparison we should spend time bothering about. Whatever you think of the benchmarks game, I don't see why we need to waste time with comparisons that don't meet that low standard: - a few different tasks - more than a code snippet - a few repeat measurements - a few different workloads

by Athas 10y ago

Svenskunganka 10y ago

There's some benches between various languages, including Crystal as well, for those interested https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks EDIT: There's also this: https://github.com/nsf/pnoise https://github.com/nsf/pnoise

rogerdpack 10y ago
Here's a small HTTP style benchmark across various languages (a bit limited, but still interesting): https://github.com/costajob/app-servers https://github.com/costajob/app-servers

bluetomcat 10y ago

All of these "fast as C" claims about modern, high-level Python-like languages (be they statically typed and natively compiled) are missing the point. It is mostly the minimalistic and terse programming style that C encourages that makes C programs performant. You avoid allocations wherever possible, you write your own custom allocators and memory pools for frequently allocated objects, you avoid copying stuff as much as possible. You craft your own data structures suited for the problem at hand, rather than using the standard "one size fits all" ones. Compare that to the "new this, new that" style of programming that's prevalent today.

progman 10y ago
There actually is one high-level Python-like language that really is almost "as fast as C". http://nim-lang.org http://nim-lang.org I am using it for years already, and it is really performant, somewhere between C and Rust. I am still wondering why so few people use it. Benchmark: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks Nim vs Rust: http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs-rust.html http://arthurtw.github.io/2015/01/12/quick-comparison-nim-vs... Performance discussion: http://forum.nim-lang.org/t/2261 http://forum.nim-lang.org/t/2261 Embedded Nim: https://hookrace.net/blog/nim-binary-size/ https://hookrace.net/blog/nim-binary-size/ Nim on LLVM: https://github.com/arnetheduck/nlvm https://github.com/arnetheduck/nlvm
- def- 10y ago
  > I am still wondering why so few people use it. While Nim is my favorite language, I can understand that it has a small userbase, for these reasons: 1. No major backer like Google for Go or Mozilla for Rust 2. No killer feature like "memory safety and performance without GC" for Rust, instead a mix of all the reasonable down-to-earth features I want in a programming language 3. Some unique decisions instead of what you're used to from other languages, for example partial case sensitivity
  - untothebreach 10y ago
    I used both nim (back when it was still nimrod) and rust for a while, before eventually settling on rust. I tried to give nim a chance, and was told that "they will grow on you" ("they" being the things you mentioned that were "unique decisions instead of what you're used to from other languages"). They never did, and though I got used to avoiding the problems I initially had with them, the language just never "felt good" to me.
  - valarauca1 10y ago
    4. The fact that operator order is changed by the amount of white space between symbols 2+2 * 5 = 20 2 + 2 * 5 = 12

exDM69 10y ago

> That's good, but what causes the difference? Could it be startup time? That's less of an issue when the application has started up. A fibonacci application is not a very good benchmark anyway.

SparkyMcUnicorn 10y ago

From this quote it sounds like the more CPU intensive it is, the more you can expect when comparing to Ruby. >Remember: The cake is a lie, and so are benchmarks. You won’t have 35x increase in performance all the time, but you can expect 5x or more in complex applications, more if it’s CPU intensive.

igouy 10y ago

> I doubt it's representative of real performance-sensitive code Two data points (one-off timings of a few lines of code doing the same work load) just don't make for a comparison we should spend time bothering about. Whatever you think of the benchmarks game, I don't see why we need to waste time with comparisons that don't meet that low standard: - a few different tasks - more than a code snippet - a few repeat measurements - a few different workloads