Live data from Hacker News

Julia and Mojo Mandelbrot Benchmark

discourse.julialang.org

141–150 of 168 posts

Re: Julia and Mojo Mandelbrot Benchmark

#141

Earlier quoted context omitted.

what's the difference? an llvm (or assembly) intrinsic called from Julia and one called from c will have exactly the same performance. c isn't magic pixie dust that makes your CPU faster.

That SIMD.jl doesn't give you direct control over which SIMD instructions are emitted, and that SIMD code generated with that module is awful compared to what a C compiler would emit. The Mandelbrot benchmark is there. Prove me wrong by implementing it using SIMD.jl and achieving performance rivaling C. Bet you can't.

I wasn't talking about using SIMD.jl. I was talking about the implimentation of the package (which is why I linked to a specific file in the package) which does directly (with some macros) generate simd intrinsics. As for the performance difference per core you're seeing, it's only because your C code is using 32 bit floats compared to the 64 bit floats that Julia is using here.

Re: Julia and Mojo Mandelbrot Benchmark

#142
post #6

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).

One language is literally some months old, and another is 11 years old. Not a fair comparison at this point, and for some years to come. The gap will definitely narrow.

Not necessarily. Julia will always be 11 years older than Mojo, no matter how old both of them get, and that advantage won't shrink. Not to mention, Mojo is a superset of a 40-year old language with billions of dollars of development poured into it, plus an extra hundred million poured directly into Mojo itself. If we go by resources spent on each, Mojo has had gotten about 5x more investment than Julia.

Re: Julia and Mojo Mandelbrot Benchmark

#143
post #105

Earlier quoted context omitted.

PackageCompiler.jl is more fully featured, and I'm definitely looking forward to further developments :) But it still has some pain points: * Massive executables (which you mentioned). This makes it very difficult to use with embedded systems. * Functions are not precompiled by default. You need to write a precompile script [1], which leads to a "two script problem": one script to do what you actually want, and anoth…

While the second part is true, it is a fundamental restriction because Julia compiles a method until it is actually hit and types are defined for the call stack. In equivalent manner, for StaticCompiler.jl you need a declarations of the methods/symbols you need to export. So, while it is true you need to do an extra step compared with other languages , it is not a fundamental problem with respect to PackageCompiler.j…

That's not a fundamental restriction or design problem with Julia, you're just describing JIT compilation. Plenty of languages can be compiled either ahead-of-time or just-in-time. Actually, this should be unusually easy for Julia, because their JIT compiler isn't a heuristic-based compiler like JITs for Python or JS.

The problem is funding. There are 0 full-time employees working on this issue because JuliaComputing has gotten about 10% of the funding Mojo has.

Re: Julia and Mojo Mandelbrot Benchmark

#144

Earlier quoted context omitted.

FWIW, the core Julia developers seem to be taking this more and more seriously, and AoT compilation to small binaries seems more of a "when" question than an "if" at this point. Open source development - without multi-million dollar support from outside - is unpredictable, but I wouldn't be surprised if a year from now, writing a restricted subset of Julia allowed you AoT compilation to reasonable binaries (and not s…

You mean investment like this? https://info.juliahub.com/juliahub-receives-13-million-strat... You can imagine what a company like Boeing might be interested in when it comes to a programming language.

13 million is substantial but not even close to the 100 million Modular got. Which really makes me wonder what Modular has been doing with that money, if they're still getting beat in benchmarks like this...

Re: Julia and Mojo Mandelbrot Benchmark

#145

IMO this is just not a great example on either side. As others have pointed out, the Julia implementation was refined to be 8x faster. The Mojo code has to run the CPython interpreter to run numpy.

> The Mojo code has to run the CPython interpreter to run numpy.

Yes, the need to run CPython interpreter is what makes Mojo slow (and it will remain that way, unless they abandon their "superset of Python" promise).

Re: Julia and Mojo Mandelbrot Benchmark

#146

Earlier quoted context omitted.

That SIMD.jl doesn't give you direct control over which SIMD instructions are emitted, and that SIMD code generated with that module is awful compared to what a C compiler would emit. The Mandelbrot benchmark is there. Prove me wrong by implementing it using SIMD.jl and achieving performance rivaling C. Bet you can't.

I wasn't talking about using SIMD.jl. I was talking about the implimentation of the package (which is why I linked to a specific file in the package) which does directly (with some macros) generate simd intrinsics. As for the performance difference per core you're seeing, it's only because your C code is using 32 bit floats compared to the 64 bit floats that Julia is using here.

He has a point. Currently there is no way in Julia of checking with CPU instructions are available. So in practice, it's impossible to write low-level assembly code in Julia.

IIUC, SIMD.jl only works because it only provides what is guaranteed by LLVM to work cross-platform, which is quite far from being able to use AVX2, for example.

Re: Julia and Mojo Mandelbrot Benchmark

#147
post #132

Earlier quoted context omitted.

Some of what you have written seems pre 1.0 release and some pre 1.9. I have never seen anybody in the community say the correct way to use Julia is in a notebook. As far as I have seen, some people use a simple editor and have the REPL open, and most just use it in vscode. You can do real-time applications just fine in Julia, just preallocate anything you need and avoid allocations in the hot loop, I am doing real-t…

I think the person you are replying to was using notebook as shorthand for interactively. You don't write scripts that you call, you have to have a repl open to interactively feed code to. Autocompletion in Julia is also just terrible and the tooling really is lacking compared to better funded languages. No harm in admitting that (when Julia had no working debugger some people were seriously arguing that you don't ne…

This certainly has not been my experience with Julia people. Sure there are opinionated people in every community, but most of pain points are acknowledged and known.

Re: Julia and Mojo Mandelbrot Benchmark

#148
post #15

Earlier quoted context omitted.

Well, still a much better community than most where having an opinion is considered a sin.

Only if it's the Correct opinion. Try being a julia user but thinking julia kinda sucks. That's a much more hostile experience than being a c++ dev and thinking c++ kinda sucks.

There was a recent post in Julia's Discourse about why people think the language has not caught on as much as it should. There were around 550 comments where half of them talked about why Julia sucks and what to do about it, there are spin-offs of the post continuing discussion. Let's just cut the bull shit, these are all tools, if one doesn't fit you just use the other.

Re: Julia and Mojo Mandelbrot Benchmark

#149
post #147

Earlier quoted context omitted.

I think the person you are replying to was using notebook as shorthand for interactively. You don't write scripts that you call, you have to have a repl open to interactively feed code to. Autocompletion in Julia is also just terrible and the tooling really is lacking compared to better funded languages. No harm in admitting that (when Julia had no working debugger some people were seriously arguing that you don't ne…

This certainly has not been my experience with Julia people. Sure there are opinionated people in every community, but most of pain points are acknowledged and known.

I can confirm that there were multiple (heated) arguments on Discourse, where some posters completely dismissed the need for debuggers in general. I remember it quite well.

It was very strange, but I don't think it says anything about the community, except that people have different opinions and preferences, like in any community.

Re: Julia and Mojo Mandelbrot Benchmark

#150
post #132

Earlier quoted context omitted.

Some of what you have written seems pre 1.0 release and some pre 1.9. I have never seen anybody in the community say the correct way to use Julia is in a notebook. As far as I have seen, some people use a simple editor and have the REPL open, and most just use it in vscode. You can do real-time applications just fine in Julia, just preallocate anything you need and avoid allocations in the hot loop, I am doing real-t…

>> For a long time, one got told that the "correct" way to use julia was in a notebook. Outside of that, nobody wanted to hear your complaints. > I have never seen anybody in the community say the correct way to use Julia is in a notebook. patrick's comment is fully in the past tense for this part, and that was indeed a pretty common thing for a long while in the past. Especially pre-1.0, before Revise became mature…

You must mean REPL, not notebook. I've been following the community since before the move to Discourse, and "use the REPL" surely outnumbers "use a notebook" by orders of magnitude.
Post reply on HN