/*
Recursively removes doublets from input. A doublet is a pair of adjacent chars,
identical or differing only in capitalization (eg. "aa" or "aA"). The result is
written to output, which must be at least input_length bytes long.
Returns the number of bytes in the result.
*/
size_t remove_doublets(char * output, const char * input, size_t input_length);
Really, no matter what the language is, people need to actually put some thought into what they're doing.
Most JS VMs have several different string types internally. Looking at V8's source code (https://github.com/v8/v8/blob/master/src/builtins/builtins-s...), it looks like there's a very happy ASCII fast path that makes toLowerCase really fast on ASCII. Actually, it even looks as if it's processing the characters 8 bytes at a time (https://github.com/v8/v8/blob/master/src/strings/string-case...).
The whole "I wrote it in JS and then ported it" introduction meant I was expecting exactly that kind of problem.
This is inaccurate. Vec<char> will store chars on the heap. & the concept of primitive values exists in Java, whereas in Rust any struct you declare can exist on the stack (or in CPU registers if the optimizer decides to)
But yes, char is a 32 bit integer as opposed to String being a Vec<u8> under the wraps, & Vec<char> is preferable to Vec<Vec<u8>>
If the author had provided the input data, I would optimize the JavaScript further so that Rust and JS would be more even.
Or make a struct with {char, boolean}.
Yes Rust, C, C++ can be fast. Really fast. Impossible-to-beat fast - if you know what you're doing. If you don't, it's going to be worse than any trivial python, lua or js that does the same thing.
The interesting question is whether the code produced by the average programmer of that language is fast or not. And there language choice matters quite a bit, both because of language design (i.e. how easy is it to generate good machine code for that language) and because of the culture associated with that language (e.g. you can write extremely efficient Java, but typical Java programs chase a lot of pointers and generate a lot of garbage).
Not just this, but the ceiling of performance improvements matter a lot too.
Rust allows you to write high-level code, where you can "easily" jump into Rust coming from JavaScript. You performance might be on par in your initial versions while you are getting into the language.
It starts to matter a lot when you now have a working application, and you start using it. With JavaScript you will quickly reach a point where your idiomatic JavaScript is about as fast as it'll go.
With Rust, there usually keeps being tricks you can pull to squeeze more performance out of it, and you can do it just for the hot-paths of your code instead of rewriting the entire thing in a new language because you reached your limit.
A good example of this limit is something like the TypeScript compiler. It has huge performance issues with larger codebases, but unfortunately there's not much that can be done without rewriting the entire damn thing in e.g. Rust, because you've reached the limits of JavaScript.
But the floor can matter too. For someone trained to write high-performance JavaScript, JavaScript's performance floor is higher than Rust's, and they can write more JavaScript faster.
> A good example of this limit is something like the TypeScript compiler. It has huge performance issues with larger codebases, but unfortunately there's not much that can be done without rewriting the entire damn thing in e.g. Rust, because you've reached the limits of JavaScript.
Actually, you can fix it by rewriting it as a single-pass compiler to improve the algorithms.
I'm not sure what you mean by the floor here? Experience? The author of the article was experienced in JavaScript and was new to Rust for example.
>Actually, you can fix it by rewriting it as a single-pass compiler to improve the algorithms.
I'd say that's on the same scale of work as rewriting it in a new language.
And even then, this is most likely not a realistic solution, I can almost guarantee you there will be stuff they are currently doing that they cannot do in such an architecture.
The first problem with the words "single-pass" and "Javascript" that come to mind are the out-of-order variable declarations, i.e. var, which bubbles up.
There are a ton of other issues as well.
1. by how fast it runs when written by a very experienced developer, or
2. by how fast programs run that are written by the "average" programmer, or
3. by how fast it runs when written by a bad or inexprienced programmer?
For each of these I can think of (at least) one language that would beat the performance of any other. There are languages that are "very difficult to use wrong", and there are languages that are difficult to use right. For the latter, C++ is a great example. You will copy and leak yourself out of memory before you terminate, if you dont know what you're doing.
Maybe we should stop comparing random languages from different domains by how fast they run.
Rust makes it surprisingly easy to write code that absolutely thrashes the memory allocator - using String/Box/Vec and adding .clone() everywhere makes a lot of tricky borrowing problems go away. Is that the kind of code I expect to be writing? Or running? And if so, we shouldn’t expect that kind of code to perform much better in most cases than javascript.
* Is language X that we all know suitable?" * Is there a language Y that we could all learn in an acceptable time optimal? * What does the tooling look like? * How would we bring in new people?
CPU runtime is just one aspect to consider
The biggest reason, I think, is that C encourages you to be memory efficient. Allocating memory is not trivial and you have to keep track of all your pointers. On the other hand, it makes it easy to modify things in place, where other languages favor immutability. But if you do a lot of allocations, create a makeshift garbage collector, and memcpy a lot, then your C code will be really slow, because you are basically doing what makes other languages slower, but worse because other languages are heavily optimized for that use cases and your code most likely isn't.
https://github.com/cesarvr/AOCRust/blob/590270ed268dcd4ff01b...
Rarely see this kind of obscenity outside of beginner's university C++ classes.
int hasz[200];
memset(hasz, 0, 200);
or the first 100 integers https://gcc.gnu.org/wiki/avr-gcc
Memory allocation is expensive. C++ pmr allocators provide powerful tools to manage memory.
1. faster when written and optimized by an expert, who writes the best blog on how to optimize X
2. faster when written and optimized by a competent-but-not-necessarily-expert programmer, who reads the best blog on how to optimize X
3. faster when written without speed in mind
It seems like C, C++, and Rust are all more or less tied at the head of the pack for #1 and #2. There's obviously a lot of room for debate here, but it seems like many other languages (Go? JavaScript running on V8?) can get pretty close for #1 but struggle for #2.
For #3, it seems like C is the king, because of the very low-level style that it forces on the programmer. Below that things get murky. I'm inclined to believe Rust does well here, because it doesn't usually allocate without being asked to, but I assume the same logic applies to other languages I'm less familiar with (D, Zig). How well C++ does probably depends on how you interpret the question. (Like does the programmer make even the slightest effort to avoid implicitly copying big data structures, to take things by reference, etc?)
No, that is not what this is. Rust IS faster than most languages on earth.
This is FACT.
Some tools ARE better than others. You only heard the "opposite" when a outlier happened or a user misunderstood how use the tool.
Also this apply to interpreted languages too!:
http://lambda-the-ultimate.org/node/5075
IF you hit their sweet spots.
PD: Just check the Rust reddit. Tons of case of naive newcomers with massive improvements on speed/performance just porting to Rust.
---
This kind of history is similar to "A virus happened on OS X/Linux!" Then say "No OS is more secure than others!" is a massive flaw. Some are more secure. Only this time is news precisely because is RARE!
It adds a runtime sanitizer to detect some (but not all) UB.
The author has a follow up article[1] on their blog about it. They rewrite the rust code to eliminate the extra allocations they identified at the end of this post. It then performs 8 times faster than the javascript version.
However, I think they could have simply iterated on the code from the first post:
There are a lot of allocations because two strings are created every time they are pushed to the queue (.to_string()):
This is unnecessary, because candidate and token are both a single character.Rust has a char type that is useful to store single characters. Especially, unlike String which is heap-allocated, char is a primitive value that resides on the stack and CPU registers. Since we are comparing single characters, it's much better to use char.
So if the queue is defined as a Vec<char> instead of a Vec<String>, and the comparison function took as argument char rather than &String, it will spare a lot of allocations and this will speed up the final application.
This has also the advantage of removing the references, making the code cleaner. Using Vec::with_capacity(n) instead of Vec::new() will also help lowering the allocation load by preemptively allocating a large enough memory slice. With Vec::new(), the vector will reallocate a few times.[1] https://cesarvr.io/post/rust-vs-javascript/