I really wasn't interested in the role of time. I was just struck that Rust was not a lot faster than C. Even with strcpy, malloc, free, etc. all compiled, C should still be slow due to essentially no support for arrays with more than one subscript. Thus I would expect that a modern language with good array support would beat C and am surprised that Rust does not.
Array support is now very old stuff; gee, now we'd like balanced binary tree support, maybe AVL trees, maybe like the C++ collection classes, but compiled and not just classes with its too much indirection. And we'd like good multi-threading support. Some of that is in the .NET languages; then they have a shot at beating C. I would expect that any language taken seriously today would beat C, the K&R version, the ANSI version, some recent version, etc.
And I'd like a lot more, e.g., some good semantic guarantees from static code analysis.
BTW in my remark above, have to swap "syntax" and "semantics" -- we have good progress on syntax but less good on the more difficult semantics.
A practical challenge is given some code, say, 100 KLOC, maybe 1 MLOC, have some static analysis that reports some useful information. Then have some transformations that have some useful guaranteed properties. If current languages do not admit such, then try to come up with a new language that does and still is easy enough to use and fast enough.
Gee, I assumed that after all these years we'd get some progress -- that Rust doesn't run circles around C is disappointing.
> I really wasn't interested in the role of time. I was just struck that Rust was not a lot faster than C. Even with strcpy, malloc, free, etc. all compiled, C should still be slow due to essentially no support for arrays with more than one subscript. Thus I would expect that a modern language with good array support would beat C and am surprised that Rust does not.
What do you think "array support" means to the compiler? Fortran has historically been faster just because of the the aliasing rules, but C has the restrict keyword now that brings it up to snuff there. The standard library inlining is more a hack around the fact that the c stdlib is dynamically linked, and that doesn't always make sense for heavily used functions.
I'm not really sure where you got this idea that C is a low bar. For instance here's C meeting or beating Fortran on every benchmark except one (where statistically they're probably tied). https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
Array support is now very old stuff; gee, now we'd like balanced binary tree support, maybe AVL trees, maybe like the C++ collection classes, but compiled and not just classes with its too much indirection. And we'd like good multi-threading support. Some of that is in the .NET languages; then they have a shot at beating C. I would expect that any language taken seriously today would beat C, the K&R version, the ANSI version, some recent version, etc.
And I'd like a lot more, e.g., some good semantic guarantees from static code analysis.
BTW in my remark above, have to swap "syntax" and "semantics" -- we have good progress on syntax but less good on the more difficult semantics.
A practical challenge is given some code, say, 100 KLOC, maybe 1 MLOC, have some static analysis that reports some useful information. Then have some transformations that have some useful guaranteed properties. If current languages do not admit such, then try to come up with a new language that does and still is easy enough to use and fast enough.
Gee, I assumed that after all these years we'd get some progress -- that Rust doesn't run circles around C is disappointing.