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.
Julia and Mojo Mandelbrot Benchmark
111–120 of 168 posts
Re: Julia and Mojo Mandelbrot Benchmark
#112Earlier 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.
Re: Julia and Mojo Mandelbrot Benchmark
#113Earlier 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.
The only other explanation is if you ran the non-simd Julia version under a single thread.
Re: Julia and Mojo Mandelbrot Benchmark
#114tldr: 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
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
#115Earlier 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.
Re: Julia and Mojo Mandelbrot Benchmark
#116Earlier 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.
Re: Julia and Mojo Mandelbrot Benchmark
#117there 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?
[1] https://github.com/org-arl/InteractiveViz.jl [2] https://github.com/MakieOrg/Makie.jl
Re: Julia and Mojo Mandelbrot Benchmark
#118Earlier 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.
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
#119Whilst 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…
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
#120Earlier 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?
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