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

91–100 of 168 posts

Re: Julia and Mojo Mandelbrot Benchmark

#91

Post by QuadmasterXLII »

anoy8888 wrote: post #38

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

I think the secret is that python is so slow that you have to vectorize and call a library written in C to do any serious math. In 2008 this was a serious downside, but it meant that a whole community got used to slicing, multi-indexing, specialized functions like cumsum, and shared idioms. As a result, when the GPGPU revolution hit, you could write vectorized gpu code in any language, but the shared idioms meant that python programmers had the unique superpower of being able to read each others vectorized gpu code.

Re: Julia and Mojo Mandelbrot Benchmark

#92

Post by TwentyPosts »

bjourne wrote: 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...

> which I'm pretty sure beats both Julia and Mojo

Sometimes "showing the code" is not enough. Show me the benchmark.

Re: Julia and Mojo Mandelbrot Benchmark

#93

Post by sundarurfriend »

classner wrote: post #24
sa-code wrote: post #20

Earlier quoted context omitted.

The language is really new, it only supports amd64 Linux at the moment (at least publicly)

I am aware it's new, but they state for example on their website: > Write Python or scale all the way down to the metal. Program the multitude of low-level AI hardware. No C++ or CUDA required. I just thought they might already have something to show on that end...

The website is more aspirational (as a public Todo list/roadmap) than descriptive in many ways. It's more of an investor-presentation than a developer-overview.

Re: Julia and Mojo Mandelbrot Benchmark

#94

Post by eddtests »

eigenspace wrote: post #44
eddtests wrote: post #14

Mojo released an example of their new language which will mean readability and simplicity compared to the Python implementation will surely have been a requirement… I get someone within Modular doing some horrific looking low-level Mojo stuff could get it much quicker.

> Mojo released an example of their new language which will mean readability and simplicity compared to the Python implementation will surely have been a requirement… Did you read the Mojo code? It’s very messy and low-level dealing with explicit SIMD intrinsics and such.

Yea I did but after using it quite a bit over the last 24 hours since the SDK came out I’ve already seen far worse lol

Re: Julia and Mojo Mandelbrot Benchmark

#95

Post by adgjlsfhk1 »

bjourne wrote: 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...

I'm pretty sure it doesn't. That looks exactly like the single threaded code for the good julia versions.

Re: Julia and Mojo Mandelbrot Benchmark

#96

Post by thetwentyone »

cswhnjidd wrote: post #74
wiz21c wrote: 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)

I've been using it at work for almost 2 years now. I haven't used python personally since.

Same, though about 3 years here. My company (financial services) officially supports Python and Julia internally.

Re: Julia and Mojo Mandelbrot Benchmark

#97

Post by adgjlsfhk1 »

eoverride wrote: post #25
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. =)

How can Julia exceed C/C++ performance?

This is actually really easy. Most C/C++ code is pretty slow. Beating perfectly optimized C/C++ code by a notable margin is basically impossible (all relatively fast languages in the limit tend to converge to theoretical peak CPU performance), but real world code isn't perfectly optimized. The better question is on a performance vs effort graph who wins. Julia has a ton of major advantages here. The base language actually gives you fast implementations of common data structures (e.g. Dictionaries and BitSets) and BLAS/LAPACK wrappers to do linear algebra efficiently while still having your code look like math. The package manager makes it basically trivial to add packages for more complicated problems (no need to mess around with makefiles). the REPL makes it really easy to interactively tweak your algorithms and gives you easy ways to introspect the compilation process (@code_native and friends). Another major advantage is that Julia has macros that make it really easy to make local changes to a block of code's semantics that are compiler flags in C/C++. For example, consider `@fastmath`. In C/C++ you can only opt in to fastmath on a per-compilation unit level, so most projects that have one part that require IEEE handling of nonfinite numbers or require associativity in one part of the program will globally opt out of the non IEEE transforms. In julia, you just write `@fastmath` before a function (or for loop or single line) and you get the optimization.

Re: Julia and Mojo Mandelbrot Benchmark

#98

Post by nologic01 »

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 widely known entities that will attract the attention of both corporate eyes and the hordes of developers constantly looking for the next big thing.

Your money might be on Julia but $100mln was just placed on the Mojo/Modular bet...

Re: Julia and Mojo Mandelbrot Benchmark

#99

Post by bjourne »

TwentyPosts wrote: post #92
bjourne wrote: 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...

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

Re: Julia and Mojo Mandelbrot Benchmark

#100

Post by suavesito »

DNF2 wrote: post #75
suavesito wrote: post #71

Earlier quoted context omitted.

The example Mojo code does not run the computations with numpy. It uses the extensions of Mojo to do it, testing the capabilities of this extensions, which are the ones who promises the speed up. I must admit otherwise that not a lot of work has been done to optimise it as the optimised Julia version.

Why are you saying that? The Mojo code seems to have the same optimizations as the Julia code.

Edit: I see your point now. Still, I don't know if there is some specific idiom that the current version of the compiler may optimise better. :)
Post reply on HN