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.
/s
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
You can quickly create record structs or value tuples (that auto-implement Equals(obj) & GetHashCode()) and pass them around by reference instead of copying.
record struct RGBA(byte R, byte G, byte B, byte A);
// allocate a small collection on the stack
Span<RGBA> colors = stackalloc RGBA[3]
{
new RGBA(255, 0, 0, 255),
new RGBA(0, 255, 0, 255),
new RGBA(0, 0, 255, 255)
};
// get value by reference
ref var c = ref colors[2];
c = new RGBA(127, 127, 127, 255);
// prints: RGBA { R = 127, G = 127, B = 127, A = 255 }
Console.WriteLine(colors[2]);
// value tuple
(byte R, byte G, byte B, byte A) white = (255,255,255,255);
Ref struct is a type of struct that is always stack allocated and cannot be promoted to the managed heap or boxed. `Span<T>` is ref struct.
Spans allow you to create views over contiguous regions of memory that is located on the stack or on the heap or over native memory. You can pass spans to methods that then read/modify the data in the view.
And many other features that help you manage memory or avoid allocations.
For example. When working with interfaces you can avoid boxing allocation of value types by using a generic type constrained to the interface instead of the interface.
uber-sophisticated IDE
How much of this is done in Python, vs constructing instructions in Python to run on a GPU at uber speed?
I haven't seen many people doing ML in Python without one of these libraries, so I'd say it is mostly constructing instructions in Python and offloading the actual intensive work to these libraries (which may or may not run on GPU depending on your hardware).
JSon serialization: 20+% faster: https://www.techempower.com/benchmarks/#section=data-r21&tes...
Single query: 20+% faster: https://www.techempower.com/benchmarks/#section=data-r21&tes...
Multiple query: 20+% faster: https://www.techempower.com/benchmarks/#section=data-r21&tes...
Data update: 15% faster: https://www.techempower.com/benchmarks/#section=data-r21&tes...
First link: How is it possible that Java can achieve same perf as C??? I write a lot of Java, and none of my stuff is close to C. I guess about 50% the speed -- which fine for my needs.
One reason (totally unscientific, of course) I think Java is faster: The virtual machine has been open source for longer. So more academics have looked at, run experiments, written papers... that are then read by the core Java team and sometimes implemented. C# is a bit behind, but should catch-up one day.
Always was, always will be.
Python’s optimal use case does not relate to speed.
Related: When I search for help on a Python foundation library or built-in funciton, my Google search results are overwhelmed by "learn-to-program"-type of websites. I guess it makes sense: During the gold rush, don't dig for gold, rather sell shovels!
On the other hand, no one is doing the same for Bash.
You are using Bash because you know how to program something else and need to schedule it / wrap it in a shell script / etc. The fact that someone even knows Bash exists is a filter. Having an idea of where you might need to use it, a second filter. And having successfully done so, a third filter.
That's what it is indeed, more R&D went into Java
C# will catch up eventually, specially now that they invest massively on PGO/AOT and ways to minimize heap allocations (stackallock and struct reference for example)
A framework is not representative of a language performance, it is representative of the framework's performance, they might not use newest language features, they might use outdated dependencies, developer might have wrote poor code, they might have bugs
I guess people don't like getting fact checked
Developers nowadays seem stuck in a box for some reason
you swap that part for something faster