Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mojo 1.0 Beta

mojolang.org

Post reply on HN
Print view View original

231–240 of 252 posts

Re: Mojo 1.0 Beta

#231

Post by rao-v »

QuadmasterXLII wrote: post #228
rao-v wrote: post #174

Earlier quoted context omitted.

I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. Surely this is the sort of thing compiler / language design nerds dream about? It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist! My understanding is that we…

julia StaticCompiler.jl is the closest to doing this but its buggy, the error messages are terrible, theres no documentation and its ambiguous whether its still in development. but ive looked, nothing better exists.

I’ll check it out!

https://ispc.github.io/ Also seems promising

Re: Mojo 1.0 Beta

#232

Post by tapirl »

totalperspectiv wrote: post #141

Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime that is more powerful than Zig, Rich type system, first class SIMD support, etc. Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig. Very excited for Mojo once it's…

> ..., comptime that is more powerful than Zig

It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.

Re: Mojo 1.0 Beta

#233

Post by haskman »

coldtea wrote: post #58
haskman wrote: post #6

Earlier quoted context omitted.

Really the only thing good about Python is its ecosystem.

Nah, it's also a very fine language for getting an idea down quickly. Might not have the niceties purists like, but perhaps that's exactly it's a great language for that. It's like executable pseudocode, and unlike other languages, all the ceremony is optional. People flocked to it way before it became a "must" for ML and CS thanks to that ecosystem becoming dominant.

Look at my statement in context of Mojo. Why would someone use this language if all they want is to "get an idea down quickly"? They would just use Python instead

Re: Mojo 1.0 Beta

#234

Post by boxed »

dtj1123 wrote: post #222
boxed wrote: post #204

Earlier quoted context omitted.

I'm looking at this transcript and I'm getting a different picture than what you describe https://podscripts.co/podcasts/lex-fridman-podcast/381-chris... . Yea, he doesn't specifically say vectorization and multi-threading or whatever but he also doesn't say you don't need some skill to get to huge speedups.

Does he say that you _do_ need skill to get huge speedups? In fairness it's been a long time since I watched this, but I remember being struck by how obviously dishonest Lattner was throughout. For example at one point he talks about approachin mojo from a first principles perspective, using the speed of light as a limiting factor for what's computationally possible. Complete bullshit. You'd have to be working at the…

Speed of light is actually the limiting factor in modern chips and has been for a long time. It's one of the major reasons why process shrinks are jumps in performance: literally the speed of signals in the CPU shrinks.

Re: Mojo 1.0 Beta

#235

Post by melodyogonna »

bigyabai wrote: post #229
melodyogonna wrote: post #217

Earlier quoted context omitted.

> Why should they? CUDA is a GPGPU paradigm, AMD/Apple/Intel all ship diverse raster-focused hardware, and TPUs are a systolic array. How much can you realistically expect to abstract with unified primitives? Ah, it seems impossible to you. These are very different hardwares... It is hard enough to make compatibility among different hardwares of the same vendor. Very difficult to imagine building primitives for hardw…

> Ah, it seems impossible to you. These are very different hardwares... In effect, they are completely different hardware. The only thing any of them have in common is rasterization primitives, so unless you're focused on render workloads you're nearly better off software-accelerating the language for CPUs instead. As a point of comparison, go look at early ray tracing implementations on GPUs that have no dedicated R…

> In effect, they are completely different hardware. The only thing any of them have in common is rasterization primitives

They can also do matrix multiplication, which is the relevant thing here.

Mojo is not an OpenCL-style library; it is a programming language, and it doesn't really abstract much. However, it is designed to support compilation to exotic hardware. Cuda CPP can also be thought of as a language; however, the compilation model and core primitives are fundamentally tied to Nvidia hardware.

> Like what? None of this is a rhetorical question, explain to me what information would help bring GPUs and TPUs up to parity with CUDA.

One primitive would be a data/memory abstraction libary like CuTe but for more than Nvidia: https://mojolang.org/nightly/docs/layout/

Another is a programming model that allows you to specialise based on hardware and hardware capabilities: - https://github.com/modular/modular/blob/c71933db1b22b6a91749... - https://github.com/modular/modular/blob/c71933db1b22b6a91749...

And finally, a novel compilation model that knows how to compile and link code for esoceteric hardwares: - https://www.youtube.com/watch?v=77Z_kngHs00

Re: Mojo 1.0 Beta

#236

Post by melodyogonna »

tapirl wrote: post #232
totalperspectiv wrote: post #141

Having written a lot of Mojo over the last two year, just for fun, it's a really cool language. Ownership model adjacent to Rust, comptime that is more powerful than Zig, Rich type system, first class SIMD support, etc. Performance wise it's the first language in long time that isn't just an LLVM wrapper. LLVM is still involved, but they are using it differently than say, Rust or Zig. Very excited for Mojo once it's…

> ..., comptime that is more powerful than Zig It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.

Not OP, but see the entire section on metaprogramming: https://mojolang.org/nightly/docs/manual/metaprogramming/. Mojo's compile-time programming is influenced by Zig, but has features that are not in Zig e.g traits, generics (real generics), and constraints, that work together.

Re: Mojo 1.0 Beta

#237

Post by ilayn »

teleforce wrote: post #188
rao-v wrote: post #174

Earlier quoted context omitted.

I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. Surely this is the sort of thing compiler / language design nerds dream about? It doesn’t have to guarantee efficiency or provide cutting edge performance in any context … it should just exist! My understanding is that we…

>I still don’t understand why we lack a language that will take uncomplicated computation heavy code and turn it into SIMD / multi thread / multiprocessing / GPU code with minimal additional syntax. It's already (partly) existed called D language, by default it's garbage collected (GC), can also be program without it or hybrid. It's a modern, backward compatible with C and it's included in GCC. The linear algebra sys…

It does not have to be in Fortran. It's just historical reason. If you want a C version of LAPACK I have one for you https://github.com/ilayn/semicolon-lapack

Re: Mojo 1.0 Beta

#238

Post by dtj1123 »

boxed wrote: post #234
dtj1123 wrote: post #222

Earlier quoted context omitted.

Does he say that you _do_ need skill to get huge speedups? In fairness it's been a long time since I watched this, but I remember being struck by how obviously dishonest Lattner was throughout. For example at one point he talks about approachin mojo from a first principles perspective, using the speed of light as a limiting factor for what's computationally possible. Complete bullshit. You'd have to be working at the…

Speed of light is actually the limiting factor in modern chips and has been for a long time. It's one of the major reasons why process shrinks are jumps in performance: literally the speed of signals in the CPU shrinks.

Electrons moving through silicon do not move at the speed of light.

Re: Mojo 1.0 Beta

#239

Post by tapirl »

melodyogonna wrote: post #236
tapirl wrote: post #232

Earlier quoted context omitted.

> ..., comptime that is more powerful than Zig It would be great if you can elaborate more here. I can't make the conclusion from Mojo's docs now.

Not OP, but see the entire section on metaprogramming: https://mojolang.org/nightly/docs/manual/metaprogramming/ . Mojo's compile-time programming is influenced by Zig, but has features that are not in Zig e.g traits, generics (real generics), and constraints, that work together.

It might be feature richer, but it is hard to say it is more powerful. Sometimes, features (especially constraints) will reduce powerlessness.

Re: Mojo 1.0 Beta

#240

Post by boxed »

dtj1123 wrote: post #238
boxed wrote: post #234

Earlier quoted context omitted.

Speed of light is actually the limiting factor in modern chips and has been for a long time. It's one of the major reasons why process shrinks are jumps in performance: literally the speed of signals in the CPU shrinks.

Electrons moving through silicon do not move at the speed of light.

The speed of electricity is not the speed of electrons first of all. Secondly, the difference here is not very big.
Post reply on HN