On 5/12/14 3:44 AM, Alain Ketterlin wrote:
multiple-dispatch (i.e., dynamically testing types, converting to a
common type, and selecting the version of sqrt to use). That's probably
more than the time it takes to actually perform the computation, a bit
like what happens with x+y on integers with Python, where only a
fraction of time is spent on adding integers.
When you are doing scientific computation, this overhead is
unacceptable, because you'll have zillions of computations to perform.
I'm still trying to sort that out. I have not tested this yet, but
it looks like Julia is fully dynamic (yes it has types too), and it does
parallel processing at its core, so the zillions of computations are
being handled all at once, depending on how many processors|cores you have.
Julia provides a way to make things fast: typing. If you provide
explicit types, the dynamic typing part obviously disappears, and
the overhead is removed.
Julia is dynamic (depending on how far you want to go with that)
but what makes it fast is the JIT. It is almost accomplishing C/C++ and
FORTRAN speeds (even though dynamic) because it is compiling on-the-fly.
But then, you're not too far from Fortran, or C/C++.
Right. Again, this is really about the design goals and the JIT.
The following code will produce over 100,000 digits of π (pi) in less
than 2 seconds on a low-end processor, like my mac mini dual core
2Ghz: {snip}
You seem to be discovering the power of the libraries that are behind
all this (MPFR in that case)...
Yes, and more+ Gnu GMP & MPFR are not new to me, but the wrapper
and repl are ! I am just realizing the power behind the libraries in
this context, but I am very impressed with the functionality wrapped
around the Gnu stuff... the interface is quite nice.
But, like lisp, Julia's internal structures are lists, so, it can
create and modify its own code on-the-fly. [...]
Sorry, I was comparing to Fortran, and it's use in scientific computing.
Self modifying code is totally irrelevant there.
no, no, no... there has to be a value add for scientists to move
away from R or Matlab, or from FORTRAN. Why go to the trouble? FORTRAN
works well (its fast too), and there are zillions of lines of code
cranking away on huge linear arrays. Enter Julia... over the next ten
years; seriously. Because of the value adds!
Why?, glad you asked. Enter self modifying code for one. The
influence of Lisp|Scheme is potentially huge here. For scientific
computing the reason for making the switch is that the array functions
being calculated now in FORTRAN can be calculated (as fast) but more
elegantly with Julia; because the language has the ease of use of
Python, the stats of R, the array capabilities of MatLab (on steroids)
and the almost speed of C/C++ (all together in one package). There is
enough of a value add in this language to make FORTRAN users (also NumPy
SciPy) take notice.
Yes, its on a development curve right now (very much beta); but very
much out there with some serious capability --- right now. It will take
some time to mature, but I really think this language has the potential
to be around for a long long time. There needs to be some serious bench
marking on the parallel processing model, and there needs to be some
uptake on the user base to find out what 'they' really need from it, but
I think this dev group is on the ball. (maybe a little too smart for
their own good, we'll see)
I noticed from the MIT videos
http://julialang.org/blog/2013/03/julia-tutorial-MIT/ from a year ago
that the project has grown with leaps and bounds... but, there is very
much an intellectual edge here vs. a usability edge... um, the computer
scientists are still very much in control. It might be time for a
larger user group to get involved with the development direction, and
code base.
I agree with D'Aprano that languages come and go. But I think Julia
is different... like Python... for the scientific community; seriously.
And, if they really are working together with certain Python group(s) to
merge technologies, this could be big for years to come!
I'm excited about it.
Don't get me wrong anybody, I'm still a Pythonista! :)
marcus
--
https://mail.python.org/mailman/listinfo/python-list
