7 ms·

I can understand the need for new programming languages to be continually developed, especially with differing power continuums. So I have nothing against this

I can understand the need for new programming languages to be continually developed, especially with differing power continuums. So I have nothing against this post, or Julia itself. But when someone advertises that they want x feature and y feature in one language, such that the respective languages of x and y are essentially obsolete, I get a little skeptical. I'm certainly not the type of person who tries to vaguely advocate all languages are more or less the same and it's just taste; not at all. But I think there are reasons why it's intrinsically difficult to design a language to have both the speed of C and the abstraction power of Lisp, for example. Things come at a price; this doesn't mean there isn't generally a clear victor for what you're trying to do, just that getting a paragon of linguistic design is very difficult. But his test of Julia is promising, though honestly I'd really like to see a speed comparison on at least 100 lines of code, preferably a full application really.

StefanKarpinski 14y ago
Miles Lubin and Iain Dunning gave an excellent presentation at MIT's IAP tutorial on Julia in January where they benchmarked rather non-trival code for doing linear programming in a variety of languages: https://github.com/JuliaLang/julia-tutorial/blob/master/NumericalOptimization/presentation.pdf http://bit.ly/VQ9rDd (shortened version since that's cut off) See page 7, "Simplex Benchmarks". Essentially, they implemented the basics you need to do a fast simplex linear programming algorithm in each of C++, Julia, Matlab and Python. Their results were in line with the Julia home page benchmarks: Julia is between 1-2x slower than good C/C++ code. PyPy and Matlab are 10-20x slower. Python is 80-400x slower. The code can be found here: https://github.com/mlubin/SimplexBenchmarks These results are fairly typical.
- dylangs1030 14y ago
  1-2x slower is still remarkable given what Julia (apparently) has the power to do. Thanks for the citations!
- pygy_ 14y ago
  Remove the four spaces before the long URL, it will be properly displayed and linkified. Meanwhile: https://github.com/JuliaLang/julia-tutorial/blob/master/NumericalOptimization/presentation.pdf https://github.com/JuliaLang/julia-tutorial/blob/master/Nume... https://github.com/mlubin/SimplexBenchmarks https://github.com/mlubin/SimplexBenchmarks
- qznc 14y ago
  I think there should be a Python+NumPy variant for comparison as well.
  - mlubin 14y ago
    I've added a bit of an explanation as to why there's no NumPy version.
    - qznc 14y ago
      SciPy does have some sparse support. http://www.scipy.org/SciPyPackages/Sparse http://www.scipy.org/SciPyPackages/Sparse
BruceM 14y ago
It is hard ... OpenDylan (http://opendylan.org/ http://opendylan.org/) manages to mostly pull it off when the right type information is available. It could be smarter at times, but it does pretty well. In a recent test for someone, they had code running in C++ in 0.5 seconds, Dylan in 0.6. Our major performance loss in OpenDylan comes when there's still too much generic dispatch going on, but that can usually be reduced through various mechanisms. (And as I said above, there's still avenues where the compiler could do better.) Another interesting implementation is Gambit Scheme which manages to pull off some really impressive feats of compilation for performance once you declare '(not safe)' although it is still fast with safety enabled.
- dylangs1030 14y ago
  Bruce, what is your association with OpenDylan? (It feels odd referring to a language that shares my name, ha). What are Dylan's strengths and weaknesses? And what you say about Scheme is believable, though I wouldn't use Scheme personally as I prefer Lisp if I'm going to be in that family.
  - BruceM 14y ago
    Quick run down: * Dylan was designed at Apple and then later a partnership of Apple, CMU and Harlequin in the 1990s * Harlequin's implementation of Dylan was spun off to another company when they failed. It was then called Functional Developer. * Functional Developer was open sourced in 2004 as Open Dylan. Since then, the development was moving rather slowly, the documentation was still in the 1996-era Framemaker documents, etc. I decided to help really revive it and we've since done the 2011.1 and 2012.1 releases and are working on the 2013.1 release now. The documentation has been brought forward into the modern era, the website updated, new libraries are being written, etc. I've spent a large amount of time over the past 15 months or so to make a lot of that happen. As for strengths: * A pretty great compiler that can do a lot of optimizations. * Multiple dispatch. As StefanKarpinski says in another comment, it is a great thing. * A condition system like Common Lisp. * Everything is an object, so multiple dispatch integrates very cleanly. * I like the macro system. It is more like syntax-case than full macros, but I find it pretty useful. * Everything is pretty clean and consistent. There aren't a lot of strange edge cases and the code is really pretty readable. * Multiple return values, keyword arguments, 'rest' arguments. * Compilation to an efficient executable. * The compilation model lets a lot of existing tools work with the compiled code. I'm able to use Instruments on OS X, perf on Linux, etc to analyze performance and so on. * We have a lot of documentation as a result of having formerly been an expensive commercial product. Weaknesses: * Small community. * Some things are still written with 1990s expectations and need some love, like atomic operations and some aspects of the numerical model. * Some other nits that would get ironed out pretty quickly with a larger community. * Marketing hangover from the 1990s in terms of people thinking Dylan is old, dead, etc. We've contemplated just changing the name on a future release to make it more clear that we're moving forward. As for Lisps ... SBCL and Clozure CL are great implementations. :)
StefanKarpinski 14y ago
I should also point out that I completely agree that is intrinsically difficult to design a language to have both the speed of C and the abstraction power of Lisp. That is part of why the job that Jeff Bezanson, who is largely responsible for Julia's amazing performance, has done is so incredible. It's hard to explain until you start using it, but ubiquitous, fast, expressive multiple dispatch is a truly amazing programming paradigm. I'm not entirely sure how it hasn't been adopted as the core paradigm of any mainstream language in the past.
- dylangs1030 14y ago
  Stefan, do you mind telling me what your programming background is? What languages did you come from before working on Julia? I'm going to look more into the documentation for it now.
  - StefanKarpinski 14y ago
    Not at all. I've done a lot of C, Matlab, Perl, Ruby and R, although I've also dabbled in Java, JavaScript, C++, Scala and Python. Definitely a polyglot of "pragmatic" languages. Julia was influenced most strongly by Lisp (Scheme in particular), Matlab, C, Python, Ruby and Perl. If you (or anyone else reading this) have questions looking through the manual, drop an email to the julia-users@googlegroups.com list, or me personally.
    - crazydiamond 14y ago
      I have just started going through the docs a bit. I am interested in 2 things. One, programs that interface with other commands -- essentially rewriting large shell programs in a "better" language. I saw the section on "external commands" and that looks very promising. Are there any other links or sample programs I can check out. Would Julia be just as good as say Ruby in this respect ? Is there a readline interface ? Second, I haven't yet come across an ncurses interface yet. Thanks. edit: Just came across your article "Shelling out sucks". | In my followup post, I will describe how Julia makes constructing and executing pipelines of external commands as safe as Python’s subprocess and as convenient as shelling out. I could not find a link to the followup. Do you have something ?
pjmlp 14y ago
Yes, on the other hand it is how programming languages advance.

StefanKarpinski 14y ago

Miles Lubin and Iain Dunning gave an excellent presentation at MIT's IAP tutorial on Julia in January where they benchmarked rather non-trival code for doing linear programming in a variety of languages: https://github.com/JuliaLang/julia-tutorial/blob/master/NumericalOptimization/presentation.pdf http://bit.ly/VQ9rDd (shortened version since that's cut off) See page 7, "Simplex Benchmarks". Essentially, they implemented the basics you need to do a fast simplex linear programming algorithm in each of C++, Julia, Matlab and Python. Their results were in line with the Julia home page benchmarks: Julia is between 1-2x slower than good C/C++ code. PyPy and Matlab are 10-20x slower. Python is 80-400x slower. The code can be found here: https://github.com/mlubin/SimplexBenchmarks These results are fairly typical.

dylangs1030 14y ago
1-2x slower is still remarkable given what Julia (apparently) has the power to do. Thanks for the citations!
pygy_ 14y ago
Remove the four spaces before the long URL, it will be properly displayed and linkified. Meanwhile: https://github.com/JuliaLang/julia-tutorial/blob/master/NumericalOptimization/presentation.pdf https://github.com/JuliaLang/julia-tutorial/blob/master/Nume... https://github.com/mlubin/SimplexBenchmarks https://github.com/mlubin/SimplexBenchmarks
qznc 14y ago
I think there should be a Python+NumPy variant for comparison as well.
- mlubin 14y ago
  I've added a bit of an explanation as to why there's no NumPy version.
  - qznc 14y ago
    SciPy does have some sparse support. http://www.scipy.org/SciPyPackages/Sparse http://www.scipy.org/SciPyPackages/Sparse

BruceM 14y ago

It is hard ... OpenDylan (http://opendylan.org/ http://opendylan.org/) manages to mostly pull it off when the right type information is available. It could be smarter at times, but it does pretty well. In a recent test for someone, they had code running in C++ in 0.5 seconds, Dylan in 0.6. Our major performance loss in OpenDylan comes when there's still too much generic dispatch going on, but that can usually be reduced through various mechanisms. (And as I said above, there's still avenues where the compiler could do better.) Another interesting implementation is Gambit Scheme which manages to pull off some really impressive feats of compilation for performance once you declare '(not safe)' although it is still fast with safety enabled.

dylangs1030 14y ago
Bruce, what is your association with OpenDylan? (It feels odd referring to a language that shares my name, ha). What are Dylan's strengths and weaknesses? And what you say about Scheme is believable, though I wouldn't use Scheme personally as I prefer Lisp if I'm going to be in that family.
- BruceM 14y ago
  Quick run down: * Dylan was designed at Apple and then later a partnership of Apple, CMU and Harlequin in the 1990s * Harlequin's implementation of Dylan was spun off to another company when they failed. It was then called Functional Developer. * Functional Developer was open sourced in 2004 as Open Dylan. Since then, the development was moving rather slowly, the documentation was still in the 1996-era Framemaker documents, etc. I decided to help really revive it and we've since done the 2011.1 and 2012.1 releases and are working on the 2013.1 release now. The documentation has been brought forward into the modern era, the website updated, new libraries are being written, etc. I've spent a large amount of time over the past 15 months or so to make a lot of that happen. As for strengths: * A pretty great compiler that can do a lot of optimizations. * Multiple dispatch. As StefanKarpinski says in another comment, it is a great thing. * A condition system like Common Lisp. * Everything is an object, so multiple dispatch integrates very cleanly. * I like the macro system. It is more like syntax-case than full macros, but I find it pretty useful. * Everything is pretty clean and consistent. There aren't a lot of strange edge cases and the code is really pretty readable. * Multiple return values, keyword arguments, 'rest' arguments. * Compilation to an efficient executable. * The compilation model lets a lot of existing tools work with the compiled code. I'm able to use Instruments on OS X, perf on Linux, etc to analyze performance and so on. * We have a lot of documentation as a result of having formerly been an expensive commercial product. Weaknesses: * Small community. * Some things are still written with 1990s expectations and need some love, like atomic operations and some aspects of the numerical model. * Some other nits that would get ironed out pretty quickly with a larger community. * Marketing hangover from the 1990s in terms of people thinking Dylan is old, dead, etc. We've contemplated just changing the name on a future release to make it more clear that we're moving forward. As for Lisps ... SBCL and Clozure CL are great implementations. :)

StefanKarpinski 14y ago

I should also point out that I completely agree that is intrinsically difficult to design a language to have both the speed of C and the abstraction power of Lisp. That is part of why the job that Jeff Bezanson, who is largely responsible for Julia's amazing performance, has done is so incredible. It's hard to explain until you start using it, but ubiquitous, fast, expressive multiple dispatch is a truly amazing programming paradigm. I'm not entirely sure how it hasn't been adopted as the core paradigm of any mainstream language in the past.

dylangs1030 14y ago
Stefan, do you mind telling me what your programming background is? What languages did you come from before working on Julia? I'm going to look more into the documentation for it now.
- StefanKarpinski 14y ago
  Not at all. I've done a lot of C, Matlab, Perl, Ruby and R, although I've also dabbled in Java, JavaScript, C++, Scala and Python. Definitely a polyglot of "pragmatic" languages. Julia was influenced most strongly by Lisp (Scheme in particular), Matlab, C, Python, Ruby and Perl. If you (or anyone else reading this) have questions looking through the manual, drop an email to the julia-users@googlegroups.com list, or me personally.
  - crazydiamond 14y ago
    I have just started going through the docs a bit. I am interested in 2 things. One, programs that interface with other commands -- essentially rewriting large shell programs in a "better" language. I saw the section on "external commands" and that looks very promising. Are there any other links or sample programs I can check out. Would Julia be just as good as say Ruby in this respect ? Is there a readline interface ? Second, I haven't yet come across an ncurses interface yet. Thanks. edit: Just came across your article "Shelling out sucks". | In my followup post, I will describe how Julia makes constructing and executing pipelines of external commands as safe as Python’s subprocess and as convenient as shelling out. I could not find a link to the followup. Do you have something ?

pjmlp 14y ago

Yes, on the other hand it is how programming languages advance.