Yes, we are definitely very acutely aware of these. Julia is not currently optimized for frequently run short scripts. That's the price on pays for having to bring up the entire runtime system (initializing the compiler, RNG, external libraries etc). The good news is that there will be a solution to this soon, which is to statically compile your julia program. The area where this really comes up for most people using is package load times. We're very actively working on making that faster.
- Syntax
A little subjective, so not sure how much I can say here. I can say that I'm not a huge fan of our multi-line comment syntax. It's not entirely clear what a better syntax would be though (the original issue on this had some suggestions, but some of them were worse).
- One-based indexing
I think there has been plenty said on this topic, though interestingly this is one of the only times I've seen the argument made in a way that I actually agree with. That said, I do think there is an easy way to deal with this though. For packages that needs arrays of indices, it would be quite easy to define an `IndexArray` type that does the translation automatically.
- String Formatting
Yep, you're right, it's a mess. It'll have to be cleaned up.
- Unsafe C Interface
There's two projects (Clang.jl and Cxx.jl) which can help with this. The former automatically generates ccall definitions for you, the latter just parses the header and generates the call directly.
- Slowing down in development
I'm really not sure where that impression comes from. Perhaps it is that we're adding fewer features, but rather working on cleaning up existing features. Also, I personally at least have been doing a lot of work outside
of base (particularly on the debugger). Not sure. Would love to know.
Thanks for the detailed response. I hope that my post wasn't too harsh, the intent was mostly to attract attention to the current issues not to undermine the great work that you and others have been doing. I'm glad that many of the issues that I mentioned are being addressed. Maybe I'll give Julia another go in some time =).
The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd definitely like to see more influence of the first two and less from the last one.
One-based indexing is also used in Fortran, which seems to be used in a great deal of numerical computing even today. Additionally, BLAS/LAPACK is an important linear algebra library written in Fortan.
I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?
I liked how the Template Numerical Toolkit implemented one-based indexing:
// Construct matrix. Elements are not initialized.
// To initialize all elements to zero use
// Matrix<double> a(2, 2, 0.0).
Matrix<double> a(2, 2);
// Assign elements to first row using
// Fortran-style one-based indexing.
a(1,1) = 0.5; a(1,2) = 1.0;
// Assign elements to second row using
// C-style zero-based indexing.
a[1][0] = 1.5; a[1][1] = 2.0;
This syntax is available in julia as well, but I'm not sure it's a great idea to encourage mixing the two indexing behaviors, even if they have different syntax. As I hinted
in the original reply, I have seen very few cases where the
choice of index offset actually makes a difference. For
example, loops over indices generally use `eachindex` which doesn't care about your choice of index base.
Keno - take a look at what I did in https://github.com/ScottPJones/StringUtils.jl (building on the backs of giants, such as Tom Breloff, Dahua Lin, and others, incorporating some code from Formatting.jl). It solves problems I've had both with string literals, formatting, and outputting funny Unicode characters (without having to use UTF-8 in my source code).
I really like your Cxx.jl, that does seem to answer the issue raised here (are there any good features in pybind11 though that aren't already in Cxx.jl? that might be a good source for ideas on how to improve Cxx.jl if not)
For better or worse, most development discussion happens on GitHub rather than julia-dev. I've been catching up on GitHub threads recently, and the progress towards 0.5 is really impressive -- both in the language itself, and in the tooling (especially the debugger). I think the nature of priorities has changed somewhat as the language matures, but I disagree that development has slowed. (disclosure: I'm a Julia committer, but have been a bit out of the loop for some months now)
There is certainly a need for better interim communication on progress between releases, to let people know what is happening without reading every GitHub thread.
No summer of code students have had projects that involved work primarily on the core language since 2013. Not that many posts happen on julia-dev because most of the development communication happens on github.
I do think it's seasonal, however not connected to GSoC. Many of the major contributors are (or were) students (Julia seems to be detrimental to people finishing their PhDs, except in the case of Jeff Bezanson, where in some sense he crowdsourced a lot of the research, as Julia was the topic of his thesis ;-) ) Many who aren't students are professors. Definite drop off when people are taking classes, exams, teaching, etc.
Might be as simple as creating a static and dynamic profile for Julia. I suggested this to developers of one language project before. Maybe Julia. A single keyword or declaration near top of the file tells it to compile for fast loading with no need for functions that change things at runtime. Or compiler option.
We do have various compiler flags, but the problem on startup is the initialization of external libraries and deserialization of the system image, primarily.
The thing about 1 based indexing is that it's a kind of in your face "this is different" decision from the point of view of a programmers of most popular languages. To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions. It's not that I think they are incompetent but it's clear they care way more about some different world than about my programming world and are ready to make my life miserable stating the point.
Now, I don't know if people from that different world (Fortran, Matlab, some other languages used in academia maybe) would feel the same way about 0 based indexing but it certainly sends the message to programmers outside those domains.
To be honest I wouldn't want to start investing my time into a language where people who proposed 1 based indexing are making design decisions.
Possibly because you're used to working with languages like C, C++, Java, Pascal, Javascript, Python, etc. But in the world of languages tied closely to scientific / mathematical programming (Matlab/Octave, R, etc.) 1-based indexing is the norm. If you'd "grown up" so to speak, in that world, you'd probably find 0-based indexing distasteful.
You shouldn't be so biased. Having one based indexing makes translating numerical recipes from pure math textbooks (where vectors and matrices are generally one-based) simpler and less error prone. I say this as someone who chafes at Julia's one based indexing as a matter of professional practice.
I don't really get the difference. I'm in academia i guess (grad school) and use MATLAB a bunch, as well as Python (not a CS major). I don't think it's that much work to switch between the two, and I don't understand why there's such a division. Why is this such a huge deal?
Does 1 based indexing actually matter? It does if you are doing index arithmetic for rolling your own multidimensional arrays for example, but one shouldn't do those kind of things anyway.
I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. Also the policies for inclusion of features, how to propose features, how decisions are made with respect to the code base, etc. all seem poorly documented.
> I think part of this problem is the community, multiple people have reported having bad interactions with core language devs.
I can only think of a couple of instance where I've heard anything like this.
The first and most prominent is Dan Luu. I'm very sad about losing him from the community. I've met him a couple of times in person, I still read his blog and I very much respect him. I don't think any of us have the full story of what happened there, but I sincerely hope that time may be able to smooth things over.
The second was in an HN comment that I just went back to find, and discovered that is was you. I'm sorry if you had a bad experience with the community. I know my perspective is biased, but I've rarely interacted with a community that's as passionate, helpful and friendly as the julia community (LLVM is up there as well).
As for documenting the process, I agree there could be some improvement there. We do have a contributors guide (CONTRIBUTING.md in the main repository). As for policies for feature inclusion, we've considered having more formal code owners for parts of the code base (right now there's mostly de facto code owners for various parts), but haven't found it necessary so far. I definitely expect some of this to be discussed at JuliaCon in June.
I can only speak for myself, I attended an evening "getting started with Julia" event at MIT a few years ago, the devs there were very tolerant of me not being able to do some of the exercises and sat with me and helped me understand. Then they gave me Pizza. I've moaned sometimes about some of the decisions that they've made and they have always responded to me and showed me that they have a good reason for doing what they are doing - even if I still think that might be wrong.
I have never had a bad interaction with the core language devs. OTOH, they are passionate about the language; I've found all the core developers I've met very helpful.
Libraries? Sure. Ease of development, I cannot comment on.
But measuring performance with timing a "hello world" program? Seriously? What scenario does the author have in mind that makes this particular benchmark even remotely relevant?
The rest of the rant pretty much comes down to "it doesn't look like Python" (which is IMO a good thing, and I would certainly not call Python a "de facto standard of numerical computing" -- sure, it's there, but I still see a lot more of R and Matlab -- and note how both have 1-based indexes.)
To be fair, last time I checked, Julia definitely had some catching up to do in a few areas to become a real competitor to those two, but "hello world" benchmarks would not be among these.
It's been a little while though, and I am tempted to check again -- leaving libraries alone for the moment, does vectorization still result in a lot of performance loss compared to loops?
> But measuring performance with timing a "hello world" program? Seriously? What scenario does the author have in mind that makes this particular benchmark even remotely relevant?
If Julia is to replace Python in scientific computing, people will want to use it for short plotting scripts. Startup time matters there. That hello world is so slow is already telling. A plotting script needs tens of seconds just to load the Julia libraries.
I had also the feeling the "benchmark" is a joke. Even if it takes some seconds to print hello, speed is only important when you run big programs with million of operations.
If it takes a system 300ms to compile a function that prints "hello" then imagine how long it would take to compile a function that does something more sophisticated.
The "hello" benchmark is a fantastic benchmark for production-strength JIT-based runtimes because it tells you how long it takes for your system to warm up enough to be able to print something to the screen. You don't want this to be long. I prefer for "hello" to take about 10ms or less. In WebKit we have a few benchmarks that are the moral equivalent of "hello" and these are some of our most important benchmarks.
The reason why warm-up time is so insanely important is that any programming language, no matter what the domain is, will be used for the following things eventually:
- Tests.
- Data definitions in your language (moral equivalent of JSONP - every language/runtime has to deal with something like this).
- Initialization.
All of these things comprise run-once code that tends to be large. All of these things are important, even in math languages. The glorious "hello" benchmark is an excellent proxy for the performance of these kinds of code. So, I think that if Julia requires 300ms to run "hello" then they should make the "hello" benchmark into their primary optimization target.
Although we have since moved to using B3, LLVM was absolutely amazing for us, for the same reasons why it's amazing for Julia: you get tons of optimizations for a lot of targets with little effort. But you have to harness this power the right way. You can't fire up the full LLVM pipeline for code that runs once! It's a waste to unleash so many optimizations only to immediately throw away the result.
I know R and have used Octave. I started learning Julia this morning after a physicist recommended it to me after he switched from python. I used Jupyter/Julia to simulate a neuron as a practice exercise. This is my experience as a beginner:
1. The static typing makes a big and positive difference. Its nice having a statically typed repl.
2. The documentation is good.
3. Using unicode symbols and \mu style tab completion is nice, especially in Jupyter where you can use the same symbols in latex style equations.
4. The base install is a bit bare. It would be nice if batteries were included - distributions and dataframes in particular.
5. R uses 1 based indexing and it was no shock to see this in Julia.
6. I had no problems with the mix of lisp and C++ in the source code. The lisp implementation is beautiful and worth a read.
Generally, I was shocked to see a blog post like this given that my first day with Julia was so positive.
I think the problem here is the library approach. They should break stuff out of Julia's core library and move them into default included libraries (like python does).
Yes they should, and that is exactly what is happening in Base, and has been happening for a while. A project like Julia doesn't have too much dev time input, so you cannot expect this to happen over night.
I'm genuinely surprised that one would say that Julia is "slowing down in development". Perhaps it's because less press is being generated about Julia? Or that the commit rate has gone down slightly, now that the easier issues have been picked off and the remaining work will take longer for the next round of incremental developments? I'm not sure what the OP meant, but from the inside, we are busier than ever.
- Both Julia Computing and the Julia Lab have grown sizably over the past two years. The Lab now houses ten full-time researchers (up from four last year), with five new students coming online over the summer and fall. We also maintain more active research collaborations with more research groups at MIT and off-campus.
- Julia is a grateful recipient of 12 Google Summer of Code slots this year, compared to 8 for 2015's Julia Summer of Code program (sponsored by the Moore Foundation) and 4 for GSoC 2014.
- JuliaCon grew from 72 attendees in 2014 to 225 in 2015 and we are on track to meet or exceed last year's ticket sales for 2016.
- New packages continue to be registered on the central METADATA repository at roughly the same rate since June 2014. http://pkg.julialang.org/pulse.html
By some measures we are still a relatively small project, but I don't see any serious evidence for the imminent heat death of the Julia universe.
For many users of Julia, long-running performance matters more than microbenchmarks. Having converted a naively written Python program to Julia (there was a huge amount of computation being done over a large search space), I experienced a massive speedup even against PyPy. My Python scripts ran for about 10 hours before I called it quits (.6% of the work had been completed). Converting to Julia allowed me to finish within 3-4 hours, AND it was easy to parallelize.
Just how naively was the Python written? ~1600 hours vs. 4 hours of execution time sounds like some extremely naive starting code. Is it fair to even compare them?
The Julia version was a literal translation of the Python version, the only difference being that I changed the entry point in the Julia version to allow restarting searches in different ranges. That made parallelization very easy, which is where I got most of time saved. I distributed the work across 3 machines. However, even without parallelization, the Julia version progressed much further than either CPython or PyPy. I also attempted a C version before Julia, but I ran into some issues, which Julia handled without me having to write extra code (int128 support out of the box, and various functions for prime numbers). The int128 support was the main reason I didn't write it in C, as I came across a lot of contradictory information online for __int128 in Clang or GCC.
Correct, I was not using Numpy. I did not think of a good way to fit my program into a Numpy shaped solution. The main point is that I didn't NEED to try, as an almost literal translation to Julia worked much better. I also did not try using Numba, which I suspect would have given me similar results to Julia. I am a fan of Python overall, but sometimes you just need to choose a tool that gets the job done with the least mental effort expended on the tool. This was a one-time script that needed to be written, no maintenance was needed: I just needed an answer, and within a certain amount of time.
Not sure why this is on the front page because the criticism in this article is fairly superficial. Julia was designed for scientific computing and interpreter start-up time doesn't matter at all in this context, especifically the start-up time of hello-world. Baseline memory consumption isn't an issue either and one-based indexing is simply something to get used to. If this stops you from being productive, it's not the language's fault. The comments about the syntax remind me of all those people saying Lisp is a bad language because it has too many parentheses.
But, I think judging a language (which claims math and scientific computing is it's strongest point) by print screen performance is not fair.
And, the authors last example is a little bit misleading I think. The C code sets up registers and jumps to the main sprintf routine. I don't know why didn't he tell that routine's instructions count...
I'm not bothered by "hello world" performance myself, and I my recent issues with Julia have been caused by rapid development meaning that when I had to put it down for a few months lots of things I had done (because I'm mortal) stopped working. I wrote this off to "it's 0.x, getoverit". I've never tried complex text formatting in Julia either! My concerns are more focused on the type system (this I love) and performance for massive computation (I've still not managed to persuade my Hadoop admin to put julia images across our cluster, but I suppose I might win the argument one day!)
Yeah the poor performance in this blog post is a total misunderstanding of why and how julia is performant. Is printing "hello world" fast really that important? OK. Then don't use Julia.
You pay for it by having the compiler JIT the code in a highly optimized fashion. If you have actual numerical calculations that are compile-once, run-many-many-many-times, then you will see a huge performance benefit, amortizing the cost of expensive compilation and optimization that happens once at the beginning of the program cycle.
The very title of what he links to "How To Make Python run as fast as Julia" betrays the problem. The goal of Julia is to not have to do that sort of boilerplate/arcane tweaking to get really good performance - the system will do it out of the box.
I'll have to disagree with the notion that Julia is hard to read. I'm currently deploying Julia to run automated hardware verification on a computer chip. Effectively, I've written a DSL using Julia macros that generates assembly code files, compiles, and executes it, and my coworkers (who do not use julia) have found it easy to read my code and understand what's going on. Far easier, in any case, than the equivalent C code using asm blocks.
I do agree about the one-based indexing. I get it, it's what matlab does. But it would be nice to say, be able to throw an option at the top of a program that forces the appropriate indexing.
> If you have actual numerical calculations that are compile-once, run-many-many-many-times, then you will see a huge performance benefit
I agree, and I haven't found anything like this in other (non-exotic) languages. I recently wrote a function using the @generated macro to produce Wigner-D matrices via the recursion relations. The function dispatches on the size of the matrix (using Type{Val{N}}) and after it compiles once for a particular value of N, all future calls are blazing fast (since the machine code is essentially just a long list of multiply and add instructions).
>The goal of Julia is to not have to do that sort of boilerplate/arcane tweaking to get really good performance
As someone who is new to python (for bioinformatics), and find python is a fine language... but..
The do it "this way not that way" method of implementation of the same algorithms to get it to run fast makes writing performant python a tedious exercise in research and profiling. The article cited suggests Cpython, numby and numpy [1] as ways to make it faster.
Why not C using GPU acceleration as the time spent coding would probably be the same? Thats what I love about plain python, its fast to write and has some good data structures.
I haven't tried Julia, but someday its on my list of languages to learn more about.
But this is a false choice. Mature JIT-based systems give you the best of both worlds by starting in an interpreter and then switching to a JIT on a per-function basis as code gets hot.
I wouldn't be bothered about it either if the language, like Java, targeted more the development of long-running services rather than interactive applications (with some exceptions like mobile). But as far as I can see it is advertised for use in interactive applications, possibly as a Python alternative, where responsiveness is important.
I haven't got the same perception - I think it's aimed at things like simulator and solvers. Those things tend to have front ends (that is true) but not front ends that support 100's of users.
Readit News
The question of syntax is subjective of course. From the set {C-like, Python, MATLAB} I'd definitely like to see more influence of the first two and less from the last one.
I am somewhat confused by your discussion of startup times. Since Julia is a "programming language for technical computing", what scenario are you imagining where startup times would be a significant concern?
One based indexing falls apart if you have to index a region of storage as bits, bytes and words at the same time.
I really like your Cxx.jl, that does seem to answer the issue raised here (are there any good features in pybind11 though that aren't already in Cxx.jl? that might be a good source for ideas on how to improve Cxx.jl if not)
(just to add: there is currently an open pull request from a core array-focused developer adding such support to base)
There is certainly a need for better interim communication on progress between releases, to let people know what is happening without reading every GitHub thread.
Now, I don't know if people from that different world (Fortran, Matlab, some other languages used in academia maybe) would feel the same way about 0 based indexing but it certainly sends the message to programmers outside those domains.
Possibly because you're used to working with languages like C, C++, Java, Pascal, Javascript, Python, etc. But in the world of languages tied closely to scientific / mathematical programming (Matlab/Octave, R, etc.) 1-based indexing is the norm. If you'd "grown up" so to speak, in that world, you'd probably find 0-based indexing distasteful.
Deleted Comment
I think part of this problem is the community, multiple people have reported having bad interactions with core language devs. Also the policies for inclusion of features, how to propose features, how decisions are made with respect to the code base, etc. all seem poorly documented.
I can only think of a couple of instance where I've heard anything like this.
The first and most prominent is Dan Luu. I'm very sad about losing him from the community. I've met him a couple of times in person, I still read his blog and I very much respect him. I don't think any of us have the full story of what happened there, but I sincerely hope that time may be able to smooth things over.
The second was in an HN comment that I just went back to find, and discovered that is was you. I'm sorry if you had a bad experience with the community. I know my perspective is biased, but I've rarely interacted with a community that's as passionate, helpful and friendly as the julia community (LLVM is up there as well).
As for documenting the process, I agree there could be some improvement there. We do have a contributors guide (CONTRIBUTING.md in the main repository). As for policies for feature inclusion, we've considered having more formal code owners for parts of the code base (right now there's mostly de facto code owners for various parts), but haven't found it necessary so far. I definitely expect some of this to be discussed at JuliaCon in June.
But measuring performance with timing a "hello world" program? Seriously? What scenario does the author have in mind that makes this particular benchmark even remotely relevant?
The rest of the rant pretty much comes down to "it doesn't look like Python" (which is IMO a good thing, and I would certainly not call Python a "de facto standard of numerical computing" -- sure, it's there, but I still see a lot more of R and Matlab -- and note how both have 1-based indexes.)
To be fair, last time I checked, Julia definitely had some catching up to do in a few areas to become a real competitor to those two, but "hello world" benchmarks would not be among these.
It's been a little while though, and I am tempted to check again -- leaving libraries alone for the moment, does vectorization still result in a lot of performance loss compared to loops?
If Julia is to replace Python in scientific computing, people will want to use it for short plotting scripts. Startup time matters there. That hello world is so slow is already telling. A plotting script needs tens of seconds just to load the Julia libraries.
Yes, but it should be fixed in the nearish future. https://github.com/JuliaLang/julia/issues/16285
The "hello" benchmark is a fantastic benchmark for production-strength JIT-based runtimes because it tells you how long it takes for your system to warm up enough to be able to print something to the screen. You don't want this to be long. I prefer for "hello" to take about 10ms or less. In WebKit we have a few benchmarks that are the moral equivalent of "hello" and these are some of our most important benchmarks.
The reason why warm-up time is so insanely important is that any programming language, no matter what the domain is, will be used for the following things eventually:
- Tests.
- Data definitions in your language (moral equivalent of JSONP - every language/runtime has to deal with something like this).
- Initialization.
All of these things comprise run-once code that tends to be large. All of these things are important, even in math languages. The glorious "hello" benchmark is an excellent proxy for the performance of these kinds of code. So, I think that if Julia requires 300ms to run "hello" then they should make the "hello" benchmark into their primary optimization target.
Fortunately, it's easy to make "hello" run fast: just tier your JIT. This can be done with LLVM just fine, see https://webkit.org/blog/3362/introducing-the-webkit-ftl-jit/
Although we have since moved to using B3, LLVM was absolutely amazing for us, for the same reasons why it's amazing for Julia: you get tons of optimizations for a lot of targets with little effort. But you have to harness this power the right way. You can't fire up the full LLVM pipeline for code that runs once! It's a waste to unleash so many optimizations only to immediately throw away the result.
1. The static typing makes a big and positive difference. Its nice having a statically typed repl.
2. The documentation is good.
3. Using unicode symbols and \mu style tab completion is nice, especially in Jupyter where you can use the same symbols in latex style equations.
4. The base install is a bit bare. It would be nice if batteries were included - distributions and dataframes in particular.
5. R uses 1 based indexing and it was no shock to see this in Julia.
6. I had no problems with the mix of lisp and C++ in the source code. The lisp implementation is beautiful and worth a read.
Generally, I was shocked to see a blog post like this given that my first day with Julia was so positive.
I think the problem here is the library approach. They should break stuff out of Julia's core library and move them into default included libraries (like python does).
- Both Julia Computing and the Julia Lab have grown sizably over the past two years. The Lab now houses ten full-time researchers (up from four last year), with five new students coming online over the summer and fall. We also maintain more active research collaborations with more research groups at MIT and off-campus.
- Julia is a grateful recipient of 12 Google Summer of Code slots this year, compared to 8 for 2015's Julia Summer of Code program (sponsored by the Moore Foundation) and 4 for GSoC 2014.
- JuliaCon grew from 72 attendees in 2014 to 225 in 2015 and we are on track to meet or exceed last year's ticket sales for 2016.
- New packages continue to be registered on the central METADATA repository at roughly the same rate since June 2014. http://pkg.julialang.org/pulse.html
By some measures we are still a relatively small project, but I don't see any serious evidence for the imminent heat death of the Julia universe.
This is what is killing me when I use Python. So hard to run things in parallel.
I have had luck with Go trying to do this and set up a concurrent application.
But, I think judging a language (which claims math and scientific computing is it's strongest point) by print screen performance is not fair.
And, the authors last example is a little bit misleading I think. The C code sets up registers and jumps to the main sprintf routine. I don't know why didn't he tell that routine's instructions count...
Has any one counted?
You pay for it by having the compiler JIT the code in a highly optimized fashion. If you have actual numerical calculations that are compile-once, run-many-many-many-times, then you will see a huge performance benefit, amortizing the cost of expensive compilation and optimization that happens once at the beginning of the program cycle.
The very title of what he links to "How To Make Python run as fast as Julia" betrays the problem. The goal of Julia is to not have to do that sort of boilerplate/arcane tweaking to get really good performance - the system will do it out of the box.
I'll have to disagree with the notion that Julia is hard to read. I'm currently deploying Julia to run automated hardware verification on a computer chip. Effectively, I've written a DSL using Julia macros that generates assembly code files, compiles, and executes it, and my coworkers (who do not use julia) have found it easy to read my code and understand what's going on. Far easier, in any case, than the equivalent C code using asm blocks.
I do agree about the one-based indexing. I get it, it's what matlab does. But it would be nice to say, be able to throw an option at the top of a program that forces the appropriate indexing.
I agree, and I haven't found anything like this in other (non-exotic) languages. I recently wrote a function using the @generated macro to produce Wigner-D matrices via the recursion relations. The function dispatches on the size of the matrix (using Type{Val{N}}) and after it compiles once for a particular value of N, all future calls are blazing fast (since the machine code is essentially just a long list of multiply and add instructions).
As someone who is new to python (for bioinformatics), and find python is a fine language... but..
The do it "this way not that way" method of implementation of the same algorithms to get it to run fast makes writing performant python a tedious exercise in research and profiling. The article cited suggests Cpython, numby and numpy [1] as ways to make it faster.
Why not C using GPU acceleration as the time spent coding would probably be the same? Thats what I love about plain python, its fast to write and has some good data structures.
I haven't tried Julia, but someday its on my list of languages to learn more about.
[1]https://www.ibm.com/developerworks/community/blogs/jfp/entry...