Mojo Is FASTER Than Rust
Вставка
- Опубліковано 9 лют 2024
- Recorded live on twitch, GET IN
/ theprimeagen
Become a backend engineer. Its my favorite site
boot.dev/?promo=PRIMEYT
This is also the best way to support me is to support yourself becoming a better backend engineer.
Article link: www.modular.com/blog/outperfo...
By: Mohamed Mabrouk
MY MAIN YT CHANNEL: Has well edited engineering videos
/ theprimeagen
Discord
/ discord
Have something for me to read or react to?: / theprimeagenreact
Kinesis Advantage 360: bit.ly/Prime-Kinesis
Hey I am sponsored by Turso, an edge database. I think they are pretty neet. Give them a try for free and if you want you can get a decent amount off (the free tier is the best (better than planetscale or any other))
turso.tech/deeznuts - Наука та технологія
![[UPDATE] Mojo Is Faster Than Rust - Mojo Explains More](http://i.ytimg.com/vi/MDblUyz0PtQ/mqdefault.jpg)
![[UPDATE] Mojo Is Faster Than Rust - Mojo Explains More](/img/tr.png)
How to scare a VIM user? Make them use their mouse 9:08
❤ Real talk! It's a disorienting experience, sometimes. 😅
The struggle is real.
it would be funnier if he pressed ":q" lol
Brave of you to assume I have a mouse
dude was shook tbh
write bad code -> write optimized code in different language -> post article -> wait till prime posts it with clickbait title
1. Comparison to Rust is done aganist best lib that does same operation on Rust, not written by same author.
2. Both are pretty decently optimized and have extremely similar logic flows.
Yeah and who would have thought SIMD optimization makes processing faster.. the shock..
@@J-Kimblesure but if it is easy to write simd in mojo that’s pretty cool
@@zeratax
don’t bother, yt comments are made by zombies.
'Tensor is one eigenvalue less than elevensor'
😂
lol
monad is a monoid in the category of endofunctors
Tensor is just a jagged array with 3 or more levels. Why do physicists have to make their data structures sound fancy.
@@monad_tcp It really isn't just fanciness lol, tensors are not about the numbers required to represent them in a given coordinate system, they are about making sure that no matter what coordinate system is used, you end up expressing the same quantity.
@@monad_tcpyou know tensors where arround before computers even existed right? We are talking about 1800's or so mathematics.
What an idiomatic pythonic nascent article this was.
real
The end of the blog post of viralinstruction about this benchmark sums up my thought about Mojo and Julia perfectly:
To me, Julia seems like such an obvious solution to the two-language problem in bioinformatics (and in deep learning). All the hard problems with bridging speed and dynamism have essentially been solved in Julia. At the same time, the language remains niche, mostly because it still has too many rough edges and usability issues, such as latency, the inability to statically analyse Julia or compile executable binaries. But these issues are not fundamental to the language - they're rather in the category of ordinary engineering problems. Solving them is mostly "just" a matter of putting in tens of thousands of professional dev hours, which is a matter of getting tens of millions of euros to pay for hiring people to do the job.
It does grate me then, when someone else manages to raise 100M dollars on the premise of reinventing the wheel [a.k.a. Mojo] to solve the exact same problem, but from a worse starting point because they start from zero and they want to retain Python compatibility. Think of what money like that could do to Julia!
So has Julia a smaller learning curve than Rust?
@@MrAbrazildo Julia is very easy to use. If you avoid a few common mistakes, you can quickly write fast programs. Squeezing the last drops of performance can be tough though.
They want Python codes to run fast as C lol
@@ck-dl4toI guess it's easier to make C++ has efficient high-level features, like ranges.
This argument is mostly raised by Julia fans, but it really doesn't make sense. It is more of a wishful thinking from a Julia fan rather than a good argument.
1. Julia syntax sucks vs Mojo syntax.
2. Mojo is more than Julia. It isn't "just an alternative". Mojo solves far more problems than Julia ever aimed to solve.
Some advantages that Mojo has over Julia:
1. Allows access to MLIR intrinsics directly, which makes adding support for fancy accelerators CONSIDERABLY easier.
2. Native GPU codegen allows un-before-seen heterogeneous compute abilities that is extremely simple to use.
3. Better syntax decisions
4. Supports both AOT and JIT. This makes compiler chain SIGNIFICANTLY more complex and advanced than a language that just supports 1. This is also what supercharges Mojo with dynamism of an interpreted language and performance of a AoT compiled language.
At that point, it really wouldn't make to spend dev effort on enhancing Julia. Because Julia has achieved only 5% of what Mojo aims to achieve and it doesn't start on strong foundations to begin with. If we are going to have to engineer 95% anyways, much better to start fresh with better foundations instead.
If you're writing an article that mentions performance you have to provide all the compiler options that you used. If the rust implementation didn't have the target-cpu=native codegen flag set and the --release flag then it is an unfair comparison. And since he used a library for the rust implementation true lto would also probably improve performance. So a set of compiler flags for all languages used is needed to make it a fairer comparison.
I played around with Mojo after reading that article. The SIMD type doesn’t do any bounds-checking, and also doesn’t zero-out unset values. It sacrifices a lot of safety for the sake of performance.
it zeros-out deez nutz pretty gud
And that is a good thing. Nothing more annoying than unsolicited safety
and unsolicited nutz@@Julian.u7
@@Julian.u7 Sure but the whole marketing spiel around this language was how it's literally python but Blazingly Fast™. In contrast, the code in this article would actually be much superior had it been written in C++.
I taught a bioinformatician that he could run python or rust inside the database they were using: Postgres
He took one of his jobs and moved it to the db to skip the overhead. It was a bit more than 100 times faster than how they had been doing that task.
Care to elaborate or drop some keywords about this? I'm curious about how it works and what we can do with it.
Thanks!
@@farrela.846 you can run your code within the context of the database server rather than have your code fetch data and push it back over a high overhead connection.
PGRX is the rust option pl/pythonu is the Python option
@@farrela.846 pgrx pl/pythonu
@@farrela.846 Postgres Procedural Languages
Reminds me of EVCXR, which can be used in jupyter, but I **think** PL/Rust compiles at creation time
Chapter 46. PL/Python - Python Procedural Language of the postgres docs, which is crazy that I didn't even know about until just now despite using both Python and postgres daily since like forever.@@farrela.846
Mojo won't be useable until it goes Open Source and until it fulfills its promise to be an actual python superset (it still calls the underlying python runtime for pure python code)
What do you mean? Why does calling the python runtime makes it not a superset of python? If it's straight up python with some added things its a superset in the most literal way possible.
Cython better?
I tried it it took me 1 min to hit that I can't create a "class" and I can't use f-strings. The "superset" of python at this time is all marketing. They shouldn't have released anything until python was fully implemented. Why not do that first, then add new features? I kind of feel like they are just taking advantage of every python developer's desire to have a faster python.
Open source enthusiast 🤓
lol
No performance benchmark articles or claims should be taken seriously unless they provide the full code examples, environment details, and details of all optimizations applied. Saying x is faster than y is "trust me bro" level.
Oh man, go look at the embedded ML space. It's so littered with this exact problem.
Watch Mojo be the name of some obscure snake species.
No. It's the name of a big (music) concert promoter. :)
Watch WatchMojo make a video of the top ten comments accidentally mentioning WatchMojo.
iterators/generators/coroutines are actually faster than traditional (while and for-in) loops in python because they are very thin c-wrappers under the hood (thinner than the original ones).
Yes but u r still stuck with dynamic typing and the gill
So every single operation is a type check and the you preform it and on top of that you can't use ur 32 cores...
If mojo solves this it could be nice but gill is actually a key thing for a lot of the c packages that ai uses. And u need to then compare to Julia and R and I doubt it would be much better.
Cython existed for quite a while And it was used to write a lot of these packages. It also gives u low level control and other nice stuff.
I think mojo can be basically tensor cython which would be really nice but not a take over everything very nice.
It still has a compile step which is a bit to slow for my taste
@@nevokrien95Mojo has static typing. It also has structs which are a static version of classes. No additional runtime checks if a field exists are needed. It supports simd parallelization and even running your code on the gpu in a pretty simple syntax if I remember correctly. You should check out the original Mojo demo/teaser video.
Is that true though? Aren't they "just" faster because they avoid appending to a dynamic array all the time?
@DoomTobi dynamic array appending is 100% fine even c++ does it. Sure usually they reserve it but like.. log(n) slowness is probably not it.
Gens and maps are not that much faster in my exprince. U can use ThreadPoolExecutor and map on it then it's like 20x faster because it actually uses the god dam cores.
In a regular python for loop here is all the operations I can think of:
1. Allocate a new heap object for the loop var and write to it.
2. Type check the loop var
3. Actually do the arithmetic
4. Decrement the var reference count
5. Figure out the var is our of scope later on.
It's like 4 junk operations per actual thing. BTW 5 is actualy very slow it's a whole graph dependency thing and 1. Fucks ur cach locality.
Now if u r using a generator and a sum u can change this to
1. Get the next pointer
2. Follow it to the object
3. Type check the object
4.do arithmetic
Because u know build in generators don't get to bleed references out. And u know a + operation on an int or float does bot requite u to save the object. And you know because if the Gill no one is freeing those objects.
So are they actually use this trick? Idk I bet pypy does and I would venture cython is doing so as well
@@nevokrien95 Compiler does
The best-case scenario isn't to have a fast programming language so that data scientists can write optimized versions of their algorithms; it's to have a high-level library that does all of those optimizations for free. Way faster experimentation speed this way.
The rust crate is searching for both '
' and '
' while the Mojo function is only searching for one character which defaults to '
'. Is it any wonder the Mojo version is faster when the Rust version is doing twice the work?
As a seasoned HPC developer I have to confess the lack of scientific, mathematuc and engineering knowledge of the average FANG drone is as mindboggling as it is scary.
I really have no idea what they teach you for four years of a CS degree at the uni. Fingerpainting, seemingly.
Bioinformatics often relies on CLI tools, embarrassingly parallel tasks, and pipelined data processing. I think Rust is positioned well for the CS/Bioinformatics methodologist, but maybe not with universal appeal given the learning curve, for data analysts.
Sounds interesting, could you elaborate? (tag me/like the comment so i get a notification)
rust is the worst when it comes to GPU computing
5:08 The term for idiomatic Rust should be 'Rustaceous'.
Why not just "Rusty"?
@@iAmPyroglyph Because I think 'Rustaceous' sounds cooler, and also because it sounds more like it's related to 'Rustacean'.
Rustalicious!
Rustic
Bioinformatician here (yes, it's a real field of science!). Most of us come from a bio or stats background and were then taught how to program and how to use analysis tools in grad school. Most of us are unfamiliar with low-level languages such as C or Rust because loads of us didn't have a solid CS background and the learning curve is just too steep for people whose main focus is solving biological issues and keeping up to date with literature and modern data analysis techniques. So most low-level tooling is actually made by CS people working in collaboration with bioinformaticians. I mean... think about it, low-level programming is as hard as it is for full-time computer scientists and requires loads of deep knowledge on how CPUs, memory and OSes work now couple that with also having to master the complex science which is biology, knowing how genes, transcription, translation, mutations, DNA/RNA works and large biochemical regulatory networks and you can see why Python and R are so popular in our field. The barrier of entry is much lower for people from hardcore biology backgrounds and it allows us to engineer performant enough complex data analysis pipelines without having to understand and worry about stuff like memory allocation and pointers...
You may want to check Julia then. It was designed specifically to be as fast as C and Fortran, but as easy to write as Python, but with more modern syntax.
@@halneufmille I'm aware of Julia, though it seems more like a replacement to MATLAB than Python, it seems more geared towards engineering than data analysis
"Mojo is faster than rust"
And the whole article contains just a sentence mentioning rust once that saying "I implemented it in rust and it was slower"
Let's just make jokes about the author and say like he just compiled without a release flag or something
Not shwoing any of the Rust code makes this highly sus...
I have a weird suspicion that they might have even done a debug compilation instead of the optimized one.
The fact that we cannot check even for that typical mistake is very suspicious.
According to their Github page however their implementation and needtail have pretty much the same performance (sometimes one wins, sometimes the other). Unfortunately I can't reproduce them since Mojo on my PC (WSL) immediately segfaults due to issue 1260...
Also, this is nothing particularly difficult to code: the benchmark is just measuring how fast you can read a file and split it into lines.
Worked with some of the people doing "bio-informatics" for two years. They don't code, nor do they have desire to code. I was paid to code, while they were dealing with cells, sequencing, proteins and bunch of other things that I had zero interest in. Some of them are as autistic as average programmer, meaning some of them are decent company.
This is not generally true. We are split between data analysts and methodologists. Most code the equivalent of a data science and data engineering level. Methodologists can be mathematicians and computer scientists, and code at a deeper level or more esoteric level. Hence the two language problem cited above.
I don't remember if they were able to leave it on but one thing to keep in mind on C vs Rust is, if LLVM works correctly now, Rust's aliasing rules allows avoiding rechecking memory to ensure the register and memory are still in sync since C lets you arbitrarily alias a block of memory infinite times with multiple of them being writeable.
As I understand it tensors are n-dimensional matrices with all kinds of matrix operations and "broadcasting" of other operations (think SIMD, but because n-dimensions more complex and you have to think about what is happening rows/columns wise). Good tensor libraries have multiple kernels, usually you use a GPU (CUDA) kernel where all the operations run in parallel on your GPU(s). Therefore your ML program can be written in Python, since the actual heavy operations are (JIT compiled? (dunno) and) run on the GPU.
PS: Out of curiosity I started to write a small matrix (not tensor) library in Rust nightly. You can do fun optimizations in Rust because of the ownership model where you elide allocations. Think you do mtx1 + mtx2, but at least one of the parameters are passed as owned. You can impl the Add trait so that in that case you simply reuse the memory of that parameter and do a += instead. However, there are limitations. To make this all somewhat nice you need to use nightly for better const generics and it all gets really complex and redundant quickly and I managed to crash rustc.
a tensor is just an element of a tensor product of vector spaces :thumbsup
The "right" way to handle those kinds of optimizations is with expression templates (C++ name ofc, have no idea what the idea is called in Rust but from what I know it should be possible). The idea is that you build the computation graph in the type system. For example, instead of having the result of mat1 + mat2 be another matrix, you have it be a MatPlus. Then if you do (mat1 + mat2) * mat3, the type will be MatTimes, and so on. You only actually effect the computation when you actually want to store the result somewhere, at which point the whole thing can be optimized by SIMD, fused-multiply-adds, whatever makes it fastest while minimizing cache misses.
Prime: "idk what a tensor is"
Me, a math major currently learning tensors: "idk what a tensor is either"
that "cool story bro" sounded personal lol
it’s hard to compare the same class of programming language on performance as any language of the same class ( gc, vm, etc ) can be optimized by their respective compilers to relatively the same performance as everything gets to machine code eventually, what does make the difference is whether the language is able to allow the dev to express the most performant set of algorithms that is allowed by the target hardware resources ( cpu, gpu, memory, disk, etc ). it seems mojo is able to expose these interfaces ( simd vectors etc ) more than other languages doesn’t mean that those other languages can’t also have these interfaces as well. it comes down to what provides the easiest path for the domain experts to do what they need to do.
The whole article smells of GPT.
Bro dropping new words in his articles
Nascent looks to be nascent
You know when anyone can be a developer these days when you hear them saying 'bro' 😂
@@jazzycoder r u retard?
nascent comes from Latin, so if you speak any language other than English that happens to be Latin based, it suddenly becomes not that fancy
This was the weirdest watch mojo I saw.
1:10 thousands of machines each worth several millions of dollars
9:08 Average VIM experience
Why don't they use a binary file format for such massive datasets?
Was wondering the same because especially field 2 has just 10 possibilities, ie, you could pack each element into a nibble and make it 2el/byte. Just that would shave 50% of field size (~25% of the file size)... field 4 is only 7bit (if my math didn't fail me) so, could also shave another 14% by packing 8char>7bytes (of the field), ~7% of file size. All in all, you could definitely gain a lot from just going binary, as just reading such huge files is a lot of I/O time.
But truth be said, the whole thing is so repetitive it just screams COMPRESSION!!!!! :P
the real crime is reading in 4x the data than is required due to using plaintext...
Right! It doesn't make sense
Each letter could be represented in 2 bits! since the only possible letters are A,C,G,T
They could reduce memory usage by 4x by switching from one byte letter representation to 2 bit letter representation
@@ErazerPTwhile applying for a DNA sequencing company they only seek for differences from a normalized DNA sequence is kind of misleading think they sequence the whole DNA it takes 7 days to make the comparison and find differences. Maybe is faster now this was 6 months ago I did not make it as an bioinformatician. 😢
@@minerscale 4x is a bit hopeful, but credible. Just tried plain old lzma2 and it was 56>20MB (2.8x), and that's a compressor that knows NOTHING about the format. A proper binary representation could probably arrange things in a way that bitstream compression could exploit to at least 3x+. But yeah, s**t format. Just seeing stuff like start_time=2020-02-26T02:02:24Z makes me wanna scream.
Mojo seems like a movement towards rust while retaining python syntax to an extent, they have structs and traits over classes and OOP world.
SIMD done in intrinsics in Rust will probably beat the pants off of that implementation. The beauty of Rust in this case is, even if it's just a kind of assembler without the explicit register bookkeeping, that its typing system makes you more aware of float to int type conversions, which are very expensive. Porting my intrinsics from C over to Rust yielded a nice speed boost.
"Everybody I know who does Julia loves Julia" - Prime, 2024
0:45 This actually brought back a core memory. Back when I was in highschool, I used "learnt" a lot because it was how English was supposed to be. But I eventually figured out that few English speakers actually knew that, and used learned instead. Now, I intentionally use the incorrect learned form because it's just how the language evolved. Learn just isn't treated as the irregular verb it is.
Good on you for having learned a second language.
Start calling people "my learned friend" where you voice the last 'e' and we can start a movement
You can almost always write a faster version if you make some assumptions: "No, that format is outdated", "Nah, surely there will be no right-to-left languages used", "Of course every file will end with an empty line" and so on. And even if you write code in accordance to specifications, other widely used tools almost always will have quite a bit of QoL features, which can easily become dealbreakers for end users.
As an example, GNU grep does support Perl-compatible regular expressions (using -P flag), while POSIX grep does not. If you write your blazingly 🔥fast 🔥Mojo 🔥grep 🔥that is only POSIX-compliant, it will work for some users, while many other users (including myself) won't even consider it.
Dude, you are breaking the green screen with your hair!
Is this the one he forgot to compile in release mode ?
Nooooo say it ain't so
1:55
Write your critical path in a way that mostly uses primitives and you're good to forget about GC. In fact, most popular jvms have escape analysis implemented to allocate objects on the stack instead of heap, so if you're careful enough you can use classes too.
Not that I am a fan of Java, but if they can write low latency algorithmic trading systems (tens of microseconds or lower to deserialize a price tick, make a decision, prepare an order, serialize and push it out to the network card), high throughput message processing system (Kafka), or highly optimized low latency, concurrent, lock-free queue (LMAX disruptor) then I'm sure it can handle bioinformatics too.
0:39 Hey Prime, ya can’t have GREEN HAIR and a GREEN SCREEN at the same time
I spent a lot of time in python and I'm very glad that I did, because it never needed to be fast, in fact it could have been 1000x slower and I still would have got the same experiments/prototypes done. I swapped when I started trying static analysis, which was just yelling about a bunch of my old code not adhering to stylistic standards or because it couldn't infer what I was doing with certain variables, at that point I might as well strongly type and get useful comments from the linting. I haven't really looked at Mojo, but Rust has some very tasty generics and meta-programming, which has the potential to let you get a lot more done with less code, which is what I've always loved.
Python has type hints you know?
@@vatanak8146 I know, but when I tried it, it was hit and miss. It's funny though, because if you don't want random warnings (from rufflsp I think) everywhere you end up having to explicitly annotate more variables than in rust.
I call it BS, exactly like the guy from Reddit. As someone with MSc in Electronics & Computer Science in Medicine, I've done some stuff with bioinformatics algos in Cpp (even though it wasn't my main field of expertise) and I doubt that this mojo code can outperform highly optimized and battle-tested Cpp parsers (written by much smarter and better-paid people than this article's author). I feel it's the same as their example with mojo magic being faster than their hand-written Python code for matrix multiplication instead of benchmarking it against numpy (which has nothing to do with python because it's a wrapper on 40 yo Fortran lib).
Again, it's an advertisement full of BS - if it was so great and magical, it would be open source already.
1:07 no, you got that all wrong, it's "thousands of [...] machines"! The "thousands" is the number of machines, and "multi-million dollar" the price of each machine.
Which mounts up to billions of dollars worth of machines, and it's what he said...
@@yakocal No he said "most people say 'billions'" suggesting that the phrase could be simply re-worded to use the shorter "billon" somehow. I disagree with that statement and assume it has only come about by misunderstanding of the sentence structure.
I mean, tell me, how WOULD you re-word this? You say "billions of dollars worth of machines". But that sounds weird, too, and loses informations, as in "billions of dollars worth of DNA-sequencing machines are working non-stop ...". Arguably the "thousands of machines" is the CORE information here, given the sentences around it focus not on economics ("how many dollars") but on scale ("how much data processed").
@@steffahnso we conclude that it's subjective...
hyperfine, which he used as benchmark tool, actually does a few runs under the hood, and calculates the standard deviation etc. for it.
So it's not 'just one run'.
Still, as others highlighted, there are a few other things where at the very least he did not prove that he did it right. Such as whether he used SIMD in Rust (likely not, and SIMD can easily be responsible for more than a 50% speedup).
Whether SIMD in Rust is in an usable state is another question. I've never tried it myself (in Rust), that that could be a good motivation. But it's a less catchy title.
Honestly Mojo as a language is very tempting to me. I love Rust, but really, getting others to use it, when it does take a decent bit of time to do properly, is difficult, and must be justified. Mojo promises me the ability to write similar code to Rust, while still being at least somewhat editable for others. The big issue with Mojo is licensing (and, underlying, the VC funding of Mojo). Frankly I don't see how they intend to make back their money without eventually doing things I'm not going to be happy with.
"Biggest takeaway" this keeps me coming back
Mojo looks fun. Been doing Aoc with it, but it is still way too early for it! I ran into multiple bugs when using parallelism
I switch from Python to Julia to do my PhD and it's amazing! I have a bad feeling Mojo will kill Julia and waste all that effort just for non-CS devs to avoid learning a new syntax.
This already existed. It's called Julia. You'd have to get all those people to move over. It's too late.
My guess is that people will favor mojo heavily when doing initial parsing and tesintgo ut theories and when it gets cemented then it'll bee pushed voer to whoever was doing the super optimized versions befroe but now they can work on larger data sets while testing theories
I work as a researcher, and I'm building these kinds of tooling and data pipelines, but have literally never heard of anyone using Mojo. The general consensus is that it's not even a contender until they open source it. I haven't even heard anybody talk about it for at least a few months, which in the machine learning world is an eternity. I legitimately forgot that they existed. Even if Modular does open source it, I doubt their ability to beat the Huggingface model serving ecosystem, which is all in Rust. I hope that Modular pivots before they burn the whole hundred million dollars they raised. I don't think they actually understand the problem they're trying to solve.
i just saw this blog, and just looked up , here it is 😂
the more stuff i see from prime about new languages, the more i think c might just be the best tool for the job.
Prime nailed this take regarding likelihood of adoption. Most in that field would find more use in a fast simple language. I’d be more curious how Mojo compares to things like GO and Cython than Rust. Just because they seem to be after a similar niche
feel you on the idiomatic
Bro, i’m no a native speaker, you’re the only UA-camr for which I put videos @ 0.75 speed
I used SIMD and it was faster than not using SIMD: The article
3:08 The most amusing to me is that there exists a class called "Wirth languages"
I live for Prime's thoughts. It is interesting such a claim to be faster than Rust. Single algorithms can't be taken in a vacuum. I would love to see a larger set of benchmarks.
Or even the Rust code used...
@@thekwoka4707 And the Rust compiler flags. In the end Rust also uses LLVM as compiler backend so this 50% claim is difficult to take serious without more details.
This code has been heavily criticised in the Rust community, and it's expected that, done properly, rust will be faster. It's a clickbait article.
Luca Palmieri has a new admirer 🇮🇹
Mojo is like a tiny pebble in Rust's boot. 👌
Video was cool, though! 👏
Mojo jojo
Wasn't there a MoJo something used to create the WebOS software for the Palm phone?
For such small programs, the progress bar is the thing that slows down the program the most. Looks pretty, very cool for writing heavy duty stuff, but unless your benchmark runs a minute or longer, you should disable the bar and then do it for fair results.
Zero2Prod is a great book for sure.
It feels like Actix and „unsafe“ drama.
11:25 I agree 100%
I don't think I can say Mojo in anything other than Mojo Jojo's voice. Maybe Dr. Evil's voice if I try hard enough :D
In Rust: A value of type char is a Unicode scalar value, represented as a 32-bit unsigned word ...; In C and probably in the propietary Mojo: 1 char = 1 byte unless another encodings are used. It's why, for 4 letters, ACGT, Rust is worst in speed managing pure ASCII characters.
IMO mojo seems really promising, lets hope it will get open sourced soon.
It seems like a great alternative to python or matlab for research
Mojo-jojo
When I heard "Java" in context of "highly optimized tools" I had to take break and walk around to feel better...
Wild idea: ThePrimeagen may one day say "the name is or at least somewhat resembles ________". Not sure in what context, but it's theoretically plausible.
In the data world, C and C++ are always winner.
You are 100% right about Mojo!
+1 to "Zero to production in Rust" is one of the best Rust books!
Just wondering if the Rust Community could come up with an equally fast solution. Unfortunately the article did not show any code.
Python:Mojo :: JavaScript:Typescript.
Look how Typescript has taken over from JS. Same thing will happen with Python -> Mojo.
I'm surprised you never saw it before, I've heard and seen pythonic many times when talking about languages that are pythonic like nim, lobster and mojo (and boo and genie, in days of yore)
Those writing Mojo off are very funny. Mojo is just a user interface for MLIR; Chris Lattner and his team wrote MLIR by hand and validated it can be just as fast as Assembly and so performant enough to handle workloads they intended to take. Mojo is just a user interface so they wouldn't have to write MLIR by hand anymore, they could have made it look like anything, they chose Python because that's what the ML community is familiar with. Speaking of Chris Lattner ... That is the same person that started LLVM, Clang, Swift, and MLIR. This isn't some random compiler guy claiming some things, there are track records.
That’s great… but that just makes me think it will never be an actual Python superset and they only said that for marketing.
@@anonymousalexander6005 Python isn't hard to implement, there are just 36 keywords, and straightforward semantics. The part that makes it a superset is what they're currently building, and that is the low-level parts Python doesn't have. Also, being a superset is a long-term goal.
I thought automatic vectorization was a solved problem. Turns out it isn't when you have heterogeneous architectures.
This is true, Chris is a beast that cant be underestimated.
I mean LLVM succeeded despite being mismanaged mess, not because of it, swift didn’t get good until he got booted of the project and MLIR hasn’t been widely used yet, so as far I am concerned everything lattner touches is vapor ware until proven otherwise.
"Thousands of multimillion dollar machines" is not the same as "one billion dollar machine". Each machine is a multimillion dollar machine, and there are thousands of them
The problem is that mojo is just using python as a front end for portable simd instrincs. You still need to understand cache coherence and vectorized instructions. Changing the syntax doesn’t just make the barrier to entry lower. I personal use Rust for all my ML and research work.
Retwisssh! 🔥
Go is an awful name, not search friendly at all. If we're talking about good names, Haskell comes to mind or Elixir.
You would expect a google-able name from a language developed by Google, but nope.
It's nuts how python (and now mojo) with heavy type annotations looks about as verbose and cryptic as template-heavy C++, except that templated C++ is better because templates are structurally typed, which ironically would fit better with the python usual duck typing. Like just use C++ at that point, you're not really gaining anything by deleting the braces.
let bro cook
Java, ya dude, big data infrastructure is all jvm’s. Hadoop is Java, Spark is Scala, Elastic is Java, etc etc
Being honest when Machine Learning was all the rage I was surprised to see that the big language of choice was.. python.. Of all things, and not Java.
The reason for python is 2 things.
1 array are nicer to handle in python because list comprehension is useful.
U would not belive how many times I print data that I list comprehend to get a picture kf what's going on.
2
Ai reaserch isn't production code its all dev which means it's VERY hacky. Like I would go and read private vars left and right just to get a grasp of what's going on.
Or I would also overwrite forward with my_log(forward) to get an idea of what's actually happening under these abstructions
In java such a thing would be impossible, which means some tasks I could solve in a hack way in python r unsovlble in java...
Also python has better c integration and u gota remember that ai used to be done In c++ so porting that into python Is a much easier task.
Also python code for ai tends to be more framework independent since u don't have static typing and TENSORs are the same thing of they r np array tensorfloe or pytorch for the most part
Is it worth it to learn Scala as an aspirant to Data engineering and Big data field? Or just stick to Python and SQL?
The real takeaway of course is the fact that "having to learn just a bit more and achieve something much better will always beat having to learn something totally new". Which is, for me at least, why Next won the React SSR wars: it was React as you know it, with one opinionated thing (routing) and an extra function to have server processing before delivering the finished rendered stuff to the browser. You could literally take an existing small but actually in production React application and convert it to SSR within an afternoon.
Remember: developers are users too. And when we get into "user" mode, woe and behold we are *far worst* than the users of the applications we create.
29secs in. I am super fan around here
ps. I know nobody cares but I love it
Interesting topic … and one I can understand. 🙂One of our senior bioinformaticians at work recently used Rust to do some DNA analyses and he shared the code with the NGS data analysis group. Rust has chance. lol.
If anything is fast it’s me moving away from a language when it’s called Pythonic.
🔥
Mojo is still a buggy mess...
I tested it on their cloud it broke with very small changes to what they did
It dosent boot on my machine at all like just crashes on install in very nasty ways
Basically if it works it can be fast but it just breaks all the time
I'm pretty sure Julia was created to do exactly what Mojo 🔥 is now struggling to do.
Julia syntax is intuitive and familiar to Python programmers. It has a thriving ecosystem of libraries and has seen massive adoption. It has an excellent C/C++ interop.
Why do we keep reinventing Python?
because data scientists are so stupid that they can’t write code in languages other than python. fact.
Julia just failed to find a company to invest in it
Mojo will kill Julia and waste all that effort just for lazy devs not to learn a new syntax. I hope time proves me wrong :(
@@RazgrizDuTTA Well I quite like Julia as a language but at the end of the day I really do not care as a physicist who wins in between Julia and Mojo. I just want a performant modern language using which I can get my work done.
@@kinomonogatari I understand your point of vue. I wish I was that pragmatic. In my case, I do linear algebra for computational mechanics. I absolutely despise the Python Numpy and Scipy design and syntaxe so I hope Julia will survive along with all the great linear algebra packages developed by the Julia community.
As a CV/ML Python developer, I despise Mojo's marketing. It's an interesting project with some good potential (especially if they end up opensourcing it), but their marketing is full of borderline lies and clickbait.
If they think that this kind of publicity will help their project, they are sorely mistaken. All that they have done is train their potential users not to trust a single word coming out of their mouths.
smh
i live in a simulation.
all hail to Mojo
mojo is not faster then rust, in the article he quiet literally said that he spotted a mistake/oversight and implemented it better.
edit: not true, author didn't say that in the article
also in bioinformatics redundant checks can save a life. as i see it - DNA -> cancer -> therapy with radioactive elements -> if u screw up, u die
couldn't find that quote in article. Care to add it here?
@@piyushbansal3734 so... i apparently cant read. i was talking about "In addition, I explored optimizations from C/C++ implementations ..."
sry for that, as i read it for the second time, it really seems that the author of the article says that those implementations are equal (optimization-wise)
@@josefkaras7519you actually admitted your mistake. That's rare on the internet these days.
Kudos to you 😃
@@aneeshprasobhanI’m more surprised that someone who understands code admitted they were wrong. It’s a double whammy for me. Next thing he’s going to say is he reads documentation before starting a project, lol.