Live data from Hacker News

Julia and Mojo Mandelbrot Benchmark

discourse.julialang.org

81–90 of 168 posts

Re: Julia and Mojo Mandelbrot Benchmark

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

> A more interesting question is which version is more elegant, ‘obvious’ and maintainable. (Deeply familiar with both, but money is on Julia). Yes, more than raw speed, what impresses me is that the version of code in [1] is already a few times faster than the Mojo code - because that's pretty basic Julia code that anyone with a little Julia experience could write, and maintain easily. The later versions with LoopVe…

User lmiq articulates the sentiment well in a later comment in the OP thread:

> what I find more interesting here is that the reasoning and code type applies to any composite type of a similar structure, thus we can use that to optimize other code completely unrelated to calculations with complex numbers.

It matters less whether super-optimized code can be written in Julia for this particular case (though there's some value in that too), the more important and telling part to me is that the language has features and tools that can easily be adopted to a general class of problems like this.

Re: Julia and Mojo Mandelbrot Benchmark

#82

It is still fascinating that lisp languages lost to python for AI and data processing and now pretty much everything else. In a perfect world , we would be using lisp or lisp like languages for everything

It is still fascinating that lisp languages lost to python for AI and data processing

To a first approximation, the only people that love lisps are people with a solid computer science background, and most people working with AI and data processing day to day do not have a computer science background. They're scientists, engineers and mathematicians who see programming and programming languages as a tool needed to do their 'real' job and not as an end in itself. Python is the perfect language for people who want to learn as little programming as possible so that they can get on with what actually interests them.

Re: Julia and Mojo Mandelbrot Benchmark

#83
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 be seen as a strongly deciding factor though.

Re: Julia and Mojo Mandelbrot Benchmark

#84
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 we haven't solved those issues, but the good news is that we're making real progress on them. Version 1.9 released in may of this year and is the first version to cache native code from packages, which makes loading of julia code MUCH faster through more AOT compilation, and there are even more improvements coming in v1.10 later this year. https://julialang.org/blog/2023/04/julia-1.9-highlights/#cac...

Error messages are also receiving a fair amount of attention, but it's a hard problem and there's less agreement on what the best way forward is. However, there's been some good work going into improving the readability and clarity of error messages that I think will help alleviate these struggles.

Re: Julia and Mojo Mandelbrot Benchmark

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

One language is literally some months old, and another is 11 years old. Not a fair comparison at this point, and for some years to come.

The gap will definitely narrow.

Re: Julia and Mojo Mandelbrot Benchmark

#86
post #63

Earlier quoted context omitted.

> I certainly consider Julia to be a Lisp Can you elaborate some more on this? My worldview assumed that a lisp used a list as a primary code/data structure and Julia doesn't seem to be doing that... Of course it does provide a way to manipulate code and data because of its macros. But what makes a lisp a lisp?

I think the commenter refers to the fact that in Julia, code is data, even if it is not represented as lists. This allows the existence of macros, which are syntactic sugar to functions modifying code. Also that most (all?) lisps have multiple dispatch as a fundamental part of the language, and Julia does too.

Every time this pops up, I feel compelled to point out how different Julia macros look like from regular Julia code, especially once the macros get complicated.

"Code as data" is not quite the same thing as homoiconicity, which I feel is Julia's missing piece.

Re: Julia and Mojo Mandelbrot Benchmark

#88

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?

https://github.com/brorson/MandelbrotExplorer

Re: Julia and Mojo Mandelbrot Benchmark

#89

I'm sorry, but it is not benchmark, it is farce. One run, 7ms, 2ms? It is statistical fluctuation, not data, especially if it was run on "typical" developer laptop under "typical" session where browsers and other high-hitters are run in background and all these turbo-boosts and freq-governors are not turned off. You need OS where almost all software (including most system services) are killed, CPU frequency is fixed…

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

#90

Earlier quoted context omitted.

FWIW, the core Julia developers seem to be taking this more and more seriously, and AoT compilation to small binaries seems more of a "when" question than an "if" at this point. Open source development - without multi-million dollar support from outside - is unpredictable, but I wouldn't be surprised if a year from now, writing a restricted subset of Julia allowed you AoT compilation to reasonable binaries (and not s…

You mean investment like this? https://info.juliahub.com/juliahub-receives-13-million-strat... You can imagine what a company like Boeing might be interested in when it comes to a programming language.

Boeing is probably interested in Julia for manufacturing optimization, so their interest is likely in improving the optimization ecosystem around JuMP [1], Optim [2], etc., and compiler improvements related to that.

But we can only guess from the outside, and it's ultimately upto JuliaHub to decide how to spend the money, so I'll cross my fingers and hope that this gets us AoT static compilation sooner!

[1] https://jump.dev/ [2] https://julianlsolvers.github.io/Optim.jl/stable/

Post reply on HN