21–30 of 61 posts
Earlier quoted context omitted.
Thanks. Well, I've heard of the language Julia, but didn't connect the title with it as it sounded like a person, robot or something.. Mm sounds good. Is it as fast as, say, C?
Ah, gotcha. Maybe it didn't initially say "Julia Lang"; it does now, perhaps thanks to your comment.
Earlier quoted context omitted.
Hmm, I would guess that if somebody doesn't already know about the Julia language, this wouldn't be a very interesting page (which is fine). So this is a great title! In case you're curious, the website is https://julialang.org/ > Julia is a high-level, high-performance dynamic programming language for numerical computing. It provides a sophisticated compiler, distributed parallel execution, numerical accuracy, and a…
Thanks. Well, I've heard of the language Julia, but didn't connect the title with it as it sounded like a person, robot or something.. Mm sounds good. Is it as fast as, say, C?
Actually want to qualify this a bit. Nothing gets automatically fast by just picking a fast language. That Julia is close to C in performance mainly means it is possible to achieve this through optimization without too much effort. However you still need to have some idea of what makes something slow or fast in Julia.
Personally I find it very easy to optimize Julia code because you can quickly see how the JIT transforms an individual function and what you may need to change.
Earlier quoted context omitted.
Thanks. Well, I've heard of the language Julia, but didn't connect the title with it as it sounded like a person, robot or something.. Mm sounds good. Is it as fast as, say, C?
When you write code in a C like fashion it can often get as fast or faster than C. Of course it has the disadvatnage of all jit languages that it will likely have slower startup. But when you crunch big chunks of data it should be able to compete with C. Actually want to qualify this a bit. Nothing gets automatically fast by just picking a fast language. That Julia is close to C in performance mainly means it is poss…
Earlier quoted context omitted.
When you write code in a C like fashion it can often get as fast or faster than C. Of course it has the disadvatnage of all jit languages that it will likely have slower startup. But when you crunch big chunks of data it should be able to compete with C. Actually want to qualify this a bit. Nothing gets automatically fast by just picking a fast language. That Julia is close to C in performance mainly means it is poss…
Ok thanks. Lately been using Cython with its near-C speed and Python convenience. Just quickly had a look at Julia wiki page, seems like a fast Python, is that fair?
Then finally, the kicker is that Julia, especially on v0.7, doesn't optimize functions separately: it optimizes them together. It will inline small functions into others, perform interprocedural optimizations and utilize compilation-time constants, etc. Thus when the code is Julia all the way down, it can and will compile everything together to optimize it a lot more than functions compiled separately, giving a lot more performance benefits. When you add in the macros to turn off things like bounds checks and adding in explicit SIMD, you truly get to C-level of performance and many times beyond because your code is so architecturally and vertically optimized (it's like you put on the flags to say "compile code that only works for this current machine with this current codebase", and it can safely make this assumption because it's JITing).
Because of this, it goes much further than Cython, and this also makes the type system and multiple dispatch central to the language. So I would say at a surface level it's "fast Python" (or "more productive C", that's how I usually think of it). However, at a deeper level the type system is so central that larger software architectures will be different to accommodate this multiple dispatch style as opposed to OOP.
Earlier quoted context omitted.
I don’t use Julia but those language changes would have me worried that existing code would start behaving differently because of parser changes.
We're very careful with changes and give thorough deprecation warnings. When you upgrade and the meaning of something that you're using is going to change in the following version, you will get a warning to change it now, with specific detail of the new spelling of that feature. So as long as you don't skip major versions, you're safe. Corollary: don't skip major versions. Even if you're upgrading from 0.4 to 0.7, yo…
god that sounds sooo painful
Earlier quoted context omitted.
When you write code in a C like fashion it can often get as fast or faster than C. Of course it has the disadvatnage of all jit languages that it will likely have slower startup. But when you crunch big chunks of data it should be able to compete with C. Actually want to qualify this a bit. Nothing gets automatically fast by just picking a fast language. That Julia is close to C in performance mainly means it is poss…
Ok thanks. Lately been using Cython with its near-C speed and Python convenience. Just quickly had a look at Julia wiki page, seems like a fast Python, is that fair?
I wouldn't say it's a fast Python.
Edit: Grammar
Earlier quoted context omitted.
The forthcoming Julia 0.7 release will provide warning messages for important (and breaking) changes that the community has been clamoring for. I don't think users are "worried" so much as they are planning to review and update their code accordingly. For example, I don't expect my existing 0.5 code to work without substantial revisions. This is the last window to improve the language proper before the 1.0 release, a…
I have investigated Julia for a while and am exactly holding off starting some major work until 1.0 is in.
Earlier quoted context omitted.
Ok thanks. Lately been using Cython with its near-C speed and Python convenience. Just quickly had a look at Julia wiki page, seems like a fast Python, is that fair?
I've gotten Cython-like speeds for non-parallelized code in a gradient descent task. I haven't been able to achieve the same speed as parallelized Cython code in Julia using either pmap or @parallel though. I wouldn't say it's a fast Python. Edit: Grammar
Cython's parallelism is via OpenMP which is shared memory multithreading. Of course multithreading is faster, but it's restricted to a single computer. Julia does have multithreading as well via `Threads.@threads`. This is shared memory and restricted to a single computer just like Cython, and will have a lot lower overhead than `pmap` and `@parallel`. If you want to directly compare something to Cython's parallelism, this is what you should be looking at.
On a side note, it looks like Cython doesn't have any native multiprocessing or multinode parallelism that would be the direct comparison to `pmap` or `@parallel`.
Earlier quoted context omitted.
We're very careful with changes and give thorough deprecation warnings. When you upgrade and the meaning of something that you're using is going to change in the following version, you will get a warning to change it now, with specific detail of the new spelling of that feature. So as long as you don't skip major versions, you're safe. Corollary: don't skip major versions. Even if you're upgrading from 0.4 to 0.7, yo…
> you'll want to upgrade /through/ versions 0.5 and 0.6 instead of skipping them. god that sounds sooo painful
Earlier quoted context omitted.
We're very careful with changes and give thorough deprecation warnings. When you upgrade and the meaning of something that you're using is going to change in the following version, you will get a warning to change it now, with specific detail of the new spelling of that feature. So as long as you don't skip major versions, you're safe. Corollary: don't skip major versions. Even if you're upgrading from 0.4 to 0.7, yo…
> you'll want to upgrade /through/ versions 0.5 and 0.6 instead of skipping them. god that sounds sooo painful
Keep in mind that in the future this statement would be something like: if you have code that was written for Julia 1.x and want to upgrade to Julia 3.x, then you should upgrade through Julia 2 instead of just skipping it. This does not seem terribly unreasonable.