Domain: julialang.org
Stories and comments across the archive that link to julialang.org.
Comments · 35
-
Re:Julia anyone?Some references to Julia as a ML language, including its GPU and automatic differentiation capabilities:
Blogs:
Building a Language and Compiler for Machine Learning
DiffEqFlux.jl â" A Julia Library for Neural Differential Equations
Why Numba and Cython are not substitutes for Julia
Papers:
Fashionable Modeling with Flux
Effective Extensible Programming: Unleashing Julia on GPUs
Dynamic Automatic Differentiation of GPU Broadcast Kernels
Automatic Full Compilation of Julia Programs and ML Models to Cloud TPUs
Don't Unroll Adjoint: Differentiating SSA-Form Programs
DiffEqFlux.jl - A Julia Library for Neural Differential Equations
Confederated Modular Differential Equation APIs for Accelerated Algorithm Development and Benchmarking (about differential equations, not ML, but describes how Julia's architecture permits very modular algorithmic designs that custom-compile down to efficient implementations)
-
Re:Julia anyone?Some references to Julia as a ML language, including its GPU and automatic differentiation capabilities:
Blogs:
Building a Language and Compiler for Machine Learning
DiffEqFlux.jl â" A Julia Library for Neural Differential Equations
Why Numba and Cython are not substitutes for Julia
Papers:
Fashionable Modeling with Flux
Effective Extensible Programming: Unleashing Julia on GPUs
Dynamic Automatic Differentiation of GPU Broadcast Kernels
Automatic Full Compilation of Julia Programs and ML Models to Cloud TPUs
Don't Unroll Adjoint: Differentiating SSA-Form Programs
DiffEqFlux.jl - A Julia Library for Neural Differential Equations
Confederated Modular Differential Equation APIs for Accelerated Algorithm Development and Benchmarking (about differential equations, not ML, but describes how Julia's architecture permits very modular algorithmic designs that custom-compile down to efficient implementations)
-
Re: Speed
Try Julia. Nearly as fast as C. Feels like writing in Python, only better.
FTFY. https://julialang.org/benchmar...
As for the syntax, Julia uses significant line breaks (replacing semicolons of C-like languages) but none of the indentation issues of Python. Blocks are closed with the "end" statement, replacing the braces of C-like languages. It's the best of both worlds.
-
Why don't you use R, Julia, ...?
-
Languages are full of hard choices
I've played with my own toy language design, and there are so many agonizing choices. I empathize with these guys, trying to get it all down.
For just one little example, take integer literals.. To sys depend or not?, that is the question. They've chosen to sys depend like C. That leads to the convenience of automatic scaling; but it's a form of implicit conversion which is evil. It potentially leads to "works on my machine" bugs. The alternative is to force something that's generally supported on modern hardware but "big enough" like 32 or 64 bit; but that leads to "dog slow or not working on embedded" because you have to simulate it on a more constrained architecture.
That's just one little choice. There are hundreds of choices like this in language design, thousands? Some are more important than others.
Good luck, guys.
-
Re:No native compiler
Didn't RTFM? Julia has several backends including LLVM. Performance is more than respectable. In particular, puts Python to shame and close to Java + JIT but without the JIT lag, load time and memory footprint annoyance.
-
Re:Best language for scientific/numerical work?
Look at Julia. It is similar to Go, Rust, Swift and the like in that it uses LLVM for generating the final machine code. It can be quite efficient. The language is designed for similar uses as Matlab - except it does not suck. I prefer Julia to Matlab for everything other then debugging - the Matlab debugger is great compared to what is available for Julia.
-
My higher performance favorite languages.
-
Re:A Very Old Performance Problem, Mostly Forgotte
Only because Fortran stores multidimensional arrays in column-major order, while every other language in the known universe uses row-major order.
Julia is another that I know of, not surprisingly because it continues the scientific computing traditions of Fortran in many ways. From TFM:
Multidimensional arrays in Julia are stored in column-major order
... This convention for ordering arrays is common in many languages like Fortran, Matlab, and R (to name a few). The alternative to column-major ordering is row-major ordering, which is the convention adopted by C and Python (numpy) among other languages. -
Your opinion on Julia
Swift is a nice and powerful language but I would like your opinion on Julia and why or when should i use Swift instead of Julia (outside of iOS development)?
-
Re:So . . .
The best is actually faster than C, and the worst is 2.1x slower, not 5x slower (numerical values given in http://julialang.org/ ). And that's just the fibonacci benchmark; the other ones are within 50% of C performance except for rand_mat_stat which is 60% slower than C (this is due to the garbage collector, apparently).
-
Re:Yet Another Slow Language
http://julialang.org/benchmark...
If you think Java handles 'all tasks' then Julia isn't aimed at you. it's for scientific/numerical computing. Java is terrible at that, in terms of syntax, library support, and speed. Even python is far better than Java for that purpose.
-
Re:So . . .
Not at all. Julia is just-in-time compiled to native code. You can basically get C-like performance in pure julia: http://julialang.org/benchmark...
There's also a powerful type system and lisp-style macros, along with support for parallel programming and lightweight threads, allowing you to do stuff like: https://gist.github.com/anj1/2...
(that's just a toy example, of course)
-
Julia is Hot!
Mmm, built for supercomputing.
http://julialang.org/ -
Re:Depends
Keep an eye on Julia, it's a very promising project.
-
Julia Re:Juliabase?
Any relation to the Julia language? http://julialang.org/ All Python to me
-
Re:Far too expensive
In a few time (a couple of years) I think Julia (http://julialang.org/) will be a contender. At present is not fully mature for industrial application IMHO (some evolution in syntax is expected, and debugging is ongoing).
Julia is a mix of Matlab, C and a typical scripting language (Perl, Python, Ruby....), wraps several numerical libraries (e.g. LAPACK for 'normal' matrices and SuiteSparse for sparse matrices, BLAS functions, PCRE for regular expressions...) and is prepared from its inception for painless running in parallel platforms. Its loaded with a ton of numerical functions (Bessels, Gammas, etc...) A good JIT compiler makes it run many numerical benchmarks almost as fast as compiled C or Fortran (see examples in the front page of http://julialang.org/), and also allows for many of the functions in Julia's standard library to be written in Julia instead of in C.
Julia is a Swiss knife for (numerical and scientific) programming in the making. It is open source and free and at present already runs in most platforms. -
Please god no.
I've used Matlab academically for about half a year now, and that most anybody (but for scientists and mathematicians operating solely on huge numeric matrices, maybe) uses it is rather shocking to me. The only good thing I can really say about Matlab is that it's made me a better programmer in _other_ languages. Sometimes when you're forced to do something so horribly wrong, the right way of doing it leaps out at you. It's like being forced to ride a unicycle, and suddenly realizing why the motorcycle was invented. Not to say that it doesn't have some very advanced features; it's not a simple beast by any means and -can- do some amazing stuff, but it seems to do them so.. weirdly, and often ridiculously slowly, that it's got that crufty feeling of legacy software with stuff just stapled on all over it.
I'm hopeful about http://www.julialang.org/ the Julia language project and think it's worth at least keeping an eye on in the future.
-
Re: Julia (language)?
I haven't really used it, but I've heard good things about Julia (especially if you're familiar with Matlab). Plus, it seems to play nice with Python.
http://en.wikipedia.org/wiki/J...
http://julialang.org/I played around with Julia some number of months ago -- very promising, but Not There Yet (I had to open up many bug reports and submit some patches just to get DB access to work, and origin/master (where I was cloning from, because the releases were not too good) tended to break every time someone committed.
Really looking forward to it one day, though....
-
Julia (language)?
I haven't really used it, but I've heard good things about Julia (especially if you're familiar with Matlab). Plus, it seems to play nice with Python. http://en.wikipedia.org/wiki/J...
http://julialang.org/ -
Re:Bad analogy
Exactly. Julia will eat R for lunch soon enough, I think. It's an elegant, well designed and efficient language. It's only been around for a couple of years, and has a very vibrant and rapidly growing community.
Check it out for yourself: The Julia Language Homepage. It's got a lot to offer anyone with an interest in mathematics, including statisticians. It's based on the LLVM, and interfaces trivially with C libraries - plus it's a very fast language in it's own right, unlike R or Python.
-
Re:Q: Why Are Scientists Still Using FORTRAN in 20
I started looking at the videos on the Julia website and kept thinking how that language reminded me of the very high level of APL but with normal ASCII characters. I remember how IBM did work on a special vectorizing APL, but it never caught on like Fortran. Julia might have a better go at it--it's pretty new, though.
-
huh
Back when I was in school, the consensus seemed to be that C was "about as fast" as FORTRAN. And when FORTRAN was really faster you could just write most of your code in C and link to FORTRAN libs. BLAS, LAPACK, etc. Just had to store your arrays in column-major order. If you look at the benchmarks at the Julia site, linked in the article, you'll see that FORTRAN beats C by a large margin in one benchmark, loses by a large margin in another benchmark, and is slightly faster in all the others. They state that they used gcc 4.8.1 as their C compiler but don't mention what compiler they used for FORTRAN. Also gcc 4.8.1? Kinda matters.
-
Re: And it still has the GIL
actual language speed = the time it takes the program to run + the time it takes the program to be written.
Sure Python might be 100x or more slower than C, but the total time is usually faster. For people that need speed, they should check out Julia. It's a scripting language designed mainly for technical computing (although it is perfectly general-purpose) that is fast due to good type inference and JIT. Usually within 2x of C. It also can call Python libraries as easily as within Python.
-
Re:Julia
Bah, somehow my Julia link got fubared. Anyhow, here's a good one:
-
Julia is build for Scientific Computing
Take a look at Julia. http://julialang.org/
It is almost as fast as C, which make it much faster than Matlab, Octave, R and Python. -
SolvedI recently had to answer this same question for myself and my group. I reduced the problem to evaluating the trade offs of the following dimensions:
- 1. Ease of reading/programming/maintaining by non-professional programmers.
- 2. Accessability.
- 3. Well supported/documented libraries.
- 4. Quickness.
#1 reduced the field of choices (IMO) to * Matlab/Octave * R/S+ * SAS * Perl * Python * Julia
As for #2 gives preference to Python, R, Julia, Perl, or Octave (Your situation may not be as limiting).
#3 led me to many searches that all indicated that R and Python have a rich set of libraries and lots of community support.
As for #4 From Julia's website http://julialang.org/ they show nice benchmark information that indicates that Python is pretty quick.
My conclusion was that I couldn't really go wrong between R or Python. However, I chose Python because it was quicker, I like the syntax better, I like the libraries better (NumPy, SciPy, Pandas, Matplotlib) and is seems to play nicer with everything else. This is what worked for me and how I went about deciding. -
Python
I have a friend who works for a company that does gene sequencing and other genetic research and, from what he's told me, the whole industry uses mostly python. You probably don't have the hardware resources that they do, but I'd bet you also don't have data sets that are nearly as large as theirs are.
You might also get better results from something less general purpose like Julia, which is designed for number crunching.
-
Just a thought along the side-line
"using a combination of C++ and Python running atop Linux"... I just started to use Julia, a rather new programming language for technical computing, and I am truly, truly impressed. I got interested by the benchmarks these guys published, and may be reporting back here in a couple of days with first experiences from implementing a Lucas-Lehmer test for Mersenne primes. Is Julia something for CERN ? I mean, you don't get to swim in the pool full of bugs that C++ can quickly become...
-
Re:He's right
Better MATLAB than wishful thinking... I'm not a fan personally, but I would rather people used that than nothing at all.
I'd like to introduce you to Julia. The sooner it gets widespread, the better for mankind. Or at least for engineerkind...
-
Re:Congratulations R Team
Also, there's Julia (http://julialang.org/), and I recently came across at least one IDE for it (although I haven't tried it yet): Julia Studio.
-
Re:Tangentially
There's a few points:
1. Julia is entirely dynamic, so there's no need to think about compile time versus run time, simplifying the mental model (but the performance is like that of compiled languages). It's as easy as Python or Matlab in that respect, but much faster.
2. There are just a few powerful language features (e.g. ubiquitous, fast multiple dispatch, supported with an expressive type system), rather than a lot of features that interact in complicated ways.
3. Good for general programming stuff: working with strings, calling external programs and other things that are generally pretty awkward in R and Matlab (one of the reasons why NumPy is gaining popularity).In general, the motivation (expressed in a previous Julia blog post) is to have something that's easy to use and learn, but fast and powerful (you *can* go deep if you want to), and designed expressly for numerical work —which means, among other things, that it has to be able to store large arrays of numeric values in-line and call libraries like LAPACK on them.
Stefan Karpinski
-
Re:Tangentially
There's a few points:
1. Julia is entirely dynamic, so there's no need to think about compile time versus run time, simplifying the mental model (but the performance is like that of compiled languages). It's as easy as Python or Matlab in that respect, but much faster.
2. There are just a few powerful language features (e.g. ubiquitous, fast multiple dispatch, supported with an expressive type system), rather than a lot of features that interact in complicated ways.
3. Good for general programming stuff: working with strings, calling external programs and other things that are generally pretty awkward in R and Matlab (one of the reasons why NumPy is gaining popularity).In general, the motivation (expressed in a previous Julia blog post) is to have something that's easy to use and learn, but fast and powerful (you *can* go deep if you want to), and designed expressly for numerical work —which means, among other things, that it has to be able to store large arrays of numeric values in-line and call libraries like LAPACK on them.
Stefan Karpinski
-
Re:Tangentially
There's a few points:
1. Julia is entirely dynamic, so there's no need to think about compile time versus run time, simplifying the mental model (but the performance is like that of compiled languages). It's as easy as Python or Matlab in that respect, but much faster.
2. There are just a few powerful language features (e.g. ubiquitous, fast multiple dispatch, supported with an expressive type system), rather than a lot of features that interact in complicated ways.
3. Good for general programming stuff: working with strings, calling external programs and other things that are generally pretty awkward in R and Matlab (one of the reasons why NumPy is gaining popularity).In general, the motivation (expressed in a previous Julia blog post) is to have something that's easy to use and learn, but fast and powerful (you *can* go deep if you want to), and designed expressly for numerical work —which means, among other things, that it has to be able to store large arrays of numeric values in-line and call libraries like LAPACK on them.
Stefan Karpinski
-
Re:It's the packages stupid!
Even the article mentions that most of the other languages use C code. Dynamic languages tend to have good foreign function interfaces, and this one seems to have one too. The only thing that has to be reimplemented is a wrapper if you want a friendly interface.