31–40 of 168 posts
Whilst the Julia version currently beats Mojo, I fully expect both to approach basically the same performance with enough tinkering, and for that performance to be on par with C or Fortran. A more interesting question is which version is more elegant, ‘obvious’ and maintainable. (Deeply familiar with both, but money is on Julia).
In my opinion, the issue that will make more of a difference in the long run is Mojo's first-class support for AoT compiled binaries (as well as JIT compilation). Julia's poor AoT support (with small binaries) is a major Achilles heel. I really wish that the Julia developers had taken that more seriously earlier on.
Connection to the Python ecosystem. Python remains the number 1 teaching language by a large margin.
AI funding. If they can get the buy in from the AI community that Julia never got, they have the resources to engineer around any challenges faced.
Solid foundation in modern language design, and with that, a focus on correct code produced by larger teams.
Whilst the Julia version currently beats Mojo, I fully expect both to approach basically the same performance with enough tinkering, and for that performance to be on par with C or Fortran. A more interesting question is which version is more elegant, ‘obvious’ and maintainable. (Deeply familiar with both, but money is on Julia).
IMO the reason Julia gets to be this fast is because of LLVM, and the guy who created LLVM is also the creator of Mojo so there is something to be said about that
Mojo released an example of their new language which will mean readability and simplicity compared to the Python implementation will surely have been a requirement… I get someone within Modular doing some horrific looking low-level Mojo stuff could get it much quicker.
Convincing LLVM to vectorize is still a problem in both languages. I do hope Mojo can make some headway there in the future. Especially since with MLIR they might be able to capture some higher level semantics Julia can't.
there are so many fractal benchmarks floating around, but i’ve never seen any cool interactive fractal applications, eg interactive visualizations that smoothly redraw changes over time, or respond to input. has anyone seen programs like that?
Earlier quoted context omitted.
We have seen many languages cycle in popularity, but Julia is one of the few high-level languages that could actually match... or in some cases exceed C/C++ performance. There are always tradeoffs, and it usually takes a few weeks for people to come to terms with why Julia is unique. Definitely falls into the fun category. =)
How can Julia exceed C/C++ performance?
Only a few like Go ecosystem developers tended to take the time to refactor many useful core tools into clean parallelized versions in the native ecosystem, and to a lesser extent Julia devs seem to focus on similar goals due to the inherent ease of doing this correctly.
When one compares the complexity of a broadcast operator version of some function in Julia, and the amount of effort needed to achieve similar results in pure C/C++... the answer of where the efficiency gains arise should be self evident.
One could always embed a Julia programs inside a c wrapper if it makes you happier. =)
Earlier quoted context omitted.
How can Julia exceed C/C++ performance?
C is not the fastest language. Fortran can often beat them because is has non-aliasing function arguments and does not treat arrays like pointers. https://fortran-lang.discourse.group/t/fortran-is-faster-tha...
Earlier quoted context omitted.
C is not the fastest language. Fortran can often beat them because is has non-aliasing function arguments and does not treat arrays like pointers. https://fortran-lang.discourse.group/t/fortran-is-faster-tha...
I do not dispute that C is not the fastest language. However C99 has the `restrict` keyword, which when combined with strict aliasing rules gives non-aliasing function arguments (I believe).
gcc is notoriously:
1. inefficient compared to the Intel or LLVM compiler
2. nondeterministic with -O3, which is why most people use g++ to check the code... and even then all bets are off on some hardware.
3. thrashes ram layouts, and slowly chokes to death if used as intended.
It comes down to the use-case, but fortran has killed too many to trust anywhere. =)
It is still fascinating that lisp languages lost to python for AI and data processing and now pretty much everything else. In a perfect world , we would be using lisp or lisp like languages for everything