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

161–168 of 168 posts

Re: Julia and Mojo Mandelbrot Benchmark

#161

Post by adgjlsfhk1 »

xiaodai wrote: post #160
Joel_Mckay wrote: post #7

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

give me one example where julia has exceeded c++ perf?

Differential equation solvers. for the fully gory details, see https://docs.sciml.ai/SciMLBenchmarksOutput/stable/ (for a specific example, see https://docs.sciml.ai/SciMLBenchmarksOutput/stable/StiffODE/...). radau and cvode are the C++ solvers which are in the majority of cases inferior to the pure julia solvers (Rodas5P, FBDF etc)

Re: Julia and Mojo Mandelbrot Benchmark

#162

Post by bjourne »

sundarurfriend wrote: post #138
bjourne wrote: post #127

Earlier quoted context omitted.

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.

Just to make sure, did you start Julia with multithreading enabled? `julia --threads=auto` should do it (or `julia -tauto` if you prefer). Without it, Julia starts single threaded, which means the code does all this work to enable multithreading and then doesn't get to benefit from it.

I did. Running with threads improves performance by 50%, but is still nowhere near C performance. My machine only has two cores so threading doesn't help much.

Re: Julia and Mojo Mandelbrot Benchmark

#163

Post by sundarurfriend »

bjourne wrote: post #162
sundarurfriend wrote: post #138

Earlier quoted context omitted.

Just to make sure, did you start Julia with multithreading enabled? `julia --threads=auto` should do it (or `julia -tauto` if you prefer). Without it, Julia starts single threaded, which means the code does all this work to enable multithreading and then doesn't get to benefit from it.

I did. Running with threads improves performance by 50%, but is still nowhere near C performance. My machine only has two cores so threading doesn't help much.

That's interesting. It makes sense that a two core machine doesn't benefit too much from multithreading, but "nowhere near C performance" is pretty surprising. I'll try out both the programs around this weekend on my own fairly anaemic machine, and see how they fair for me. Thanks for responding!

Re: Julia and Mojo Mandelbrot Benchmark

#164

Post by amj7e »

patrick451 wrote: post #156
amj7e wrote: 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…

The recommended solution to slow startup times has always been keep a repl open. That's basically the same workflow as a notebook in my mind. Like I said this means there is a large class of tasks julia a doesn't make sense for because paying the startup cost is too expensive compared to python or go. I just timed vscode with the lsp. From the point I open a 40 line file of the lorenz attractor example, it takes 45 s…

I don't know man, I just tested vscode and it's almost instant, loads every function from multiple files in less than 5 seconds. I'm on a 13-inch intel Mac and Julia 1.11 master (1.9 and 1.10 should be the same).

Having a REPL open is not the same thing as a notebook, if you feel like that, cool I guess.

That thread is old and Julia can cache compiled code now from 1.9 and onward. However, it can not distribute the cached code(yet).

Writing the fastest possible real-time application in c/c++ has the same principles as in Julia. It's not as shoe-horned as you might believe.

When developing Julia, the developers chose some design decisions that affected the workflow of using the language. If it doesn't fit your needs that's cool, don't use it. If you are frustrated and like to try the language come to discourse, people are friendly.

Re: Julia and Mojo Mandelbrot Benchmark

#165

Post by bjourne »

sundarurfriend wrote: post #163
bjourne wrote: post #162

Earlier quoted context omitted.

I did. Running with threads improves performance by 50%, but is still nowhere near C performance. My machine only has two cores so threading doesn't help much.

That's interesting. It makes sense that a two core machine doesn't benefit too much from multithreading, but "nowhere near C performance" is pretty surprising. I'll try out both the programs around this weekend on my own fairly anaemic machine, and see how they fair for me. Thanks for responding!

Cool. If Julia runs much faster for you than for me I'd be interested in hearing it. I was honestly surprised the performance was so bad so perhaps I did something wrong.

Re: Julia and Mojo Mandelbrot Benchmark

#166

Post by jakobnissen »

DNF2 wrote: post #153
jakobnissen wrote: post #146

Earlier quoted context omitted.

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.

Loopvectorization exploits avx512, when available. How is that achieved?

IIRC it relies on HostCPUFeatures.jl which parses output from LLVM. However, this means it just crashes when used on a different CPU than it was compiled on (which can happen on compute clusters) and it crashes if the user sets JULIA_CPU_TARGET.

Re: Julia and Mojo Mandelbrot Benchmark

#167

Post by patrick451 »

amj7e wrote: post #164
patrick451 wrote: post #156

Earlier quoted context omitted.

The recommended solution to slow startup times has always been keep a repl open. That's basically the same workflow as a notebook in my mind. Like I said this means there is a large class of tasks julia a doesn't make sense for because paying the startup cost is too expensive compared to python or go. I just timed vscode with the lsp. From the point I open a 40 line file of the lorenz attractor example, it takes 45 s…

I don't know man, I just tested vscode and it's almost instant, loads every function from multiple files in less than 5 seconds. I'm on a 13-inch intel Mac and Julia 1.11 master (1.9 and 1.10 should be the same). Having a REPL open is not the same thing as a notebook, if you feel like that, cool I guess. That thread is old and Julia can cache compiled code now from 1.9 and onward. However, it can not distribute the c…

>I don't know man, I just tested vscode and it's almost instant, loads every function from multiple files in less than 5 seconds. I'm on a 13-inch intel Mac and Julia 1.11 master (1.9 and 1.10 should be the same).

I know, I'm always "holding it wrong". And that's the problem with julia.

> Having a REPL open is not the same thing as a notebook, if you feel like that, cool I guess.

Both workflows amortize the JIT times away by keeping an in-memory cache compiled code. This makes a lot of smaller scripting tasks untenable in julia. So people chose python instead. That means julia needs a massive advantage elsewhere if they are going to incorporate both languages into their project.

> When developing Julia, the developers chose some design decisions that affected the workflow of using the language. If it doesn't fit your needs that's cool, don't use it. If you are frustrated and like to try the language come to discourse, people are friendly.

This thread was about why julia hasn't seen wider adoption. It's my contention that the original design decisions are a one of the root causes of that.

Re: Julia and Mojo Mandelbrot Benchmark

#168

Post by ChrisRackauckas »

patrick451 wrote: post #167
amj7e wrote: post #164

Earlier quoted context omitted.

I don't know man, I just tested vscode and it's almost instant, loads every function from multiple files in less than 5 seconds. I'm on a 13-inch intel Mac and Julia 1.11 master (1.9 and 1.10 should be the same). Having a REPL open is not the same thing as a notebook, if you feel like that, cool I guess. That thread is old and Julia can cache compiled code now from 1.9 and onward. However, it can not distribute the c…

>I don't know man, I just tested vscode and it's almost instant, loads every function from multiple files in less than 5 seconds. I'm on a 13-inch intel Mac and Julia 1.11 master (1.9 and 1.10 should be the same). I know, I'm always "holding it wrong". And that's the problem with julia. > Having a REPL open is not the same thing as a notebook, if you feel like that, cool I guess. Both workflows amortize the JIT times…

I just tried it from the Windows command line and this benchmark with the plots ran in what seemed like instant, and some simple timing showed it was under 2 seconds with a fresh Julia v1.10 beta installation. That seems to line up with what amj7e is saying, and I don't think anyone would call the Windows command line the pinnacle of performance? That's not to say Julia's startup is fast, but it has improved pretty significantly for workflows like due to the package caching. It needs to keep improving, and the work to pull OpenBLAS safely out of the default system image will be a major step in that direction, but it's already almost an order of magnitude better than last year in most of the benchmarks that I run.
Post reply on HN