Re:Performance Showdown: Rust vs Javascript (2020)
by edflsafoiewq on Friday February 12, 2021 @07:40AM
(#26113001)
An illustration: the C++ solution takes a std::string by value, incurring an unintentional copy of the buffer. C++ makes it easy to make this mistake. C does not. But for the same reason C++ also makes it easy to use complicated objects and allocations when you need them for performance.
https://github.com/cesarvr/AOCRust/blob/590270ed268dcd4ff01b...
Re:Performance Showdown: Rust vs Javascript (2020)
by lionkor on Friday February 12, 2021 @07:57AM
(#26113130)
Wow, that's some horrible code. No std::vector::reserve, string by value, memset, "using namespace std", missing includes, c-header includes in c style, ...
Rarely see this kind of obscenity outside of beginner's university C++ classes.
Re:Performance Showdown: Rust vs Javascript (2020)
by nyanpasu64 on Friday February 12, 2021 @10:00AM
(#26114313)
int hasz[200];
memset(hasz, 0, 200);
Re:Performance Showdown: Rust vs Javascript (2020)
by felixr on Friday February 12, 2021 @10:57AM
(#26115016)
> only the first 50 integers
or the first 100 integers https://gcc.gnu.org/wiki/avr-gcc
Re:Performance Showdown: Rust vs Javascript (2020)
by MertsA on Sunday February 14, 2021 @05:15AM
(#26131044)
For anyone who isn't well versed in C, int is most of the time 32 bits but it's architecture dependent with some machines being e.g. 16 bit. If you need the size to be exactly 32 bits then you can just use int32_t or similar and let the compiler make that happen regardless of the architecture it's compiling to. The original code should have specified 200 * sizeof(int) or better yet since it's a local variable just ditch the memset and change it to int hasz[200] = {}; which will do the same.
Re:Performance Showdown: Rust vs Javascript (2020)
by BenFrantzDale on Friday February 12, 2021 @07:50PM
(#26120428)
People keep saying C is fast. It’s not. You can’t write a reusable fast sort in C. C++’s std::sort will trounce qsort any day of the week because qsort uses function pointers that can’t be inlined. Without inlined generic algorithms, how can people claim C is performant?
Memory allocation is expensive. C++ pmr allocators provide powerful tools to manage memory.
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.