23 ms·

Julia and Mojo Mandelbrot Benchmark

• WantonQuantum 3y ago
  Be sure to check out the comments on the page - lots of optimisations for the julia code.
  • ayhanfuat 3y ago
    Not if you want to avoid condescending "I cannot look at the Python code my eyes hurt" comments. Good to know the Julia community hasn't made any progress in that regard, though.
    • amj7e 3y ago
      Well, still a much better community than most where having an opinion is considered a sin.
      • patrick451 3y ago
        Only if it's the Correct opinion. Try being a julia user but thinking julia kinda sucks. That's a much more hostile experience than being a c++ dev and thinking c++ kinda sucks.
        • DNF2 3y ago
          It's really all down to your tone and attitude. If you're hostile, demanding and negative, you will indeed get pushback, but that's human nature. Some people feel that they should get to act like a prick, while everyone else should be humble and courteous. If you act like a decent person person, there's no problem pointing out weak points in Julia and request help to work around it. If your only input is "Julia kinda sucks", what kind of feedback do you feel that you are owed?
        • amj7e 3y ago
          There was a recent post in Julia's Discourse about why people think the language has not caught on as much as it should. There were around 550 comments where half of them talked about why Julia sucks and what to do about it, there are spin-offs of the post continuing discussion. Let's just cut the bull shit, these are all tools, if one doesn't fit you just use the other.
    • ballooney 3y ago
      I only see one of those among 32 constructive ones - a rather better ratio than this site!
    • agumonkey 3y ago
      So Julia has --pedantic by default ?
    • drt5b7j 3y ago
      [flagged]
      • ayhanfuat 3y ago
        Personally insulting someone because they pointed out something negative about the community kind of supports what I said.
    • suavesito 3y ago
      I think this is a little bit unfair. The comment refers to the Mojo specific use of [], not to regular Python. It also starts saying > I know I shouldn’t say so but I can’t help... Remarking that the comment should not be taken too seriously, as it might be inappropriate. Finally, saying the whole community is condescending given 1 in 32 comments is... a little rounding up from the statistics there.
      • ayhanfuat 3y ago
        Seems like we are speaking from different experiences. As someone who witnessed multiple requests like “please avoid hyperbole when it comes to criticizing other languages” in Slack, Discourse or Twitter, I interpret “I know I shouldn’t say so” differently. I would say 1 in 32 is also about the experience. I stopped visiting Discourse, chatting in Slack because I found it exhausting that every time Python is mentioned someone came up with a different way of saying how much they hate Python. I know I wasn’t the only one disturbed by this but in the end communities make their own choices. Sorry about missing the mojo specific [].
        • krull10 3y ago
          Someone feeling the need to bash other languages is universal. For example, every Julia post here has people bashing it, in a way that is often tangential to the topic of the post. I'm actually surprised this thread doesn't have someone complaining about 1-based indexing in Julia.
• orliesaurus 3y ago
  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
  • CraftingLinks 3y ago
    That's not what the presented benchmarks show, though.
    • adgjlsfhk1 3y ago
      What do you mean by that?
  • Joel_Mckay 3y ago
    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. =)
    • eoverride 3y ago
      How can Julia exceed C/C++ performance?
      • markkitti 3y ago
        C is not the fastest language. Fortran can often beat them because is has non-aliasing function arguments and does not treat arrays like pointers. https://fortran-lang.discourse.group/t/fortran-is-faster-than-c/5058 https://fortran-lang.discourse.group/t/fortran-is-faster-tha...
        • RossBencina 3y ago
          I do not dispute that C is not the fastest language. However C99 has the `restrict` keyword, which when combined with strict aliasing rules gives non-aliasing function arguments (I believe).
• ubj 3y ago
  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.
  • arbitrandomuser 3y ago
    If anyone is interested in compiling small binaries with Julia do check out staticcompiler.jl and supporting statictools.jl that manages to produce small binaries without the Julia runtime , Ofcourse it's a wip , and not fully mature , I'm just putting it out there for people to know. There's some really cool demonstrations come out of this ... Wasm fluid simulation in Julia: https://alexander-barth.github.io/FluidSimDemo-WebAssembly/ https://alexander-barth.github.io/FluidSimDemo-WebAssembly/ Differential equations demo in the browser: https://tshort.github.io/Lorenz-WebAssembly-Model.jl/ https://tshort.github.io/Lorenz-WebAssembly-Model.jl/ Someone even setup Julia to run on AVR mcus for Arduino (Directly using gpucompiler which statictools uses to compile to binaries): https://seelengrab.github.io/articles/Running%20Julia%20baremetal%20on%20an%20Arduino/ https://seelengrab.github.io/articles/Running%20Julia%20bare...
    • ubj 3y ago
      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`.
      • suavesito 3y ago
        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 given by Chris Rackaukas on this. From my personal experience. I've done graphical apps in GTK3 in Julia with PkgC.jl cross-compiling from Linux to Windows. And they worked. :) [1] https://julialang.github.io/PackageCompiler.jl/stable/ https://julialang.github.io/PackageCompiler.jl/stable/
• torrance 3y ago
  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).
  • sa-code 3y ago
    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
    • deleted 3y ago
      [deleted]
    • sundarurfriend 3y ago
      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 optimizations are being moved to the Julia side nowadays (since the language has more semantic understanding of the code and can do better optimizations). I believe the main thing LLVM helps with is portability across many platforms, without having to write individual backends for each one.
      • sa-code 3y ago
        That's fair, I'm not really a compiler person but what you said makes sense
  • sundarurfriend 3y ago
    > 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 LoopVectorization require more specialized knowledge , and get into the "how can we tune this particular benchmark" territory for me (I don't know how to evaluate the Mojo code in this regard as yet, how 'obvious' it would be to an everyday Mojo developer). So [1] is a more impressive demonstration of how an average developer can write very performant code in Julia. [1] https://discourse.julialang.org/t/julia-mojo-mandelbrot-benchmark/103638/16 https://discourse.julialang.org/t/julia-mojo-mandelbrot-benc...
• moelf 3y ago
  For a similar "benchmark" (also Mandelbrot) but took place in Jax repo discussion: https://github.com/google/jax/discussions/11078#discussioncomment-3051481 https://github.com/google/jax/discussions/11078#discussionco...
• rvz 3y ago
  As long as you can copy and paste Python code to Mojo and it is 1:1 compatible with all your existing libraries and is hundreds of times faster than Python, that is much better than wasting time rewriting it in another language that is 8x faster than Mojo (in its first release) with hand-optimizations from Julia language experts. I expect Mojo's first release to be fast enough that it would get the Python folks using it over Julia and that the next Mojo release or future ones will get another 8x or 10x faster. The same outcome happened with Bun 1.0 and already claimed the top spot in speed and compatibility in the node ecosystem in its first release and it isn't even done yet. The least amount of effort to get something done much faster wins by default.
  • stellalo 3y ago
    > The least amount of effort to get something done much faster wins by default. And then you’re stuck with a proprietary language “subscribe to download”? Not sure it’s the least amount of effort honestly.
    • falkaer 3y ago
      It's only closed-source for now, with plans to open-source the language when it's more finalized - similar to LLVM early on. Not sure if it says so explicitly on their website somewhere, but Chris Lattner has stated that several times
  • liuliu 3y ago
    The Mojo code in this post cannot be run in Python. So in this case, you wrote code for Mojo language, not Python.
  • PriNova 3y ago
    This is not how you think Mojo works. If you copy&paste python code into Mojo, you will not benefit from optimizations. You need to refactor your python code into Mojo code to gain compiler efficiency. But if you look at the refactored code in the end, it is very ugly syntax (this is my personal opinion and might change with the evolution of Mojo)
  • 3y ago
• eddtests 3y ago
  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.
  • oivey 3y ago
    The Mojo one is already doing some pretty horrific low-level stuff with fairly manual SIMD. That’s why it was faster than Julia in the initial example, and the edge is lost when a couple of posters did similar things for Julia.
  • patagurbon 3y ago
    We have yet to see Mojo do any "sufficiently smart compiler" optimizations that Julia or similar languages don't already do. The Mojo code in the blog post does the same ugly optimizations to get good SIMD as the Julia code. Convincing LLVM to vectorize is still a problem in both languages. I do hope Mojo can make some headway there in the future. Especially since with MLIR they might be able to capture some higher level semantics Julia can't.
  • eigenspace 3y ago
    > 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.
    • eddtests 3y ago
      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
• classner 3y ago
  Does anyone know of examples of Mojo for GPU computations? The website makes multiple claims about it being able to run seamlessly on the GPU but I couldn't find any documentation on it...
  • sa-code 3y ago
    The language is really new, it only supports amd64 Linux at the moment (at least publicly)
    • classner 3y ago
      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...
      • sundarurfriend 3y ago
        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.
• shric 3y ago
  It would have been more appropriate to render a Julia set in Julia.
• turndown 3y ago
  IMO this is just not a great example on either side. As others have pointed out, the Julia implementation was refined to be 8x faster. The Mojo code has to run the CPython interpreter to run numpy.
  • suavesito 3y ago
    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.
    • DNF2 3y ago
      Why are you saying that? The Mojo code seems to have the same optimizations as the Julia code.
      • suavesito 3y ago
        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. :)
  • Max-Limelihood 3y ago
    > The Mojo code has to run the CPython interpreter to run numpy. Yes, the need to run CPython interpreter is what makes Mojo slow (and it will remain that way, unless they abandon their "superset of Python" promise).
• BaculumMeumEst 3y ago
  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?
  • thanatos519 3y ago
    https://github.com/xaos-project/XaoS https://github.com/xaos-project/XaoS is still awesome but could really use a GPU backend :)
  • PriNova 3y ago
    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 https://github.com/taichi-dev/taichi
    • BaculumMeumEst 3y ago
      now we're talking!
    • suavesito 3y ago
      > Beats the fastest Mojo implementation of Mandelbrot by x260 *on the GPU*. Important detail that it runs on GPU.
    • xiaodai 3y ago
      but the chinese just steal american technology. look at huawei mate 60. sarcastic
  • sbrorson 3y ago
    https://github.com/brorson/MandelbrotExplorer https://github.com/brorson/MandelbrotExplorer
  • fanf2 3y ago
• anoy8888 3y ago
  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
  • est 3y ago
    And dialects of Lisp a-likes will fight each other. https://locklessinc.com/articles/why_lisp_failed/ https://locklessinc.com/articles/why_lisp_failed/
  • eigenspace 3y ago
    What do you mean by lisp-like? If you mean “primarily uses S-expressions” then I guess I dont really see why that’s so important to you. If you mean a language that is semantically similar to lisps and learned a lot of the important lessons that Lisp taught the programming world, I think Julia is one of the Lispiest languages in this space right now. The syntax may not be S-expression based on the surface, but our Exprs are actually essentially just S-espressions so writing syntactic macros is very easy. The language is about as dynamic as is possible without major performance concessions, and is very heavily influenced by a lot of design ideas from the CLOS, with some features missing but also some cool features CLOS doesnt have.
    • dan-robertson 3y ago
      I think the point the GP is making is that Julia (and other lisps) lost in this space.
      • eigenspace 3y ago
        While I consider julia lispy, I do think it's quite a reach to call it a lisp. I also think it's quite a reach to say julia lost in this space. It's still working it's way up. Julia is growing and evolving and finding new users and niches. It certainly hasn't 'won', but it's a bit early to call it a loss.
    • Oreb 3y ago
• blacklion 3y ago
  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 (all power saving technology is turned off in both firmware and OS, I'm not sure it is possible on M-based Apple laptops, and many Intel-based laptops with castrated BIOSes are not suitable too). You need warm-up loops to warm-up caches, or special code to flush caches, depends on what you want to measure. You need to have tight-loop with your function called (and you must be sure, that it is not inlined by compiler into loop) which runs enough iterations to spend at least several seconds of wall time. You need several such loop runs (10+, ideally), to have something which looks like statistics. You need to calculate standard deviation and check that it is small enough (and you need to understand why it is not small enough if it is not). Then it is benchmark. Otherwise it is FUD.
  • sundarurfriend 3y ago
    > One run, 7ms, 2ms? These are not single runs of the code. The Julia code uses `btime` from BenchmarkTools, which runs many iterations of the code until a certain number of seconds or iterations is reached. The Mojo code uses `Benchmark` from a `benchmark` package, which I assume does similar things. Beyond that, this is one person getting curious about how a newly released language compares to an existing language in a similar space, and others chiming in with their versions of the code. If you have a higher standards for benchmarks and think it will make a difference, you're welcome to contribute some perfect benchmarking results yourself.
  • majoe 3y ago
    Come on, of course this is not a thorough benchmark, but just a random thread in a forum, where someone wants to get a feeling for the performance of a new technology. They could have used @benchmark instead of the @btime macro, though. The first gives you the statistics, you asked for, whereas the second one is a thin wrapper around @benchmark, that just prints the minimal time across all runs. Nevertheless the takeaway of this thread is pretty clear, even without @benchmark: The performance difference mainly stems from SIMD instructions.
• wiz21c 3y ago
  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)
  • cswhnjidd 3y ago
    I've been using it at work for almost 2 years now. I haven't used python personally since.
    • thetwentyone 3y ago
      Same, though about 3 years here. My company (financial services) officially supports Python and Julia internally.
      • xiaodai 3y ago
        appreciate you may not want to share the exact company. is it in the us, europe, asia? I know cba and anz in australia supports julia internally for monte-carlo.
  • eigenspace 3y ago
    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-january-2023 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/#caching_of_native_code 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.
• bjourne 3y ago
  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/mandelbrot.c https://github.com/bjourne/c-examples/blob/master/programs/m...
  • TwentyPosts 3y ago
    > which I'm pretty sure beats both Julia and Mojo Sometimes "showing the code" is not enough. Show me the benchmark.
    • bjourne 3y ago
      I'll pass - Hacker News comments are not dissertations. The C code ran faster on my machine. YMMV.
      • nindalf 3y ago
        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.
      • dahart 3y ago
        If you want speed, why not use, say, GLSL, instead of C? The code is far simpler, and runs much faster than C.
      • DNF2 3y ago
        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.
        • bjourne 3y ago
          I ran this Julia code which one of the thread participants claimed to be the "best": https://discourse.julialang.org/t/julia-mojo-mandelbrot-benchmark/103638/25 https://discourse.julialang.org/t/julia-mojo-mandelbrot-benc... Run your own benchmarks if you don't believe me. IDGAF.
• mark_l_watson 3y ago
  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.
• yewenjie 3y ago
  Does anybody know if Mojo seriously want to be a closed-source programming language? Or is it a publicity stunt?
  • kinjba11 3y ago
    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-in-the-open-from-the-beginning https://docs.modular.com/mojo/faq.html#why-not-develop-mojo-...
• demandingturtle 3y ago
  [dead]