3 ms·

@1) Is it? [0] seems to indicate that it is usually about twice as slow as C and sometimes fares much worse. Of course, that article is over a year old by now s

@1) Is it? [0] seems to indicate that it is usually about twice as slow as C and sometimes fares much worse. Of course, that article is over a year old by now so maybe there are improvements, but if I can get a 2x performance gain ‘just’ by writing in C/C++, I will certainly do so. [0] http://justindomke.wordpress.com/2012/09/17/julia-matlab-and-c/#results http://justindomke.wordpress.com/2012/09/17/julia-matlab-and...

pessimizer 13y ago
Are you making a case here that Matlab and R should never be used?
svantana 13y ago
Note that one of the benchmarks take 5 ms in c -- if that's all you're trying to compute, why care about speed at all? And of course JIT will be a huge penalty on that time scale. There are a bunch of benchmarks on the front page of http://julialang.org/ http://julialang.org/ that show only a small penalty for using julia over c.
thinkpad20 13y ago
There's almost always a performance tradeoff when choosing to use some other language than C/C++; how much of a performance cost is the key question. If it's consistently within a factor of 2 of C performance, that's actually quite good, considering all of the high-level benefits you get out of it.
RivieraKid 13y ago
Compared to Python or MATLAB? Yes. 2x slower than C is amazing for a high-level and dynamic language. But of course, if performance is critical, C/C++ may be the better choice.
klibertp 13y ago
Wait, what? 2x slower than C is slow? And 2x performance gain is worth dropping from high to low-level programming? In what world, I'd like to ask? Do you frequently "just" write programs in asm to get additional performance gains? It could well be that you really need every bit of performance; what I want to say is that areas where "2x slower than C" are few and far in between.
- claudius 13y ago
  Numerical calculations (e.g. DMRG) on large systems easily take days, if not weeks, to converge sensibly. At the same time, the algorithms can be implemented in a relatively small amount of code (500 sloc in the Python prototype with some help from Numpy and Scipy, about 10k in C++). So, yes, if code can be reused later on and spending a month rather than a week writing it will save you many thousand hours of CPU time, it might well make sense not to use some high-level language (although I wouldn’t classify C++11 as low-level, albeit sometimes a bit verbose).
  - relate 13y ago
    I really don't get debates like this. You should simply account for the (a) time it takes to write the program AND (b) the time it takes to run the program. Selecting a language only based on (b) is clearly suboptimal.

pessimizer 13y ago

Are you making a case here that Matlab and R should never be used?

svantana 13y ago

Note that one of the benchmarks take 5 ms in c -- if that's all you're trying to compute, why care about speed at all? And of course JIT will be a huge penalty on that time scale. There are a bunch of benchmarks on the front page of http://julialang.org/ http://julialang.org/ that show only a small penalty for using julia over c.

thinkpad20 13y ago

There's almost always a performance tradeoff when choosing to use some other language than C/C++; how much of a performance cost is the key question. If it's consistently within a factor of 2 of C performance, that's actually quite good, considering all of the high-level benefits you get out of it.

RivieraKid 13y ago

Compared to Python or MATLAB? Yes. 2x slower than C is amazing for a high-level and dynamic language. But of course, if performance is critical, C/C++ may be the better choice.

klibertp 13y ago

Wait, what? 2x slower than C is slow? And 2x performance gain is worth dropping from high to low-level programming? In what world, I'd like to ask? Do you frequently "just" write programs in asm to get additional performance gains? It could well be that you really need every bit of performance; what I want to say is that areas where "2x slower than C" are few and far in between.

claudius 13y ago
Numerical calculations (e.g. DMRG) on large systems easily take days, if not weeks, to converge sensibly. At the same time, the algorithms can be implemented in a relatively small amount of code (500 sloc in the Python prototype with some help from Numpy and Scipy, about 10k in C++). So, yes, if code can be reused later on and spending a month rather than a week writing it will save you many thousand hours of CPU time, it might well make sense not to use some high-level language (although I wouldn’t classify C++11 as low-level, albeit sometimes a bit verbose).
- relate 13y ago
  I really don't get debates like this. You should simply account for the (a) time it takes to write the program AND (b) the time it takes to run the program. Selecting a language only based on (b) is clearly suboptimal.