On the other hand, in Java, with a few exceptions around Swing (native painting for GUIs) in Java, almost everything is written in pure Java, so you can debug all the way down if need be. It is a huge help for understanding the foundation library and all of its edge cases (normal for any huge library). Modern Java debuggers, like IntelliJ, are so crazy, they will decompile JARs and allow you to set debug breakpoints and step-into decompiled code. It is mind blowing when trying to debug a library that you don't own the source code (random quant lib, ancient auth lib, etc.).
A superset of python that, once finished, can run all native python code, but also adds language features to get closer to the “metal”, getting speeds of C libraries with the ability to properly debug and step through it.
If this project goes the way it’s promised (the guy has great experience with language development), this could further cement python as it would solve its biggest criticisms. Very excited for it
https://youtu.be/pdJQ8iVTwj8 https://www.modular.com/mojo https://en.m.wikipedia.org/wiki/Chris_Lattner
He has the magic touch. What you describe sounds amazing. And having LattBot behind it is even better.
I have watched one of his episodes with Lex before. He is absurdly humble about his accomplishments.
It also gives you more control over memory allocations than Java, which is nice when trying to squeeze more performance out of the code.
It also gives you more control over memory allocations than Java
I strongly doubt any production C# code is significantly faster than its JAVA counterpart.
I mean less focus on being “glue” between C code and more focus con optimizing the interpreter?
If your ML model takes hours when it can take minutes, or takes days when it can take hours, you will move away. You could move away to another language or a faster interpreter but that's a different discussion.
> more focus con optimizing the interpreter
This is good but there's an upper bound to performance of interpreted languages. Maybe the Python interpreter could be as fast as V8, but it is unlikely to be fast as JVM. People will need to drop down to C / Fortran for whatever compute intensive work they're doing.
You just install it.
> learning a little C and potentially fixing an up-to-date and beloved library
A romantic thought, but 99% of the time I'm just going to do a workaround or a local patch.
I don't use Java anymore, but I don't hate it. I think it has some verbose conventions, but I vastly prefer it to C's extremely terse conventions.
Nowadays I try to do as much in TypeScript as I can, because I find it a pleasure to use, and it has the same property where you can dive into any lib when debugging.
This is one big reason I love Pharo and other Smalltalk-language implementations. Being mostly written in themselves down to the VM. You can take a deep dive and inspect everything without being afraid of smashing your head against C bedrock underneath. And they still manage doing this while being reasonably performant and dynamic.
"Debugging a Mixed Python and C Language Stack" (2023) https://news.ycombinator.com/item?id=35710350
Aren’t most of these native libraries open source? I’m a C# dev so maybe this is a naive question based on my experience but is there not a way to bring in the source of the C library and debug into it in these “hit the wall” situations?
> This article is about optimizing a tiny bit of Python code by replacing it with its C++ counterpart.
So it's C++ rather than Python.
So, if anything, the title should say "Python, when linked with C++ code, can make (...)"
So if you’re writing python the employs this technique and you still want to keep the “OS agnostic” characteristic of python does that mean you’d have to compile multiple C++ binaries and check the OS to see which one to run?
I'm not sure why the author implemented SHA1 and a base64 digest thereof manually rather than including a small library, but perhaps that was part of the challenge.
Python can generate a whole lot more keys per second if you enable SIMD, multithreading, or even GPU support. In fact, Ryzen / 11th+ Gen Intel/ARMv8A have dedicated SHA1 instructions that should significantly boost performance here. Together with something like https://github.com/WojciechMula/base64-avx512 I bet you could increase the performance an order of magnitude if daw CPU speed were really a concern.
I suppose three million keys per second ought to be enough for any websocket server, especially for a relatively simple implementation of the code.
They replace Python code that makes 5 calls into native code by code that makes 1 call that makes those 5 calls, and get a speed up from 869k calls per second to 3.15m calls per second, so a snarky title could even be “Python-to-native calls are slow”.
They could even measure it by adding a C++ version of that
def magic_accept(key: str) -> str:
return 's3pPLMBiTxaQ9kYGzzhZRbK+xOo='
By inlining all library code you use, yes indeed, you too can also not make a single call.
Nice try!
[1] https://github.com/mayeut/pybase64
This particular one also includes b64encode_as_string, which would also reduce some work/copying.
- segfault the interpreter if you pass in something that's not a string
- read bogus memory if the length of the string is < 24