3 ms·

So this is why every once in a while we see some article about Julia being as easy to use as Python while having nearly the performance of C. That's some very

So this is why every once in a while we see some article about Julia being as easy to use as Python while having nearly the performance of C. That's some very slick but sketchy marketing tactics. I'd rather deal with Cython apache license than deal with this GPL stuff for commercial use.

deleted 9y ago
[deleted]
omginternets 9y ago
What exactly is sketchy, here?
ihnorton 9y ago
> So this is why every once in a while we see some article about Julia being as easy to use as Python while having nearly the performance of C. Here's a performance testimonial with links to real code and benchmarks against Fortran (not Python), from Steven G. Johnson, one of the authors of FFTW: https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/7 https://discourse.julialang.org/t/julia-vs-fortran-complaint... I implemented an erfinv function Julia (https://github.com/JuliaLang/julia/pull/29874 https://github.com/JuliaLang/julia/pull/29874), and it was about 3x faster than Matlab or SciPy's erfinv function, both of which are taken from standard Fortran libraries. [...] I have found similar gains (compared to Fortran code called in SciPy) for other special functions, e.g. polygamma functions (https://github.com/JuliaLang/julia/pull/71255 https://github.com/JuliaLang/julia/pull/71255) and exponential integrals (https://github.com/JuliaMath/SpecialFunctions.jl/issues/19 https://github.com/JuliaMath/SpecialFunctions.jl/issues/19). The reason Julia can beat the Fortran code is that metaprogramming makes it easy to apply performance optimizations that are awkward in Fortran. We have metaprogramming macros (@evalpoly) that can easily inline polynomial evaluations, whereas the Fortran code makes function calls that loop over look-up tables of polynomial coefficients. Even greater speedups are possible for evaluating polynomials of complex arguments, where there is a fancy recurrence from Knuth that is almost impossible to use effectively without code generation. In principle, the Fortran authors could have done the same inlining and gotten similar performance, but the code would have been much more painful to write by hand. (They could even have written a program to generate Fortran code, but that is even more painful.) > I'd rather deal with Cython apache license than deal with this GPL stuff for commercial use. The Julia core is MIT licensed. The language distribution is currently GPL licensed due to linked dependencies, but there has been a no-GPL build flag available for several releases. GPL (and other) dependencies are continually being removed, and there are only one or two (GPL) libraries left in the currently nightly build.
matt4077 9y ago
This seems to be a terrible misinformed comment. Not only isn't there really a problem with using GPL tools in a commercial context, as long as they don't become part of your work product. GCC is probably used to compile a large percentage of commercial software. And I'm sure you're writing comments in Chrome, yet expect to retain the copyright on those words. But what makes this really asinine is that Julia isn't even GPL: https://github.com/JuliaLang/julia/blob/master/LICENSE.md https://github.com/JuliaLang/julia/blob/master/LICENSE.md Moreover, since I've been seeing this kind of hostility towards the GPL more and more often: it should be somewhat obvious to everyone that the current ecosystem of widely available, highest-quality OSS stacks is a rather surprising development. There are certainly parallel universes where parallel computing requires you to buy the compiler from IBM, and URIs end not in .html, but in .doc. The GPL and its advocates aren't the only ones who created this, but I'm pretty sure they were at least necessary. That includes not just the software they created, but also the force of the moral argument for software freedom they made.
- bachmeier 9y ago
  What I really dislike about a lot of the GPL arguments is that they are complaints that the GPL doesn't let you freeload masked as arguments that the GPL is anti-business. The GPL is one of the most business-friendly licenses there is. The freedoms guaranteed by the GPL mean dual licensing works. Good luck with a dual licensing strategy if you release your software under the MIT license.

deleted 9y ago

[deleted]

omginternets 9y ago

What exactly is sketchy, here?

ihnorton 9y ago

> So this is why every once in a while we see some article about Julia being as easy to use as Python while having nearly the performance of C. Here's a performance testimonial with links to real code and benchmarks against Fortran (not Python), from Steven G. Johnson, one of the authors of FFTW: https://discourse.julialang.org/t/julia-vs-fortran-complaint/4366/7 https://discourse.julialang.org/t/julia-vs-fortran-complaint... I implemented an erfinv function Julia (https://github.com/JuliaLang/julia/pull/29874 https://github.com/JuliaLang/julia/pull/29874), and it was about 3x faster than Matlab or SciPy's erfinv function, both of which are taken from standard Fortran libraries. [...] I have found similar gains (compared to Fortran code called in SciPy) for other special functions, e.g. polygamma functions (https://github.com/JuliaLang/julia/pull/71255 https://github.com/JuliaLang/julia/pull/71255) and exponential integrals (https://github.com/JuliaMath/SpecialFunctions.jl/issues/19 https://github.com/JuliaMath/SpecialFunctions.jl/issues/19). The reason Julia can beat the Fortran code is that metaprogramming makes it easy to apply performance optimizations that are awkward in Fortran. We have metaprogramming macros (@evalpoly) that can easily inline polynomial evaluations, whereas the Fortran code makes function calls that loop over look-up tables of polynomial coefficients. Even greater speedups are possible for evaluating polynomials of complex arguments, where there is a fancy recurrence from Knuth that is almost impossible to use effectively without code generation. In principle, the Fortran authors could have done the same inlining and gotten similar performance, but the code would have been much more painful to write by hand. (They could even have written a program to generate Fortran code, but that is even more painful.) > I'd rather deal with Cython apache license than deal with this GPL stuff for commercial use. The Julia core is MIT licensed. The language distribution is currently GPL licensed due to linked dependencies, but there has been a no-GPL build flag available for several releases. GPL (and other) dependencies are continually being removed, and there are only one or two (GPL) libraries left in the currently nightly build.

matt4077 9y ago

This seems to be a terrible misinformed comment. Not only isn't there really a problem with using GPL tools in a commercial context, as long as they don't become part of your work product. GCC is probably used to compile a large percentage of commercial software. And I'm sure you're writing comments in Chrome, yet expect to retain the copyright on those words. But what makes this really asinine is that Julia isn't even GPL: https://github.com/JuliaLang/julia/blob/master/LICENSE.md https://github.com/JuliaLang/julia/blob/master/LICENSE.md Moreover, since I've been seeing this kind of hostility towards the GPL more and more often: it should be somewhat obvious to everyone that the current ecosystem of widely available, highest-quality OSS stacks is a rather surprising development. There are certainly parallel universes where parallel computing requires you to buy the compiler from IBM, and URIs end not in .html, but in .doc. The GPL and its advocates aren't the only ones who created this, but I'm pretty sure they were at least necessary. That includes not just the software they created, but also the force of the moral argument for software freedom they made.

bachmeier 9y ago
What I really dislike about a lot of the GPL arguments is that they are complaints that the GPL doesn't let you freeload masked as arguments that the GPL is anti-business. The GPL is one of the most business-friendly licenses there is. The freedoms guaranteed by the GPL mean dual licensing works. Good luck with a dual licensing strategy if you release your software under the MIT license.