HOPE: The Ease Of Python With The Speed Of C++

[erendorn]

1) You're really naive. Fortran is faster than C which is faster than C++. Julia makes heavy use of the best of C and Fortran math libraries so it is close to Fortran performance.

Fortran is indeed faster than C and C++ because of forbidden aliasing.
The C subset of C++ is of course as fast a C (that has been shown by benchmarks of compiling C projects with C and C++ compilers, but as it's the exact same code, there's of course no reason that performance should be different).
The non-C features of C++ are faster than the same features handwritten in C, because the compiler optimize them. (So all in all, C is actually slower than C++)
Calls to libraries are pretty much the same regardless of language. Saying one language is faster because it can call Fortran libraries is silly.

[mmstick]

All the benchmarks I have seen put Julia's performance at about 6 times slower than C or C++. Do you have benchmarks showing Julia with better performance than C or C++ using the same libraires?

Benchmarks are on their website, as are links to the original source code for those benchmarks, Benchmarks are carried out regularly which is also charted on the website. http://julialang.org/benchmarks/

[TheBlackCat]

Benchmarks are on their website, as are links to the original source code for those benchmarks, Benchmarks are carried out regularly which is also charted on the website. http://julialang.org/benchmarks/

So it looks like pretty much everything is slower than C for Julia. I can't really see the axes on the plot, but it looks like one benchmark might be a bit faster (although looking at the C code I would be surprised if doing multiple type conversions at every step of the loop like that, which Julia doesn't do, is the fastest implementation).

[mmstick]

So it looks like pretty much everything is slower than C for Julia. I can't really see the axes on the plot, but it looks like one benchmark might be a bit faster (although looking at the C code I would be surprised if doing multiple type conversions at every step of the loop like that, which Julia doesn't do, is the fastest implementation).

The homepage for Julia shows actual numbers -- not sure how you missed that. It topples the C implementation in a few benchmarks even if it loses some. If you think their implemetation is not the same as Julia's, why not submit a patch?

In any case, C/C++/Python isn't nearly as convenient as Julia. Try doing these in the above:

# gratio returns the value of the golden ratio.
gratio() = (1 + 5^0.5) / 2

# fib prints the Nth fibonacci number(s).
fib(x::Int) = int((gratio()^x - (1-gratio())^x) / 5^0.5)
fib(range::UnitRange{Int}) = {fib(x) for x = range}
fib(array::Array{Int,1}) = {fib(x) for x = range}

# squared squares the input.
squared(x) = x^2
squared(numbers::Array) = {x^2 for x = numbers}
squared(numbers::UnitRange) = {x^2 for x = numbers}

# average returns the average.
average(x::Array) = sum(x) / length(x)

# digits returns the number of digits in the number.
digits(x::Int) = itrunc(log10(x)) + 1

[gamerk2]

You know the actual language used isn't a big huge factor in performance if coded optimally, right? The algorithms used is a much bigger factor in performance. Those algorithms might be sub-optimal for a given language however, due to language constraints. That's the main reason C is so bloody powerful, since you can essentially abuse the language half to death to squeeze out performance gains. I automatically disregard any argument of "language speed" as a result, unless someone can give me a specific task and a specific reason why one language is faster/slower then the other.

[TheBlackCat]

The homepage for Julia shows actual numbers -- not sure how you missed that. It topples the C implementation in a few benchmarks even if it loses some.

I did miss that. Although it only topples C for 2, and loses for 4.

If you think their implemetation is not the same as Julia's, why not submit a patch?

Because I have enough work to do submitting patches for actual features to software I actually use on top of my normal day job to spend time submitting improved benchmarks for software I don't use and don't particularly care about the benchmarks for. Again, performance is not my primary concern. Getting my work done is. And the performance of the glue language I use is not a major limiting factor for that.

In any case, C/C++/Python isn't nearly as convenient as Julia. Try doing these in the above:

You can do that in python too, with the added benefit of not confusing function calls or numeric assignment with anonymous function assignment. Matlab made a similar mistake with confusing array indexing with function calls which led to no end of problems. I am disappointed to see Julia doing something similar. That sort of thing simply would not be allowed in python, since making sure the code is clear and unambiguous is a major concern.

Whatever the case, those are all at least as easy in python:

# gratio returns the value of the golden ratio.
gratio = lambda: (1 + 5**0.5) / 2
# Or you could do the sane thing and just assign a float:
gratio = (1 + 5**.5)/2

# fib prints the Nth fibonacci number(s), also works for arrays
fib = lambda n: (gratio**n - (1-gratio)**n) / 5**0.5

# squared squares the input, also works for arrays
squared = lambda x: x**2

# average returns the average, also works for arrays
average = lambda x: sum(x) / len(x)

# digits returns the number of digits in the number.
from math import trunc, log10
digits = lambda x: trunc(log10(x)) + 1

Now try doing this in Julia. Assume "readdata" is some arbitrary data-reading function. This will work on any platform with any directory separator:

import os
from os.path import join, splitext
# read all the data files in the directory and all subdirectories and store them in a dictionary (mapping) based on their path if their file extension is ".h5", if not skip them
res = {}
for path, _, filenames in os.walk('.'):
    for fname in filenames:
        if splitext(fname)[1] == ".h5":
            fullname = join(path, fname)
            res[fullname] = readdata(fullname)

# or an equivalent, but less clear, one-liner
res = {join(path, fname): readdata(join(path, fname)) for path, _, filenames in os.walk('.') for fname in filenames if splitext(fname)[1] == ".h5"}

# or an anonymous function for an arbitrary directory and extension:
res = lambda dirname, ext: {join(path, fname): readdata(join(path, fname)) for path, _, filenames in os.walk(dirname,) for fname in filenames if splitext(fname)[1] == ext}
res('.', '.h5')

Or what if you wanted to scrape data from tables on a web page? Or access data stored on an online resource like google docs? Or plot multiple interactive graphs where the dragging one plot or one marker also moved others? Or access multiple I/O bound tasks asynchronously? Despite your criticism of Python not being focused enough on numerical computing, these sorts of things are easy to do in Python specifically because it is explicitly designed and used as a general-purpose programming language. Things like advanced HTML handling, advanced network interfaces, advanced graphics toolkit interaction, and advanced asynchronous I/O handling were not created for numerical computing, and you don't see them on languages designed primarily for numerical computing, but people doing numerical computing benefit from work like this done for other purposes.

[pal666]

My point is that the one line example you gave does not do the same thing.

of course it does

[pal666]

1) You're really naive. Fortran is faster than C which is faster than C++. Julia makes heavy use of the best of C and Fortran math libraries so it is close to Fortran performance.

you are really stupid. c++ makes heavy use of the best of C and Fortran math libraries so it is close to Fortran performance(which is not 'much faster'. and plain c, being almost strict subset, is not faster at all). also native c++ can be faster than fortran.

2) That's not the point. C++ is an ugly bloated mess of inconsistency that only someone with years of experience can properly understand. In the real world, people prefer simplification over complification. C++ needs to die sooner rather than later. C++ certainly isn't made for scientific computing either, which Julia is.

in real world nobody uses julia but everyone uses c++. may be that is because everyone has different needs and toy one-purpose language doesn't cut it ?

3) Again, irrelevant. There's no need to rewrite the bulk of code when you can import an existing Fortran/C library which you are probably already using in another language. Not to mention, because writing your code in Julia is easier to read and write you have more time to work on optimizing your algorithms.

Again, irrelevant. real programs are not few lines wrappers around some fortran library

4) Then don't be a dumbass and learn about it.

i will be dumbass if i will learn about every of thousands of one-purpose toy languages

[pal666]

of course it does

btw, isn't it funny that as soon, as you try to make fast python program, it turns out uglier than c++

[kigurai]

btw, isn't it funny that as soon, as you try to make fast python program, it turns out uglier than c++

Trying to do something "fast" in Python usually means implementing it in C or C++ and then wrapping it. So, I guess I could accept that it would be "at least as ugly as C++"