Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Julia and Mojo Mandelbrot Benchmark

discourse.julialang.org

Post reply on HN
Print view View original

121–130 of 168 posts

Re: Julia and Mojo Mandelbrot Benchmark

#121

Post by suavesito »

DNF2 wrote: post #70
suavesito wrote: post #62

Earlier quoted context omitted.

I think you might not be familiar with the package used to benchmark Julia [1]. It does not fix processes to CPU's, or set kernel governor to performance, and there are fluctuations from usage of the computer. But it does run the function for several seconds and returns the distribution of the runs (the little graphics underneath the benchmarks). It calculates standard deviation and if some runs are too small (sub-na…

Are you sure the Mojo code hasn't been optimized? It seems to be hand-tuned with simd operations and multi-threading.

I cannot edit my comment, but you're completely right about it being optimised. I will say that I'm not familiar with what idioms might the Mojo compiler be able to optimise better (a problem arising with the Mojo compiler still being closed source, in comparison with the open source nature of Julia), and, in this sense, I don't know if there is more "compiler friendly" code with the same semantics for Mojo that might allow it to get nearer to Julia results.

Re: Julia and Mojo Mandelbrot Benchmark

#122

Post by suavesito »

PriNova wrote: post #48
BaculumMeumEst wrote: post #26

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?

Look at Taichi at Github. This library for Python seems not very popular and unaware. Maybe, because it is a Chinese development, but Taichi is simple and compiles directly down to kernels on CUDA, GPU, Metal, Vulkan and has batteries included. Beats the fastest Mojo implementation of the Mandelbrot set about 260 times faster. https://github.com/taichi-dev/taichi

> Beats the fastest Mojo implementation of Mandelbrot by x260 *on the GPU*.

Important detail that it runs on GPU.

Re: Julia and Mojo Mandelbrot Benchmark

#123

Post by kinjba11 »

yewenjie wrote: post #108

Does anybody know if Mojo seriously want to be a closed-source programming language? Or is it a publicity stunt?

It's in their FAQ.

> Why not develop Mojo in the open from the beginning?

> Mojo is a big project and has several architectural differences from previous languages. We believe a tight-knit group of engineers with a common vision can move faster than a community effort. This development approach is also well-established from other projects that are now open source (such as LLVM, Clang, Swift, MLIR, etc.).

https://docs.modular.com/mojo/faq.html#why-not-develop-mojo-...

Re: Julia and Mojo Mandelbrot Benchmark

#124

Post by bwanab »

nologic01 wrote: post #98
torrance wrote: 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).

An even more interesting question is: which version will actually entice millions of independed and variably motivated actors from all walks of life to commit and invest to a particular ecosystem. Technnical and usability aspects play only a minor role in technology adoption. In particular the best technology doesnt always win. My humble two pennies is that Julia is missing the influencer factor: being endorsed by wi…

You may very well be right, but for my money Alan Edelman (MIT) is influencer enough.

Re: Julia and Mojo Mandelbrot Benchmark

#125

Post by patrick451 »

nologic01 wrote: post #98
torrance wrote: 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).

An even more interesting question is: which version will actually entice millions of independed and variably motivated actors from all walks of life to commit and invest to a particular ecosystem. Technnical and usability aspects play only a minor role in technology adoption. In particular the best technology doesnt always win. My humble two pennies is that Julia is missing the influencer factor: being endorsed by wi…

I've tried julia a handful of times. IMO, the thing slowing adoption is that the usecases where julia feels like the most powerful, optimal choice are too limited. For example

- Slow startup times (e.g., time-to-first-plot) kill it's a appeal for scripting. 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.

- Garbage collection kills it's appeal for realtime applications.

- The potential for new code paths to trigger JIT compilation presents similar issues for domains that care about latency. Yes, I know there is supposedly static compilation for julia, but as you can read in other comments here, that's still a half baked, brittle feature.

The second two points mean I still have the same two language problem I had with c++ and python. I'm still going to write my robotics algorithms in c++, so julia just becomes a glue language; but there's nothing that makes it more compelling that python for that use. This is especially true when you consider the sub-par tooling. For example, the lsp is written julia itself, so it suffers the same usability problems as TTFP : you won't start getting autocompletions for several minutes after opening a file. It is also insanely memory hungry to the extent that it's basically unusable on a laptop with 8gb of ram (on the other hand, I have no problem with clangd). Similarly, auto-formatting a 40 line file takes 5 seconds. The debugging and stacktrace story is similarly frustrating.

When you take all of this together, julia just doesn't seem worth it outside of very specific uses, e.g., long running large scale simulations where startup time is amortized away and aggregate throughput is more important than P99 latency.

Re: Julia and Mojo Mandelbrot Benchmark

#126

Post by suavesito »

ubj wrote: post #105
suavesito wrote: post #69

Earlier quoted context omitted.

Well, it is as simple as that... using PackageCompiler.jl [1] (PkgC.jl). It does create huge executable (you can easily trim them), but those are relocatable and portable between machines as they include most (if not all) of the dependencies needed to run them. They are already used in production in several places. I don't have the link at hand right now, but maybe someone else might jump to give the link to talks gi…

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.jl, but rather a design restriction given how Julia works.

Re: Julia and Mojo Mandelbrot Benchmark

#127

Post by bjourne »

DNF2 wrote: post #113
bjourne wrote: post #99

Earlier quoted context omitted.

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.

I ran this Julia code which one of the thread participants claimed to be the "best": https://discourse.julialang.org/t/julia-mojo-mandelbrot-benc... Run your own benchmarks if you don't believe me. IDGAF.

Re: Julia and Mojo Mandelbrot Benchmark

#128

Post by bjourne »

adgjlsfhk1 wrote: post #112
bjourne wrote: post #111

Earlier quoted context omitted.

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

That is not "the same as C" and you certainly do not achieve the same performance as you do with C. Furthermore my point, which you missed, was that developers typically use different methods to vectorize performance-sensitive code in different languages (even Python has a SIMD wrapper but most people would use NumPy instead).

Re: Julia and Mojo Mandelbrot Benchmark

#129

Post by sa-code »

sundarurfriend wrote: post #41
sa-code wrote: post #31

Earlier quoted context omitted.

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

My understanding is that Julia gets to be this fast because the language design was optimized for performance from the beginning, by clever use of its type hierarchy and multiple dispatch for compilation into very specific and efficient machine code (plus a thousand other little optimizations like constant propagation, auto-vectorization, etc.) LLVM helps with its own optimizations, but more and more of those optimiz…

That's fair, I'm not really a compiler person but what you said makes sense

Re: Julia and Mojo Mandelbrot Benchmark

#130

Post by eigenspace »

jakobnissen wrote: post #119
eigenspace wrote: post #83

Earlier quoted context omitted.

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…

Agreed. I was just saying the number often isn't so informative since pretty much any of these languages can achieve those speeds.

How the language gets to that number is of course very enlightening

Post reply on HN