On Friday, May 1, 2015 at 12:26:54 PM UTC+2, Scott Jones wrote: > > > > On Friday, May 1, 2015 at 4:25:50 AM UTC-4, Steven Sagaert wrote: >> >> I think the performance comparisons between Julia & Python are flawed. >> They seem to be between standard Python & Julia but since Julia is all >> about scientific programming it really should be between SciPi & Julia. >> Since SciPi uses much of the same underlying libs in Fortran/C the >> performance gap will be much smaller and to be really fair it should be >> between numba compiled SciPi code & julia. I suspect the performance will >> be very close then (and close to C performance). >> > > Why should Julia be limited to scientific programming? > I think it can be a great language for general programming, >
I agree but for now & the short time future I think the core domain of julia is scientific computing/data science and so to have fair comparisons one should not just compare julia to vanilla Python but especially scipi & numba. > for the most part, I think it already is (it can use some changes for > string handling [I'd like to work on that ;-)], decimal floating point > support [that is currently being addressed, kudos to Steven G. Johnson], > maybe some better language constructs to allow better software engineering > practices [that is being hotly debated!], and definitely a real debugger [I > think keno is working on that]). > > Comparing Julia to Python for general computing is totally valid and > interesting. > Comparing Julia to SciPy for scientific computing is also totally valid > and interesting. > > Similarly the standard benchmark (on the opening page of julia website) >> between R & julia is also flawed because it takes the best case scenario >> for julia (loops & mutable datastructures) & the worst case scenario for R. >> When the same R program is rewritten in vectorised style it beat julia see >> https://matloff.wordpress.com/2014/05/21/r-beats-python-r-beats-julia-anyone-else-wanna-challenge-r/ >> . >> >> So my interest in julia isn't because it is the fastest scientific high >> level language (because clearly at this stage you can't really claim that) >> but because it's a clean interesting language (still needs work for some >> rough edges of course) with clean(er) & clear(er) libraries and that gives >> reasonable performance out of the box without much tweaking. >> >
