[HN Gopher] Deep Dive into Ownership in Mojo
___________________________________________________________________
Deep Dive into Ownership in Mojo
Author : matt_d
Score : 47 points
Date : 2024-06-09 20:57 UTC (1 days ago)
(HTM) web link (www.modular.com)
(TXT) w3m dump (www.modular.com)
| comex wrote:
| Most of the video describes a system similar to Swift, where
| function arguments can be borrowed or inout, but borrowed
| references are not first-class types, and so you don't have
| lifetimes like in Rust. In Swift, this design definitely makes
| the language more approachable than Rust, but it results in a ton
| of unnecessary refcounting and sub-objects forced to be their own
| heap allocations, which contributes to Swift's reputation for
| terrible performance overall.
|
| But then, at the end of the video, Chris says that Mojo has
| lifetimes! ...But leaves an explanation for a future video.
|
| So I'm looking forward to that.
| raphlinus wrote:
| Until that video comes out, you can read the proposal[1]. This
| appears to be quite recent (the timestamp says 4 days ago).
|
| I personally found the writing style of the proposal to be
| clearer than the tutorial-flavor of the original blog post (I
| haven't watched the video). But that's probably because I have
| a programming language background and am intimately familiar
| with Rust.
|
| [1]:
| https://github.com/modularml/mojo/blob/main/proposals/lifeti...
| adamwk wrote:
| Swift's ownership features are still new and going through
| evolutions; so its current state isn't the necessarily the
| vision or where it will be in a year. E.g., here's a proposal
| that allows one to create a lifetime dependency between a
| function's return value and its parameters:
| https://github.com/apple/swift-evolution/blob/d9aa90bae13e35...
| ilrwbwrkhv wrote:
| Does anyone actually use Mojo for anything? Or is it like Deno
| where the founder raised a bunch of money but the language will
| never ever find market fit?
| nsingh2 wrote:
| The last time I looked at Mojo it required a sign up to
| install, that killed my interest pretty fast. Though now it
| looks like you can just install it?
| zie wrote:
| Yup you can just install it now.
| 6gvONxR4sf7o wrote:
| I don't use it for anything, but as it gets stable, I'd love
| to. I don't expect to even try it out for years, but don't
| think that means it's failed.
| toshinoriyagi wrote:
| Given how new it is, it isn't widely used yet. But there's
| always new packages being posted in the discord, and mojo's CPU
| performance is already competitive with PyTorch in a lot of
| benchmarks. GPU support is supposed to be coming sometime in
| the summer.
| cyber_kinetist wrote:
| I think the main problem for Mojo is that it really doesn't
| make the hard part of writing HPC code that much easier. Maybe
| a bit better than C++ (ex. better compile-time metaprogramming,
| built in SIMD type) - but you still have to do the dirty work
| of writing the optimized SIMD kernels, which isn't going to be
| sexy given the nature of the problem. (Also... CUDA support
| when?)
|
| I think the main advantage of Mojo would be its tight
| integration with the Python ecosystem (can conveniently call
| Python from Mojo)... Given the atrocities with existing C/C++
| build systems, guess this could be a much lower barrier for
| deep learning people to delve into HPC stuff?
| neonsunset wrote:
| Writing SIMD routines can be quite easy, at least much more
| pleasant than using intrinsic mnemonics.
|
| My understanding is that Mojo's portable SIMD builds on top
| of LLVM vector MLIR dialect, which is good. If this is indeed
| true, it would make it competitive with C# cross-platform
| SIMD which usually means just creating variables typed as
| Vector128/256/512<T> and using either the regular arithmetic
| operators on them or VectorXXX.Shuffle/PairwiseSomething/etc.
| for SIMD-specific operations without ever touching mnemonics
| (those can be intermixed behind branches of if (Arm64?) if an
| ISA of your interest has a more specific instruction, and
| these still consume the same vector types). Example: https://
| github.com/dotnet/runtime/blob/7ffb9a44ab32cd96d5684...
|
| Even higher level abstraction can be built on top of that,
| e.g. Triton or ISPC style (just no one has done that yet,
| it's a relatively new addition to the language, the closest
| one is System.Numerics.Tensors which is C#'s own baby BLAS).
|
| I'm very interested in Mojo as it seems like one of the few
| options where moving away from C# wouldn't be a huge
| downgrade, giving all the performance bits while being built
| on top of LLVM, for now waiting until it is fully open-
| sourced and becomes a public project.
| mhh__ wrote:
| I would (as in, turn-key would use it tomorrow) but it's not
| open source yet.
| Yasuraka wrote:
| The stdlib is, as of a few weeks ago. The rest I presume will
| follow once they are sure of their MLIR moat
| chrisldgk wrote:
| This is an unfair side jab at Deno, it's not being used as
| widely as Node (yet), but it's the go-to edge runtime beside
| Cloudflare workers and the underlying system powering Supabase
| functions.
| ilrwbwrkhv wrote:
| Fair fair.. They are actually used far more than Mojo.
| However the amount raised makes it very hard to pull through.
| extr wrote:
| It's too new, they're still working on it. But if it's promised
| features materialize it's hard to imagine it won't gain an
| audience. And in general I wouldn't bet against Chris Lattner.
| uoaei wrote:
| Is this important for Mojo or is this scope creep?
| ivell wrote:
| Lifetime is already a fundamental part of Mojo. At the moment
| it is not exposed to devs, but the proposal is to flesh out the
| ergonomics and also bring conceptual clarity.
| mhh__ wrote:
| It's good to have a story (I worry it's become cool slightly
| before we've hit the jackpot theory-wise, but still) for this but
| it does feel a little odd having it in "python" / a language
| which both idiomatically a syntactically isn't particularly
| interested in references and values and so on.
| lordofgibbons wrote:
| I'm honestly more excited for Mojo as a competitor in the systems
| programming space (Rust) than the ML space.
|
| Where Rust's default way of doing things gives you the most
| optimal performance (i.e no copy), you pay for that with code
| complexity and symbol soup syntax. If you want to move fast, you
| copy things, which is both ugly and wasteful.
|
| Mojo on the other hand, based on the ownership presentation, by
| default makes some assumptions on your behalf for most common
| situations that you can then override if you need every ounce of
| performance out of the program.
|
| I appreciate this approach more because I can hit the ground
| running and build something with great performance and then
| optimize it later when needed.
|
| I'm looking forward to building something with it once they
| finish their work on the networking and asynchronous libraries.
| GeekyBear wrote:
| Some more generalized information to get started with:
|
| MLIR was spearheaded by the same person who created LLVM, to add
| additional features that Google needed to build compilers for its
| in-house hardware AI accelerators.
|
| Mojo is a new language that takes advantage of the new features
| enabled by MLIR, in the same way that Swift took advantage of the
| features previously enabled by LLVM.
|
| Here's an interview with Chris Lattner discussing Mojo in much
| more generalized terms:
|
| https://www.youtube.com/watch?v=JRcXUuQYR90
___________________________________________________________________
(page generated 2024-06-10 23:01 UTC)