4 ms·

> So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six hefty macro-

> So it may be that your "clever" C algorithm which in your head translates into just six CPU operations, unfortunately on a real modern CPU is six hefty macro-ops that will take dozens of cycles to execute and repeatedly go to sleep waiting for main memory, whereas the algorithm in a modern language that looked ludicrous to your C programmer eyes compiles to sixteen tiny ops the CPU can consume two at a time with no waits and it's done in eight cycles while the C code was still waiting for a main memory read. Can you give an example of that?

tialaramex 4y ago
I can give you a smaller example if that helps. Rust's u8::is_ascii_hexdigit is a predicate which decides whether the 8-bit unsigned integer is the ASCII code for a hexadecimal digit, that is 0 through 9, A through F or a through f. Inside the implementation is exactly what a modern programmer would expect, a pattern match, it'll do a whole bunch of arithmetic operations on the 8-bit unsigned integer and get a true or false result. Your modern CPU can do that real fast, because it's all just arithmetic on registers. If you go look at a C library isxdigit() function, sometimes (not so often these days) you will find it has a mask and a LUT, it's assuming that "just" looking up the answer in memory will be faster. Your modern CPU can't do that quickly. It must calculate the index into the LUT, and then read the appropriate memory, hopefully that's in L1 cache or something, if it needs to go to main memory that takes an eternity, and either way it means something else can't be in the cache because this LUT is taking up space.
- Gordonjcp 4y ago
  I can't say I've ever seen a lookup table method for that, going right back to implementing that kind of function on 8-bit CPUs. Are you sure you're not just used to shitty code?
  - tialaramex 4y ago
    GNU libc is an example of a relatively well known isxdigit() which uses a LUT even today. Its excuse is that this simplifies locale handling, you know for if your locale has hexadecimal digits in a different place from everybody else, presumably because you're from some alternate universe where Z is a hex digit.
    - litoE 4y ago
      But isn't that just a bad implementation in libc, rather than a problem with C itself? It should be trivial to rewrite isxdigit() copying rust's algorithm in C.
      - Gordonjcp 4y ago
        Or, you know, MIKBUG's implementation.
    - torstenvl 4y ago
      This is a problem with glibc (it's also a violation of the C standard, since isxdigit is explicitly not affected by the current locale). Other C libraries don't have this problem. http://git.musl-libc.org/cgit/musl/plain/src/ctype/isxdigit.c?id=6582baa752a8facb2c8a7b5b3dcf67331429cdc1 http://git.musl-libc.org/cgit/musl/plain/src/ctype/isxdigit....
    - deleted 4y ago
      [deleted]

tialaramex 4y ago

I can give you a smaller example if that helps. Rust's u8::is_ascii_hexdigit is a predicate which decides whether the 8-bit unsigned integer is the ASCII code for a hexadecimal digit, that is 0 through 9, A through F or a through f. Inside the implementation is exactly what a modern programmer would expect, a pattern match, it'll do a whole bunch of arithmetic operations on the 8-bit unsigned integer and get a true or false result. Your modern CPU can do that real fast, because it's all just arithmetic on registers. If you go look at a C library isxdigit() function, sometimes (not so often these days) you will find it has a mask and a LUT, it's assuming that "just" looking up the answer in memory will be faster. Your modern CPU can't do that quickly. It must calculate the index into the LUT, and then read the appropriate memory, hopefully that's in L1 cache or something, if it needs to go to main memory that takes an eternity, and either way it means something else can't be in the cache because this LUT is taking up space.

Gordonjcp 4y ago
I can't say I've ever seen a lookup table method for that, going right back to implementing that kind of function on 8-bit CPUs. Are you sure you're not just used to shitty code?
- tialaramex 4y ago
  GNU libc is an example of a relatively well known isxdigit() which uses a LUT even today. Its excuse is that this simplifies locale handling, you know for if your locale has hexadecimal digits in a different place from everybody else, presumably because you're from some alternate universe where Z is a hex digit.
  - litoE 4y ago
    But isn't that just a bad implementation in libc, rather than a problem with C itself? It should be trivial to rewrite isxdigit() copying rust's algorithm in C.
    - Gordonjcp 4y ago
      Or, you know, MIKBUG's implementation.
  - torstenvl 4y ago
    This is a problem with glibc (it's also a violation of the C standard, since isxdigit is explicitly not affected by the current locale). Other C libraries don't have this problem. http://git.musl-libc.org/cgit/musl/plain/src/ctype/isxdigit.c?id=6582baa752a8facb2c8a7b5b3dcf67331429cdc1 http://git.musl-libc.org/cgit/musl/plain/src/ctype/isxdigit....
  - deleted 4y ago
    [deleted]