4 ms·

> Even *printf can be much, much faster. If the format specifier is static, first run just generates code just for that specifier. There's no reason you can't

by nly 12y ago

> Even *printf can be much, much faster. If the format specifier is static, first run just generates code just for that specifier. There's no reason you can't do what you want today AOT in stronger languages. Adding a JIT, or special AOT treatment of any given set of functions, to workaround weaknesses in C and its poor standard library, is just sad. Another problem is that stock libc printf has to be able to deal with localisation, and locales can be changed arbitrarily at runtime (although it's not thread-safe to do so) One way to get all the performance out of modern hardware would be to stop using languages and libraries that haven't seen major improvement since the 90s, and still can't deliver optimal execution of functions, like printf, designed in the 60s.

vardump 12y ago
Cough existing codebase cough. We can significantly boost performance for some aspects of C/C++ in the meanwhile by JITting. "sprintf" is just slow. (side note: Also C++ "<<" stream implementations I've seen are unbelievably slow (about 3x slower than *printf) and tend to have a lot of side effects, such as a barrage of system calls if unbuffered -- the 99% case. Although I'm sure this is fixable with a better stream implementation and maybe some compiler assistance. Just try to benchmark stringstream...) Otherwise I agree with you of course. Time is up for C/C++. Although I think they'll stay around. They're just not a good fit for modern CPUs anymore. There just isn't a good replacement yet. Maybe Rust will be that one day?
- nly 12y ago
  The problem with C isn't that it's old, unsafe, conservative, or that it lacks GC. The problem is that people have religious wars about strncat vs strlcat, which are both terrible and both equally broken, rather than looking at the big picture. The big picture is that there are hardly any functions in the standard library that aren't terrible. If you wanted a safe, fast printf function in C for example, one way to do it would be to provide a function that took a format string and returned a reusable handle, much like you use regular expressions in a library like PCRE. This would give you instant benefits when it came to print and scan loops (no re-parsing of the format string), while still giving the compiler ample opportunity to do type checking without too much work. It even opens the door to a JIT and/or AOT backend, all without major changes to the actual compiler. void (*hello)(char const*, int); if (!printf_jit ("Hello %s, you have %d points\n", &hello)) { /* jit failed */ } hello ("Steve", 80); printf_free (hello); I don't lump C++ in the same boat. The above code can be written semantically in C++ today, without any external libraries, with full type-checking.
  - vardump 12y ago
    Nice idea how to get type checking. I was thinking more of a macro that initializes a function pointer with a code generator and subsequently overwrites it once JIT has been completed. Sadly in both cases, no chance to inline or avoid unneeded stack use. Sadly the parameter string ("Steve") needs to be scanned for zero terminator -- this is slow. Zero terminated strings are an evil invention.

by nly 12y ago

vardump 12y ago

Cough existing codebase cough. We can significantly boost performance for some aspects of C/C++ in the meanwhile by JITting. "sprintf" is just slow. (side note: Also C++ "<<" stream implementations I've seen are unbelievably slow (about 3x slower than *printf) and tend to have a lot of side effects, such as a barrage of system calls if unbuffered -- the 99% case. Although I'm sure this is fixable with a better stream implementation and maybe some compiler assistance. Just try to benchmark stringstream...) Otherwise I agree with you of course. Time is up for C/C++. Although I think they'll stay around. They're just not a good fit for modern CPUs anymore. There just isn't a good replacement yet. Maybe Rust will be that one day?

nly 12y ago
The problem with C isn't that it's old, unsafe, conservative, or that it lacks GC. The problem is that people have religious wars about strncat vs strlcat, which are both terrible and both equally broken, rather than looking at the big picture. The big picture is that there are hardly any functions in the standard library that aren't terrible. If you wanted a safe, fast printf function in C for example, one way to do it would be to provide a function that took a format string and returned a reusable handle, much like you use regular expressions in a library like PCRE. This would give you instant benefits when it came to print and scan loops (no re-parsing of the format string), while still giving the compiler ample opportunity to do type checking without too much work. It even opens the door to a JIT and/or AOT backend, all without major changes to the actual compiler. void (*hello)(char const*, int); if (!printf_jit ("Hello %s, you have %d points\n", &hello)) { /* jit failed */ } hello ("Steve", 80); printf_free (hello); I don't lump C++ in the same boat. The above code can be written semantically in C++ today, without any external libraries, with full type-checking.
- vardump 12y ago
  Nice idea how to get type checking. I was thinking more of a macro that initializes a function pointer with a code generator and subsequently overwrites it once JIT has been completed. Sadly in both cases, no chance to inline or avoid unneeded stack use. Sadly the parameter string ("Steve") needs to be scanned for zero terminator -- this is slow. Zero terminated strings are an evil invention.