Why is Mojo's dictionary slower (!) than Python's?

Seriously, I don't know why. Leave a comment with feedback on my Mojo script.
Take a look at my Mojo script here:
github.com/ekbrown/scripting_...
And here's my Python script:
github.com/ekbrown/scripting_...
Here's the Mojo language:
www.modular.com/max/mojo
BTW: I used the Elgato Wave 3 microphone in this video:
www.elgato.com/us/en/p/wave-3...
Here's a follow-up video in which a hand-written hashmapdict in Mojo (thanks to Maxim Zaks!) that is faster than Python's dictionary:
• Mojo hand-written hash...
#mojolang #python

[@hyperplano]

In the discord channel I read the current dictionary implementation is not optimized. It's been included to allow developers to experiment more with the language, but it will be optimized in future releases.

[@earlkjarbrown3753]

Great to hear! Thanks for pointing this out.

[@ekbphd3200]

Thanks!

[@brendanhansknecht4650]

Python actually has a realy optimized dictionary for its constraints (taking untyped keys and values). Mojo will catch up (and should surpass due to static types), but the current dict is new and mostly unoptimized. Also, this should be memory bound instead of compute bound so even in the long term, I would not expect much of a difference.

[@ekbphd3200]

Yeah, good points. Thanks.

[@androth1502]

my guess would be that the mojo implementation is a quick lazy thing just to get maps in, while python uses a C implementation.

[@ekbphd3200]

Yeah, I assume that's what's going on.

[@androth1502]

@@ekbphd3200 still not a good look for them to release something so unoptimized after boldly claiming to be thousands of times faster than python. lol.

[@svenmasche]

lmao up until minute 9 i was expecting that you were going to explain it ^^

[@ekbphd3200]

Sorry. I'm curious to see when they will be able to optimize the native Mojo dictionary. In the meantime, there's a third-party Mojo dictionary that is faster. Take a look at this video: kzbin.info/www/bejne/d6KneJ5_p6lsn9Usi=xx6_7G-srSQX3KjF

[@murithiedwin2182]

Mojo official benchmark with python performance needs a comprehensive "mojo feature to python feature" comparison benchmark... We would like then to see where the 35,000X speed up claim came from...

[@ekbphd3200]

Yeah, I think the specific task is important. As a linguist, I use strings a lot, and Python still seems to be faster than Mojo right now. I hope Mojo becomes faster than Python with strings at some point in the future. Thanks for the comment!

[@niks660097]

@@ekbphd3200 The thing is in python is a lot of string operations are handled by pure C code, for example regex is completely done by a FSM in C, that's why regexes in python are faster than java, golang you name it, if the string you are searching on is big enough, in my current company we were planning to move some code from python to golang cause of performance issues, but while profiling, python's string regexes and dict's perf. caught everyone off guard.

[@sillybuttons925]

The script does exercise item lookup, looping etc. So seems like a pretty valid comparison. Maybe try the collections.Counter if it's implemented in mojo?

[@ekbphd3200]

The hashmapdict is quick, as is the compact dict, written by a third party guy: github.com/mzaks/compact-dict kzbin.info/www/bejne/d6KneJ5_p6lsn9U

[@jinsongli3128]

my test with the List also shows mojo is slower than python, not sure if I did anything wrong.

[@ekbphd3200]

Thanks for that info! Yeah, I assume that at some point Mojo will be faster than Python with most tasks but that’s not the case yet with the linguistic tasks I do most often.

[@cmdlp4178]

Maybe in Mojo the Strings are copied and reallocated as new objects, maybe because of the different StringKey type, or maybe (I am not as familiar with Mojo) because Dict stores and owns an own instance of the string, similar to as in C++. There the string and the memory associated with the string is "owned" by e.g. the unordered_map. Maybe you should retry measuring the time, now inserting floating point numbers for examples, that might not be allocated in Mojo.

[@ekbphd3200]

Good idea! I'll give that a try soon.

[@indibarsarkar3936]

Please try splitting the data in half and assigning each halves to a dictionary. Then measure the time taken to copy or interchange elements from one dictionary to another. Maybe the problem is in the file management and not in dictionary!!

[@ekbphd3200]

Mojo's dictionary has increased in performance (when inserting items) with v24.4. I found a 4x increase in speed with a particular linguistic task. Take a watch: kzbin.info/www/bejne/kKGoi2iwgrtkjtU

[@pe6649]

Sorry, but the answer is mostly: It does simply not make sense to do benchmark comparisons with a language or tool under development. Mojo is under development. It is not at all astounding, what you found out. To me it is more astounding that you are surprised. Performance is always about details! Simple expectations like x is faster than y fail VERY often when measured. Take the various steps to make Python faster we absolved in the last decade and more: For exampe- In Python 3.11 at first JIT compiling was added. You can fasten something up, but it is not a nobrainer, and further optimizations are needed and will come. I believe Mojo will do a good job finally. But be a bit more patient. Especially Mojo will shine in optimizing for new hardware architectures. If you just want fast Python, use Numba or Nuitka..

[@earlkjarbrown3753]

Yeah, good points. I've enjoyed watching Mojo as it's being developed and assume it will be smokingly fast in comparison to Python in nearly all applications at some point in the future.

[@ekbphd3200]

Thanks!

[@talhatahir4931]

lol!!! Those mojicians claim that they are 60k times faster than python and we can't even show the truth?

[@ekbphd3200]

@@talhatahir4931 Yeah, I think it depends on the benchmark task that is used. As a linguist, I'm interested in processing strings.

[@NoX-512]

@@talhatahir4931 The 68K claim was using Mojo’s SIMD types in a Mandelbrot function.