201–210 of 239 posts
AFAIK, you can create a shared memory block between WASM JS:
https://developer.mozilla.org/en-US/docs/WebAssembly/Referen...
Then you'd only need to parse the SharedArrayBuffer at the end on the JS side
Earlier quoted context omitted.
One of the slowest, most ineficient code bases I've ever worked on was in Go. The mentality was "the language is fast, so as long as it compiles we're good"... Yeah that worked out about as well as you'd expect.
But that has nothing to do with the language.
Is this an outlier or has Rust started to be part of the establishment and being 'old' so that people want to share their "moving away from Rust" stories? I didn't mind reading articles that are not about how Rust is great in theory (and maybe practice).
This story is about moving away from WASM for an application that's unsuitable for it. It's not really about Rust.
So it's more so a story about architectural mistakes.
Why not a shared buffer? Serializing into JSON on this hot path should be entirely avoidable
I think a shared array just avoids the copy, not the serialization which is the main problem as they showed with serde-wasm-bindgen test
Earlier quoted context omitted.
My experience is the exact opposite. This was particularly true for one of the projects I've worked with in the past, where Python was chosen as the main language for a monitoring service. In short, it proved itself to be a disaster: just the Python process collecting and parsing the metrics of all programs consumed 30-40% of the processing power of the lower end boxes. In the end, the project went ahead for a while…
> but in the end it was deemed a waste of time when the whole project was terminated. The main lesson of the story. Just pick Python and move fast, kids. It doesn’t matter how fast your software is if nobody uses it.
I'd rather not use python. The ick gets me every time.
Earlier quoted context omitted.
> I'm saying that the Rust might execute in 50ms and the Python in 150ms. Okay, so the Rust code would be 3x as fast. Feels arbitrary, but sure. > You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds. I explained why your post made no sense already... > That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Pyt…
> Different languages will perform differently on IO work, IO is executed by kernel, file system or network drivers. IO performance is not dependent at all on which language makes the syscalls. > The thing we can agree with is this - no, uv would not be as fast if it were written in Python. In this thread, we are talking about the speed of uv in terms of user experience - how long a person waits for command line oper…
I think your posts on this topic can not possibly be worth responding to if you're coming to the conversation with this level of not understanding things.
Your post is a combination of not understanding computers and then hand waving about fake numbers and user expectations. IO is not magic, it is not some distinct process that you have no control over from userland, it is exactly the sort of thing that Python does very poorly at, in fact.
I'll just reference techempower again, or you can look up those system calls you referenced like how epoll works and then look into what is involved for Python to use epoll effectively.
Earlier quoted context omitted.
> I'm saying that the Rust might execute in 50ms and the Python in 150ms. Okay, so the Rust code would be 3x as fast. Feels arbitrary, but sure. > You are the one not making sense, we are talking about application performance, why are you not measuring that in milliseconds. I explained why your post made no sense already... > That is assuming Rust is 100x faster than Python btw, 49ms of I/O, 1ms of Rust, 100ms of Pyt…
> That's not how anything works. Different languages will perform differently on IO work, different runtimes will degrade under IO differently, etc. That's why even basic echo HTTP servers perform radically differently in Python vs Rust. > This isn't how computers work and it's not even how math works. What are you disagreeing with? There's some baseline amount of I/O that the kernel does for you, that's what I'm ass…
Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was. The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was…
The usual strategy is to write a script then if it's slow see how you could design a program that would
The usual strategy in the real world is to copy paste thousands of lines of C++ code until someone comes along and writes a proper direct solution to the problem.
Of course there are ideas on how to fix this, either writing your own scripting libraries (stb), packages (go/rust/ts), metaprogramming (lisp/jai). As for bugs those are a function of how you choose to write code, the standard way of writing shell it bug prone, the standard way of writing python is less so, not using overloading & going wider in c++ generally helps.
Earlier quoted context omitted.
> Just pick Python and move fast, kids. It doesn’t matter how fast your software is if nobody uses it. The reason nobody uses your software could be that it is too slow. As an example, if you write a video encoder or decoder, using pure Python might work for postage-stamp sized video because today’s hardware is insanely fast, but even, it likely will be easier to get the same speed in a language that’s better suited…
Learning that it’s too slow takes users.
Something not unlike this happened to me when moving some batch processing code from C++ to Python 1.4 (this was 1997). The batch started finishing about 10x faster. We refused to believe it at first and started looking to make sure the work was actually being done. It was. The port had been done in a weekend just to see if we could use Python in production. The C++ code had taken a few months to write. The port was…
> We soon found out that we could make algorithmic improvements so much more quickly It's true that writing code in C doesn't automatically make it faster. For example, string manipulation. 0-terminated strings (the default in C) are, frankly, an abomination. String processing code is a tangle of strlen, strcpy, strncpy, strcat, all of which require repeated passes over the string looking for the 0. (Even worse, relo…