3 ms·

> But that just brings you back to the original problem when some day someone builds a machine that has hardware support for popcount on multiple words. Is tha

> But that just brings you back to the original problem when some day someone builds a machine that has hardware support for popcount on multiple words. Is that really a problem? We've already seen that compilers are clever enough to recognize these patterns. Meanwhile any loop using __builtin_popcount will look more or less like this: for (int i = X; i < Y; i++) { total += __builtin_popcount(a[i]); } ... which is a substantially easier pattern to recognize than the one that clang is already using to recognize popcount.

lisper 10y ago
> Is that really a problem? I think it is if you consider wasted effort a problem. But apparently not everyone does. > compilers are clever enough Yes, but only because someone did a lot of work to make them clever. And they only had to do that work because someone else did a lot of work to write a clever algorithm. If we as an industry had just done the Right Thing to begin with both of those people could have used that time to do something more productive.
- coldtea 10y ago
  >I think it is if you consider wasted effort a problem. But apparently not everyone doe You haven't considered 2 things: marginal returns and opportunity cost. Your solution to this "wasted effort" is to build a better C (or a better language). But this overlooks the millions of hours spent in C systems, C code, C compilers, learning, and all that would have to be done once again... If the better language already existed, and was a drop in replacement (meaning everything just works) then your argument would indeed mean an end to wasted effort if adopted. But as it is, it means tons of EXTRA effort, which is not clear is if better than the current wasted effort because of C deficiencies.
  - lisper 10y ago
    > You haven't considered 2 things: marginal returns and opportunity cost. Yes, I have. > this overlooks the millions of hours spent in C systems No, it doesn't. You are assuming that I am advocating re-writing existing C code in this hypothetical new language. I'm not. The hypothetical new language should be backwards-compatible with C, either a superset of C (like C++) or with a C (and C++) FFI (just about every other language out there today). But even that is not strictly necessary. It is already common practice for programs written in different languages to interact with each other via language-independent mechanisms like pipes and sockets. > If the better language already existed, and was a drop in replacement (meaning everything just works) then your argument would indeed mean an end to wasted effort if adopted. Many such languages exist. The one I like to use, Common Lisp (and specifically Clozure Common Lisp) not only has a C FFI, it has an Objective-C FFI, which allows me to easily write Cocoa applications and leverage all of the power of both C and ObjC libraries on OS X with all of the efficiency of C. No wheel-reinventing required. And yes, everything Just Works. (With QuickLisp it really Just Works!) > But as it is, it means tons of EXTRA effort No, it doesn't. If you think it does, then you're doing it wrong.
    - coldtea 10y ago
      > Many such languages exist. The one I like to use, Common Lisp (and specifically Clozure Common Lisp) not only has a C FFI, it has an Objective-C FFI, which allows me to easily write Cocoa applications and leverage all of the power of both C and ObjC libraries on OS X with all of the efficiency of C. No wheel-reinventing required. And yes, everything Just Works. (With QuickLisp it really Just Works!) Not sure in what parallel universe starting to write software in CL, and getting hundreds of thousands of C programmers to adopt it doesn't mean "tons of EXTRA effort". Heck, even the re-training required is millions of man-hours. Even worse for the other proposed solution, to have legacy programs (that is: 99.9999% of available software that's not in the "NEW LANGUAGE") written in different languages to interact with each other via language-independent mechanisms like pipes and sockets. And all that to gain what? Supposedly it was to have a language where compilers could take advantage of the superior design to be even faster and more optimized than C, and you propose CL, which, after 30+ years, is slower or at best equal-ish to C.
      - lisper 10y ago
        I was not suggesting that all C programmers switch to Common Lisp (though I don't think that would be a bad thing). I was just citing that as an existence proof that it is possible to introduce a new language into the software development mix without abandoning all of the legacy code written in C. > And all that to gain what? The ability to write future software with less effort (and that is more reliable and secure) than past software. > equal-ish to C. Equal-ish is good enough given the big win in security, reliability and development effort.
        coldtea 10y ago
        >I was just citing that as an existence proof that it is possible to introduce a new language into the software development mix without abandoning all of the legacy code written in C. I don't think anybody doubted that. At least not anybody who ever heard of the C calling conventions and FFIs. But you started this thread advocating for something much stronger, which I read (correct me if I'm wrong) as: working around C is wasting so much effort, people should adopt a better language design for better compiler optimizations, etc. Unless this adoption is actually a mass phenomenon (even a replacement), then instead of improving things, it only split all the effort and worsened things. >The ability to write future software with less effort (and that is more reliable and secure) than past software (...) Equal-ish is good enough given the big win in security, reliability and development effort. At the start of this thread you were all about compiler optimizations for speed -- not about more reliability and security. Now "equal-ish" to C is good enough?

lisper 10y ago

> Is that really a problem? I think it is if you consider wasted effort a problem. But apparently not everyone does. > compilers are clever enough Yes, but only because someone did a lot of work to make them clever. And they only had to do that work because someone else did a lot of work to write a clever algorithm. If we as an industry had just done the Right Thing to begin with both of those people could have used that time to do something more productive.

coldtea 10y ago
>I think it is if you consider wasted effort a problem. But apparently not everyone doe You haven't considered 2 things: marginal returns and opportunity cost. Your solution to this "wasted effort" is to build a better C (or a better language). But this overlooks the millions of hours spent in C systems, C code, C compilers, learning, and all that would have to be done once again... If the better language already existed, and was a drop in replacement (meaning everything just works) then your argument would indeed mean an end to wasted effort if adopted. But as it is, it means tons of EXTRA effort, which is not clear is if better than the current wasted effort because of C deficiencies.
- lisper 10y ago
  > You haven't considered 2 things: marginal returns and opportunity cost. Yes, I have. > this overlooks the millions of hours spent in C systems No, it doesn't. You are assuming that I am advocating re-writing existing C code in this hypothetical new language. I'm not. The hypothetical new language should be backwards-compatible with C, either a superset of C (like C++) or with a C (and C++) FFI (just about every other language out there today). But even that is not strictly necessary. It is already common practice for programs written in different languages to interact with each other via language-independent mechanisms like pipes and sockets. > If the better language already existed, and was a drop in replacement (meaning everything just works) then your argument would indeed mean an end to wasted effort if adopted. Many such languages exist. The one I like to use, Common Lisp (and specifically Clozure Common Lisp) not only has a C FFI, it has an Objective-C FFI, which allows me to easily write Cocoa applications and leverage all of the power of both C and ObjC libraries on OS X with all of the efficiency of C. No wheel-reinventing required. And yes, everything Just Works. (With QuickLisp it really Just Works!) > But as it is, it means tons of EXTRA effort No, it doesn't. If you think it does, then you're doing it wrong.
  - coldtea 10y ago
    > Many such languages exist. The one I like to use, Common Lisp (and specifically Clozure Common Lisp) not only has a C FFI, it has an Objective-C FFI, which allows me to easily write Cocoa applications and leverage all of the power of both C and ObjC libraries on OS X with all of the efficiency of C. No wheel-reinventing required. And yes, everything Just Works. (With QuickLisp it really Just Works!) Not sure in what parallel universe starting to write software in CL, and getting hundreds of thousands of C programmers to adopt it doesn't mean "tons of EXTRA effort". Heck, even the re-training required is millions of man-hours. Even worse for the other proposed solution, to have legacy programs (that is: 99.9999% of available software that's not in the "NEW LANGUAGE") written in different languages to interact with each other via language-independent mechanisms like pipes and sockets. And all that to gain what? Supposedly it was to have a language where compilers could take advantage of the superior design to be even faster and more optimized than C, and you propose CL, which, after 30+ years, is slower or at best equal-ish to C.
    - lisper 10y ago
      I was not suggesting that all C programmers switch to Common Lisp (though I don't think that would be a bad thing). I was just citing that as an existence proof that it is possible to introduce a new language into the software development mix without abandoning all of the legacy code written in C. > And all that to gain what? The ability to write future software with less effort (and that is more reliable and secure) than past software. > equal-ish to C. Equal-ish is good enough given the big win in security, reliability and development effort.
      - coldtea 10y ago
        >I was just citing that as an existence proof that it is possible to introduce a new language into the software development mix without abandoning all of the legacy code written in C. I don't think anybody doubted that. At least not anybody who ever heard of the C calling conventions and FFIs. But you started this thread advocating for something much stronger, which I read (correct me if I'm wrong) as: working around C is wasting so much effort, people should adopt a better language design for better compiler optimizations, etc. Unless this adoption is actually a mass phenomenon (even a replacement), then instead of improving things, it only split all the effort and worsened things. >The ability to write future software with less effort (and that is more reliable and secure) than past software (...) Equal-ish is good enough given the big win in security, reliability and development effort. At the start of this thread you were all about compiler optimizations for speed -- not about more reliability and security. Now "equal-ish" to C is good enough?