3 ms·

No because D has C performance, now. Have you seen the blog numbers?

by p0nce 13y ago

pkolaczk 13y ago
As pointed out in the other comments on this thread, this benchmark benchmarks mostly standard RNG performance, not quality of the code generated by each compiler. Here you've got much more computationally intensive benchmark, showing that D is "as fast as C" like it could be said about Java: http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/ http://attractivechaos.wordpress.com/2013/04/06/performance-... It is close, but Java is just as close, too. Not a tremendous performance advantage that someone would choose one over another for and not something I'd expect from a language marketed as "performance oriented".
- p0nce 13y ago
  Ok you live in a world where Java is "as fast as C". Let's terminate this discussion.
  - pkolaczk 13y ago
    I didn't say it. You said D was as fast as C now. Then, according to your definition of "as fast as C", Java must be fast as C as well. Seems your as fast as C definition must be something between 30%-95% performance of C because those are the most common performance numbers reported for D in various benchmarks (I cited one of them, and the one in the blog also confirms this - only one D compiler managed to match the best C compiler, the others were significantly behind). The same numbers are consistently reported about Java, so I don't really understand what you're arguing about. So I conclude both are the same league (with two minor exceptions: 1. I saw Java beating GCC many times, once quite severely by almost 2x on simple array numerical code, while I never saw that happening for D and 2. D has much worse GC implementation than Java or C# have).
  - strcat 13y ago
    In the real world it's not nearly as fast as C, but in a micro-benchmark like this with a bunch of loops crunching fixed-size integers it would come close. The difference in performance between the languages is almost entirely due to differences in the implementation of the benchmark.

No because D has C performance, now. Have you seen the blog numbers?

by p0nce 13y ago

No because D has C performance, now. Have you seen the blog numbers?

As pointed out in the other comments on this thread, this benchmark benchmarks mostly standard RNG performance, not quality of the code generated by each compiler. Here you've got much more computationally intensive benchmark, showing that D is "as fast as C" like it could be said about Java: http://attractivechaos.wordpress.com/2013/04/06/performance-of-rust-and-dart-in-sudoku-solving/ http://attractivechaos.wordpress.com/2013/04/06/performance-... It is close, but Java is just as close, too. Not a tremendous performance advantage that someone would choose one over another for and not something I'd expect from a language marketed as "performance oriented".

p0nce 13y ago
Ok you live in a world where Java is "as fast as C". Let's terminate this discussion.
- pkolaczk 13y ago
  I didn't say it. You said D was as fast as C now. Then, according to your definition of "as fast as C", Java must be fast as C as well. Seems your as fast as C definition must be something between 30%-95% performance of C because those are the most common performance numbers reported for D in various benchmarks (I cited one of them, and the one in the blog also confirms this - only one D compiler managed to match the best C compiler, the others were significantly behind). The same numbers are consistently reported about Java, so I don't really understand what you're arguing about. So I conclude both are the same league (with two minor exceptions: 1. I saw Java beating GCC many times, once quite severely by almost 2x on simple array numerical code, while I never saw that happening for D and 2. D has much worse GC implementation than Java or C# have).
- strcat 13y ago
  In the real world it's not nearly as fast as C, but in a micro-benchmark like this with a bunch of loops crunching fixed-size integers it would come close. The difference in performance between the languages is almost entirely due to differences in the implementation of the benchmark.