Live data from Hacker News

Julia and Mojo Mandelbrot Benchmark

discourse.julialang.org

101–110 of 168 posts

Re: Julia and Mojo Mandelbrot Benchmark

#101

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

If this wasn't their bread and butter and not an example they picked themselves, it would indeed not be fair... But they chose this example specifically and said this is how you get state of the art performance with Mojo, so...

Re: Julia and Mojo Mandelbrot Benchmark

#102
post #72

A bit OT but what is Julia's adoption rate nowadays ? I know there are people who thinks it's the best, others thinks it's not going to cut it, but well.. In your experience ? (my experience is: a little too slow to load, type hierarchies lead to unbearable error messages sometimes but looks like a serious attempt to replace whatever language in the math/physics/stats/... space)

Hard to know really since the language is open source and tries not to be too onerous with telemetry (though there is some limited opt-out telemetry in the package manager). It's growing, but certainly not growing exponentially or anything like that. Here's some statistics from January this year: https://info.juliahub.com/julia-annual-growth-statistics-jan... Regarding your negative experiences, the bad news is that…

I know you're doing a lot of great work, I'm following Julia rather closely. It's just that as of now, it's not easy enough to grasp to make quick tests at work (I'd have some use there, but I have to be on schedule with the projects).

I've used a bit for various pet projects (mainly some graph search and JuMP stuff) and it was convincing. But now I can see Fortran perform in real production code (where it shines, at the cost of being so antiquated that it's not funny anymore) and my expectations for Julia are now higher.

I'll give it another try 'cos you spend some time answering my question :-) (and because the charts in the 2nd provided link are just really convincing)

Re: Julia and Mojo Mandelbrot Benchmark

#103
I don’t find this benchmark very relevant but I still enjoyed the article and comments.

I am keenly interested in Mojo, and have been running the local SDK for a few days on my Linux laptop.

I was also very keen on Julia a few years ago. I evaluated Julia as a true general purpose programming language: ML, DL, string processing, web use, etc., and it looked very good. Still, I didn’t switch from my go to languages Common Lisp, Python, and Scheme.

I have some hope, but limited expectations, that Mojo may become my one general purpose programming language. I started a template for a Mojo AI and general programming book. It helps me to write about new tech I am very interested in.

Re: Julia and Mojo Mandelbrot Benchmark

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

Ran faster on your machine than what? Mojo was only runnable locally starting 2 days ago, so it doesn't sound like you compared it with Mojo.

Re: Julia and Mojo Mandelbrot Benchmark

#105
post #12

Earlier quoted context omitted.

Yep, I was aware of StaticCompiler.jl. I wish it was more mature. Static compilation is indeed possible with Julia. But it's very limited in its capabilities and certainly not as effortless as a simple `mojo build myfile.mojo`.

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 another script that (hopefully) hits all the types you'll possibly need at runtime. And yes you can use `--trace-compile=file.jl` or SnoopCompile.jl instead, but this is still another step I need to worry about when compiling something.

[1]: https://julialang.github.io/PackageCompiler.jl/dev/sysimages...

Re: Julia and Mojo Mandelbrot Benchmark

#106

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?

Try Frax on iOS

Re: Julia and Mojo Mandelbrot Benchmark

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

Re: Julia and Mojo Mandelbrot Benchmark

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

If you want speed, why not use, say, GLSL, instead of C? The code is far simpler, and runs much faster than C.

Re: Julia and Mojo Mandelbrot Benchmark

#110
post #4

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.

This is my current pain with Julia. It makes deploying code require the entire environment, or a PackageCompiler built sys-image. I've played with static compiler, and other techniques. They are sadly quite brittle for my previous use cases. Lack of ability to use threads in a static compiler built binary was a deal killer for me.
Post reply on HN