4 ms·

> The right name for a function that counts bits is "bitcount", not "popcount" "Population count" is what this function is typically called. > (and certainly

> The right name for a function that counts bits is "bitcount", not "popcount" "Population count" is what this function is typically called. > (and certainly not __builtin_popcount!) C doesn't have namespacing and naming the function "bitcount" would almost certainly collide with user code. > 2. __builtin_popcount only works on unsigned ints. If you want to count bits in anything else (a string, say, or a bignum) you're back to square 1. Not really? Just use __builtin_popcount in a loop.

lisper 10y ago
> "Population count" is what this function is typically called. I didn't know that. Thanks. > C doesn't have namespacing That I did know. I even pointed that out in the comment you're responding to :-) > Just use __builtin_popcount in a loop. 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.
- theseoafs 10y ago
  > 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

> "Population count" is what this function is typically called. I didn't know that. Thanks. > C doesn't have namespacing That I did know. I even pointed that out in the comment you're responding to :-) > Just use __builtin_popcount in a loop. 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.

theseoafs 10y ago
> 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.