3 ms·

This is completely and totally meaningless. It's excluding compiler time, and it's only outputting a single number. As such, there's nothing preventing any of

This is completely and totally meaningless. It's excluding compiler time, and it's only outputting a single number. As such, there's nothing preventing any of the optimizing compilers from optimizing the entire program to essentially print("pi<num> = <num>"). Ditto, time to load interpreters is included, whereas time to load compilers is excluded. Also, note that the output is different in format for the different languages. On a different note: he mentions PyPy in passing but doesn't post benchmark numbers. It'd be interesting to see how PyPy fares, especially with the slower-in-Python idiomatic version.

gilgoomesh 11y ago
PyPy is on the graph (dotted mustard line between Javascript and Ruby).
- TheLoneWolfling 11y ago
  It seems to have been added after I made the comment.
  - tptacek 11y ago
    No. https://web.archive.org/web/20150423220114/https://bjpelc.wordpress.com/2015/01/10/yet-another-language-speed-test-counting-primes-c-c-java-javascript-php-python-and-ruby-2/ https://web.archive.org/web/20150423220114/https://bjpelc.wo...
userbinator 11y ago
As such, there's nothing preventing any of the optimizing compilers from optimizing the entire program to essentially print("pi<num> = <num>"). That has clearly not happened here. If it did, you would see a flat line regardless of n. Nevertheless it is a good idea to make it e.g. take n as a commandline parameter, even if only to make testing different values easier. Ditto, time to load interpreters is included, whereas time to load compilers is excluded. You don't have to load the compiler every single time you run the program, whereas that isn't the case with an interpreter. Also, note that the output is different in format for the different languages. It's performing a single output operation at the very end of the computation. Any difference in that would be completely lost in the noise as n increases and the computation time dominates. On a different note: he mentions PyPy in passing but doesn't post benchmark numbers PyPy is there between JavaScript and Ruby: https://bjpelc.files.wordpress.com/2015/01/graph3.png https://bjpelc.files.wordpress.com/2015/01/graph3.png
- deleted 11y ago
  [deleted]
  - deleted 11y ago
    [deleted]
copsarebastards 11y ago
> It's excluding compiler time, and it's only outputting a single number. As such, there's nothing preventing any of the optimizing compilers from optimizing the entire program to essentially print("pi<num> = <num>"). Ditto, time to load interpreters is included, whereas time to load compilers is excluded. Who cares? This covers real world cases. If an optimizing compiler could actually figure out to optimize those programs to a printf() call, that would be an impressive level of optimization and I'd want to know about it (note that no optimizing compiler achieved that level of optimization). Likewise, I don't know about you, but when I run interpreted code, I often start by loading an interpreter. If you want to profile a different use case, do it, but that doesn't mean profiling these cases is "completely and totally meaningless".

gilgoomesh 11y ago

PyPy is on the graph (dotted mustard line between Javascript and Ruby).

TheLoneWolfling 11y ago
It seems to have been added after I made the comment.
- tptacek 11y ago
  No. https://web.archive.org/web/20150423220114/https://bjpelc.wordpress.com/2015/01/10/yet-another-language-speed-test-counting-primes-c-c-java-javascript-php-python-and-ruby-2/ https://web.archive.org/web/20150423220114/https://bjpelc.wo...

userbinator 11y ago

As such, there's nothing preventing any of the optimizing compilers from optimizing the entire program to essentially print("pi<num> = <num>"). That has clearly not happened here. If it did, you would see a flat line regardless of n. Nevertheless it is a good idea to make it e.g. take n as a commandline parameter, even if only to make testing different values easier. Ditto, time to load interpreters is included, whereas time to load compilers is excluded. You don't have to load the compiler every single time you run the program, whereas that isn't the case with an interpreter. Also, note that the output is different in format for the different languages. It's performing a single output operation at the very end of the computation. Any difference in that would be completely lost in the noise as n increases and the computation time dominates. On a different note: he mentions PyPy in passing but doesn't post benchmark numbers PyPy is there between JavaScript and Ruby: https://bjpelc.files.wordpress.com/2015/01/graph3.png https://bjpelc.files.wordpress.com/2015/01/graph3.png

deleted 11y ago
[deleted]
- deleted 11y ago
  [deleted]

copsarebastards 11y ago

> It's excluding compiler time, and it's only outputting a single number. As such, there's nothing preventing any of the optimizing compilers from optimizing the entire program to essentially print("pi<num> = <num>"). Ditto, time to load interpreters is included, whereas time to load compilers is excluded. Who cares? This covers real world cases. If an optimizing compiler could actually figure out to optimize those programs to a printf() call, that would be an impressive level of optimization and I'd want to know about it (note that no optimizing compiler achieved that level of optimization). Likewise, I don't know about you, but when I run interpreted code, I often start by loading an interpreter. If you want to profile a different use case, do it, but that doesn't mean profiling these cases is "completely and totally meaningless".