Live data from Hacker News

Julia and Mojo Mandelbrot Benchmark

discourse.julialang.org

111–120 of 168 posts

Re: Julia and Mojo Mandelbrot Benchmark

#111
post #87

Last time this was up I wrote a single-threaded version in C which I'm pretty sure beats both Julia and Mojo: https://github.com/bjourne/c-examples/blob/master/programs/m...

> pretty sure beats both Julia and Mojo: Would the C compiler automatically exploit vectorized instructions on the CPU, or loop/kernel fusion, etc? It’s unclear otherwise how it would be faster than Julia/Mojo code exploiting several hardware features.

In a HLL like Julia or Mojo you use special types and annotations to nudge the compiler to use the correct SIMD instructions. In C the instructions are directly usable via intrinsics. Julia's and Mojo's advantage is that the same code is portable over many SIMD instruction sets like sse, avx2, avx512, etc. But you generally never get close to the same performance hand-optimized C code gets you.

Re: Julia and Mojo Mandelbrot Benchmark

#112

Earlier quoted context omitted.

> pretty sure beats both Julia and Mojo: Would the C compiler automatically exploit vectorized instructions on the CPU, or loop/kernel fusion, etc? It’s unclear otherwise how it would be faster than Julia/Mojo code exploiting several hardware features.

In a HLL like Julia or Mojo you use special types and annotations to nudge the compiler to use the correct SIMD instructions. In C the instructions are directly usable via intrinsics. Julia's and Mojo's advantage is that the same code is portable over many SIMD instruction sets like sse, avx2, avx512, etc. But you generally never get close to the same performance hand-optimized C code gets you.

This just isn't true. Julia lets you write intrinsics (either LLVM intrinsics or native assembly code) just the same as C. For example, https://github.com/eschnett/SIMD.jl/blob/master/src/LLVM_int....

Re: Julia and Mojo Mandelbrot Benchmark

#113
post #99

Earlier quoted context omitted.

> which I'm pretty sure beats both Julia and Mojo Sometimes "showing the code" is not enough. Show me the benchmark.

I'll pass - Hacker News comments are not dissertations. The C code ran faster on my machine. YMMV.

I don't really believe you ran either the Mojo or the Julia code. There's no way your single-threaded C code outperformed multi-threaded simd optimized Julia or Mojo. It's flat out impossible.

The only other explanation is if you ran the non-simd Julia version under a single thread.

Re: Julia and Mojo Mandelbrot Benchmark

#114

tldr: in the test's first implementation mojo was faster but then the refactored and made the julia code faster by 8x over mojo. that's cool but mojo literally just came out

You make it sound a bit like they optimized the heck out of Julia, while the Mojo sample was a naive little thing in a new innocent language.

The reality is that the Julia optimization was just a rewrite to use the same algorithm as Mojo, and that the Mojo code was heavily optimized.

Re: Julia and Mojo Mandelbrot Benchmark

#115
post #89

Earlier quoted context omitted.

This is such a classic strongly opinionated, inflammatory, and fundamentally ignorant Hacker News comment.

I returned to HN recently after a few years away, and I swear the average commenter has gotten much worse. Simultaneously more arrogant, more ignorant, and with worse reading comprehension. I used to be able to count on commenters understanding what was written even if they disagreed, but lately I see many comments confidently responding to something that wasn't relevant or even present.

I suspect there's a bit of an Eternal September effect going on as a wider audience ends up here (possibly fleeing the continuing "enshittification" of most all for-profit online fora)

Re: Julia and Mojo Mandelbrot Benchmark

#116
post #15

Earlier quoted context omitted.

Not if you want to avoid condescending "I cannot look at the Python code my eyes hurt" comments. Good to know the Julia community hasn't made any progress in that regard, though.

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.

Re: Julia and Mojo Mandelbrot Benchmark

#117

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?

There is a package for Julia that does this, it's called InteractiveViz.jl [1]. It is rally neat and used GPU rendering underneath with (GL)Make.jl [2].

[1] https://github.com/org-arl/InteractiveViz.jl [2] https://github.com/MakieOrg/Makie.jl

Re: Julia and Mojo Mandelbrot Benchmark

#118
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.

It's really all down to your tone and attitude. If you're hostile, demanding and negative, you will indeed get pushback, but that's human nature.

Some people feel that they should get to act like a prick, while everyone else should be humble and courteous.

If you act like a decent person person, there's no problem pointing out weak points in Julia and request help to work around it. If your only input is "Julia kinda sucks", what kind of feedback do you feel that you are owed?

Re: Julia and Mojo Mandelbrot Benchmark

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

yeah pretty much any strongly performance oriented modern language should be able to be massaged into emitting whatever instructions should give close to optimal performance here. It's always fun though when one language does better naïvely in a benchmark to delve in and see how to match or surpass them, and see if it was worth the trouble. Microbenchmark performance for languages in this class definitely shouldn't b…

I disagree, actually. I have found microbenchmarks to be very informative to understand why a language is fast in some cases and slow in others.

It's not only the actual benchmark numbers though. Its understanding the code that reaches those numbers: Can Julia do explicit SIMD? How awkward is that in one language or the other? Are there idiosyncratic bottlenecks? Bad design decisions that needs to be worked around in one language but not the other? And so on.

Re: Julia and Mojo Mandelbrot Benchmark

#120

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?

All the other answers are true. But there is one thing I didn't see people saying. Thanks to the existence of macros, you can create->compile code in runtime. This allows for faster solving of some problems which are too dynamic, thanks to the fast compile times of Julia.

This might sound counterintuitive given that latency is a normal problem mentioned everywhere else about Julia. But, if you think about it, Julia compiled to native code a plot library from scratch in 15- seconds every time you imported it (before Julia 1.9 where native caching of code was introduced, and latency was cut down significantly).

This makes that problems where you would like to (for example) generate polynomials in runtime and evaluate then a billion times each, Julia can generate efficient code for ever polynomial, compile it and run it fast those billion times. C/C++/Fortran would have needed to write a (really fast) genetic function to evaluate polynomials, but this would have always (TM) been less efficient than code generated and optimised for them.

Edit: typos and added some remarks lacking originally

Post reply on HN