6 ms·

How current is this impression? There continue to be first-rate Fortran compilers that probably win on numerics for exactly the reasons you state, but I would b

How current is this impression? There continue to be first-rate Fortran compilers that probably win on numerics for exactly the reasons you state, but I would be surprised that PL/I has a toolchain that's kept up with modern architecture. String handling, on most modern toolchains, mostly goes to inline functions or builtins that the compiler has been (rather pragmatically, if a big disgustingly) made aware of. It's very unlikely that strcpy or memmem is going through external linkage.

graycat 7y ago
My experience is old, but my summary point remains: Language defined and compiler supported functionality usually is faster than libraries of external functions. The relevance here: C isn't the fastest thing around and can be beaten. Maybe similarly for Rust. For PL/I and strings, for the IBM versions on S/360 and S/370, the compiler might have used some of the hardware instructions for string handling. I'd be surprised if in C strcpy, etc., were not still external: They USED to be, and then someone might have written their own version, e.g., for their own versions of strings, and linked to it; for compatibility, strcpy would about have to be an external function call still.
- monocasa 7y ago
  The compiler (off the top of my head this applies to GCC, clang, and MSVC, dont know about ICC) generally understands the C string functions at a fundamental level and will emit optimized code instead of a function call that will use hardware instructions and might know the size of the buffer at compile time. For instance on GCC you have to specify -fno-builtin to say "you don't know what you think you know about c library, actually emit those function calls instead of trying to optimize the idea of those calls."
  - graycat 7y ago
    Soooo, those C compilers cheat on the language as defined in K&R etc.!!! WOW!! With that cheating, C gets to catch up with, say, what PL/I was doing with string manipulations in, say, 1969!!! So, this is the 50th anniversary!! C string handling is right up to date as of 50 years ago!!! There is still the issue of a C programmer having to calculate array indices that Fortran and PL/I can do back, way back there, 50+ years ago!!!! What was it, Fortran 66 or some such???
    - monocasa 7y ago
      It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. And GCC at least (don't know about the others, not that this isn't true for them) has done this for decades at this point as well. Edit: Before that point, the targets that C tended focus on preferred these operations being in functions anyway.
      - graycat 7y ago
        > It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. As I read K&R, strcpy, etc., where there, in a library of external functions, as a convenience and optional for the user, and NOT part of the definition of the C language. Your YMMV. The situation definitely is "cheating": In K&R, strcpy is clearly, syntax, semantics, original implementation, an external library function. K&R has the definition of the language. One of the most important parts of C is that it doesn't change. It was clear in K&R that strcpy could be implemented by any user in their own external code. So, a compiler that implements strcpy with its own in-line, not with external names, code is cheating on the language definition. C as in K&R was designed to run in a DEC computer with 8 KB of main memory. So, the K&R definition of C was primitive. Since strings in C as in K&R are so primitive, really a disaster, a situation well understood when K&R was written, some programmers might have done a much better string implementation via external function calls. So, given some old C code, they could have linked in their own external calls not mentioned in K&R and for parts of the old code that called strcpy linked in their own version of that function that worked with the new string functionality. All to have been expected. So, some compiler writers have gotten more performance from C by cheating some on the language and put in compiler options to justify the cheating. With this cheating, the compiler writers are making my main point: Functionality defined in the language and implemented in the compiler via in-line code can be faster than functionality implemented in external function calls. That is, the more recent C compiler writers so strongly agreed with this point that they cheated on the language definition to get the gains. This point was made very clearly by IBM as they pointed out that the string functionality in the PL/I language and the IBM compilers was faster than the many Fortran string packages implemented by external functions. Being faster than K&R style C is easy. So, here I was struck by the point that Rust is not always a LOT faster than C, that is, K&R C. But, maybe Rust IS a lot faster than C with a compiler that does no cheating!
  - graycat 7y ago
    I get it now: My view of HN just went down to the sewer: We're into the old, bitter, go out back and fight it out, religious computer language wars. And there C is one of the grand sacred subjects: C is the greatest. The greatest, best ever. The greatest, fastest of all time, never to be improved on. Pure genius. Pure gold. And C programmers are like people who climb Mount Everest barefoot with no tools and the only REAL programmers. Yup, C religion. My view, bluntly: C was a toy language for an 8 KB DEC computer, well known to be a toy at the time. It's still a toy language and so primitive that it is a huge waste of effort in computing. There's no excuse for it and hasn't been even from the first day it was written, even for operating system code, since even at the time Multics was written in PL/I. And C is so primitive, in its K&R definition, that for string and array functionality, it is SLOW. Besides, the idea that we are stuck-o with strcpy, etc. as in the original K&R external library means that we can't implement array bounds checking, reports on memory usage, etc. with an upgraded library of external functions. My points here are rock solid: Functionality defined in the language and implemented in the compiler can be a lot faster than implementations with libraries of external functions. On strings, C and Fortran are examples. On arrays, C is an example. If Rust is not a lot faster than K&R C, then I'm surprised at Rust. All those hero barefoot Mount Everest climbers might notice that they are really tired, their feet hurt, and they very much need some better equipment! Ah, programming language religious wars!!!!! Grow up HN; set aside the toys of childhood. Be rational and set aside religious wars.
    - glangdale 7y ago
      You appear to be making your points in a way in which no developments from the part 10-20 or so years are intruding. Can you point to a extant PL/I compiler that produces good code on modern architectures? How sure are you that the issues that separated C, Fortran and PL/I historically are even remotely relevant now? I would imagine inlined functions (and for the brave, interprocedural analysis) renders many of your points moot. Fortran still has an edge on numerics as I understand it, but I don't think it's all that decisive. The other reason that baking functionality into the language is problematic is that you wind up having a few things that go fast, while you neglect to build facilities that optimize other people's data structures. So you get the world's fastest dense array (say) but your sparse array is resolutely mediocre. Instead of a language packed with special-cases, I would much rather a minimal language with good analyses (many of which can be supported by language design; I think Rust has a good future here to support good analyses by how carefully it tracks lifetimes and how it doesn't fling aliases around with the abandon of C).
- jcranmer 7y ago
  C/C++ compilers will happily optimize standard library functions. A call to printf that doesn't use any % formatting will usually get converted into a call to puts, for example. And strlen of a string literal is of course replaced with a constant integer, and strcpy will be converted to memcpy if the length is known. And memcpys of known length are of course emitted with appropriate move sequences.

graycat 7y ago

My experience is old, but my summary point remains: Language defined and compiler supported functionality usually is faster than libraries of external functions. The relevance here: C isn't the fastest thing around and can be beaten. Maybe similarly for Rust. For PL/I and strings, for the IBM versions on S/360 and S/370, the compiler might have used some of the hardware instructions for string handling. I'd be surprised if in C strcpy, etc., were not still external: They USED to be, and then someone might have written their own version, e.g., for their own versions of strings, and linked to it; for compatibility, strcpy would about have to be an external function call still.

monocasa 7y ago
The compiler (off the top of my head this applies to GCC, clang, and MSVC, dont know about ICC) generally understands the C string functions at a fundamental level and will emit optimized code instead of a function call that will use hardware instructions and might know the size of the buffer at compile time. For instance on GCC you have to specify -fno-builtin to say "you don't know what you think you know about c library, actually emit those function calls instead of trying to optimize the idea of those calls."
- graycat 7y ago
  Soooo, those C compilers cheat on the language as defined in K&R etc.!!! WOW!! With that cheating, C gets to catch up with, say, what PL/I was doing with string manipulations in, say, 1969!!! So, this is the 50th anniversary!! C string handling is right up to date as of 50 years ago!!! There is still the issue of a C programmer having to calculate array indices that Fortran and PL/I can do back, way back there, 50+ years ago!!!! What was it, Fortran 66 or some such???
  - monocasa 7y ago
    It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. And GCC at least (don't know about the others, not that this isn't true for them) has done this for decades at this point as well. Edit: Before that point, the targets that C tended focus on preferred these operations being in functions anyway.
    - graycat 7y ago
      > It doesn't "cheat"; the semantics of the C standard library are just as much a part of the language as the rest. As I read K&R, strcpy, etc., where there, in a library of external functions, as a convenience and optional for the user, and NOT part of the definition of the C language. Your YMMV. The situation definitely is "cheating": In K&R, strcpy is clearly, syntax, semantics, original implementation, an external library function. K&R has the definition of the language. One of the most important parts of C is that it doesn't change. It was clear in K&R that strcpy could be implemented by any user in their own external code. So, a compiler that implements strcpy with its own in-line, not with external names, code is cheating on the language definition. C as in K&R was designed to run in a DEC computer with 8 KB of main memory. So, the K&R definition of C was primitive. Since strings in C as in K&R are so primitive, really a disaster, a situation well understood when K&R was written, some programmers might have done a much better string implementation via external function calls. So, given some old C code, they could have linked in their own external calls not mentioned in K&R and for parts of the old code that called strcpy linked in their own version of that function that worked with the new string functionality. All to have been expected. So, some compiler writers have gotten more performance from C by cheating some on the language and put in compiler options to justify the cheating. With this cheating, the compiler writers are making my main point: Functionality defined in the language and implemented in the compiler via in-line code can be faster than functionality implemented in external function calls. That is, the more recent C compiler writers so strongly agreed with this point that they cheated on the language definition to get the gains. This point was made very clearly by IBM as they pointed out that the string functionality in the PL/I language and the IBM compilers was faster than the many Fortran string packages implemented by external functions. Being faster than K&R style C is easy. So, here I was struck by the point that Rust is not always a LOT faster than C, that is, K&R C. But, maybe Rust IS a lot faster than C with a compiler that does no cheating!
- graycat 7y ago
  I get it now: My view of HN just went down to the sewer: We're into the old, bitter, go out back and fight it out, religious computer language wars. And there C is one of the grand sacred subjects: C is the greatest. The greatest, best ever. The greatest, fastest of all time, never to be improved on. Pure genius. Pure gold. And C programmers are like people who climb Mount Everest barefoot with no tools and the only REAL programmers. Yup, C religion. My view, bluntly: C was a toy language for an 8 KB DEC computer, well known to be a toy at the time. It's still a toy language and so primitive that it is a huge waste of effort in computing. There's no excuse for it and hasn't been even from the first day it was written, even for operating system code, since even at the time Multics was written in PL/I. And C is so primitive, in its K&R definition, that for string and array functionality, it is SLOW. Besides, the idea that we are stuck-o with strcpy, etc. as in the original K&R external library means that we can't implement array bounds checking, reports on memory usage, etc. with an upgraded library of external functions. My points here are rock solid: Functionality defined in the language and implemented in the compiler can be a lot faster than implementations with libraries of external functions. On strings, C and Fortran are examples. On arrays, C is an example. If Rust is not a lot faster than K&R C, then I'm surprised at Rust. All those hero barefoot Mount Everest climbers might notice that they are really tired, their feet hurt, and they very much need some better equipment! Ah, programming language religious wars!!!!! Grow up HN; set aside the toys of childhood. Be rational and set aside religious wars.
  - glangdale 7y ago
    You appear to be making your points in a way in which no developments from the part 10-20 or so years are intruding. Can you point to a extant PL/I compiler that produces good code on modern architectures? How sure are you that the issues that separated C, Fortran and PL/I historically are even remotely relevant now? I would imagine inlined functions (and for the brave, interprocedural analysis) renders many of your points moot. Fortran still has an edge on numerics as I understand it, but I don't think it's all that decisive. The other reason that baking functionality into the language is problematic is that you wind up having a few things that go fast, while you neglect to build facilities that optimize other people's data structures. So you get the world's fastest dense array (say) but your sparse array is resolutely mediocre. Instead of a language packed with special-cases, I would much rather a minimal language with good analyses (many of which can be supported by language design; I think Rust has a good future here to support good analyses by how carefully it tracks lifetimes and how it doesn't fling aliases around with the abandon of C).
jcranmer 7y ago
C/C++ compilers will happily optimize standard library functions. A call to printf that doesn't use any % formatting will usually get converted into a call to puts, for example. And strlen of a string literal is of course replaced with a constant integer, and strcpy will be converted to memcpy if the length is known. And memcpys of known length are of course emitted with appropriate move sequences.