3 ms·

The "beauty of Ruby" part is self evident, assuming you find Ruby beautify. Is there any documentation to back up the "Faster than Go" statement? I compiled an

The "beauty of Ruby" part is self evident, assuming you find Ruby beautify. Is there any documentation to back up the "Faster than Go" statement? I compiled and tested the HTTP server example, and pounded on it with ab. I don't have enough time tonight do an in depth comparison, but it doesn't seem much faster than Go. On the plus side: the binaries are nice and small, and the memory usage is low.

sergiotapia 11y ago
Search for benchmarks and https://www.youtube.com/watch?v=xbdVs4FhZac https://www.youtube.com/watch?v=xbdVs4FhZac to see performance comparisons.
- msie 11y ago
  5:30 in they talk about benchmarks.
- wiremine 11y ago
  Thanks! I saw the benchmarks compare Crystal to Python, C, Ruby and C++, but I didn't see anything about Go. Which is fine, I guess, but it makes the title feel a bit link baity.
  - asterite 11y ago
    All the languages couldn't fit in the talk, but the full benchmarks are here: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks As always, take benchmarks with a graint of salt. We use benchmarks mostly to know how far away we are from C (1x, 10x, 100x, etc.), so any language that has a speed "in the order of" C is good enough for us, small differences don't matter much.
asterite 11y ago
The current HTTP server is pretty fast. Did you try compiling/running your program with the `--release` flag? It's explained a bit here: http://crystal-lang.org/docs/using_the_compiler/index.html http://crystal-lang.org/docs/using_the_compiler/index.html Crystal is faster than Go in some cases (mostly because we use LLVM and it optimizes really well), but right now Go has faster context switches between goroutines (in our case fibers) and in general faster concurrency (for example it distributes the goroutines across multiple threads, we are using one for now). But improving these is definitely on our roadmap and should be doable. More good news is that we are using Boehm GC and didn't spend a lot of time optimizing on our side (rather than just relying on LLVM), so a custom GC and more optimizations (like maybe escape analysis) could improve performance even more.

sergiotapia 11y ago

Search for benchmarks and https://www.youtube.com/watch?v=xbdVs4FhZac https://www.youtube.com/watch?v=xbdVs4FhZac to see performance comparisons.

msie 11y ago
5:30 in they talk about benchmarks.
wiremine 11y ago
Thanks! I saw the benchmarks compare Crystal to Python, C, Ruby and C++, but I didn't see anything about Go. Which is fine, I guess, but it makes the title feel a bit link baity.
- asterite 11y ago
  All the languages couldn't fit in the talk, but the full benchmarks are here: https://github.com/kostya/benchmarks https://github.com/kostya/benchmarks As always, take benchmarks with a graint of salt. We use benchmarks mostly to know how far away we are from C (1x, 10x, 100x, etc.), so any language that has a speed "in the order of" C is good enough for us, small differences don't matter much.

asterite 11y ago

The current HTTP server is pretty fast. Did you try compiling/running your program with the `--release` flag? It's explained a bit here: http://crystal-lang.org/docs/using_the_compiler/index.html http://crystal-lang.org/docs/using_the_compiler/index.html Crystal is faster than Go in some cases (mostly because we use LLVM and it optimizes really well), but right now Go has faster context switches between goroutines (in our case fibers) and in general faster concurrency (for example it distributes the goroutines across multiple threads, we are using one for now). But improving these is definitely on our roadmap and should be doable. More good news is that we are using Boehm GC and didn't spend a lot of time optimizing on our side (rather than just relying on LLVM), so a custom GC and more optimizations (like maybe escape analysis) could improve performance even more.