6 ms·

Pop Quiz: Why should I clutter my brain with these little guessing games about what the compiler is doing? And why should these pop quizzes slow down my group's

by kmavm 17y ago

Pop Quiz: Why should I clutter my brain with these little guessing games about what the compiler is doing? And why should these pop quizzes slow down my group's code reviews? There are, after all, languages out there that do not force this insanity on us. The alternative for performance-critical applications is not Java, but C. C remains surprisingly tough competition after all these years for those rare pieces of software where programmer time is cheap compared to hardware resources. Having had non-trivial experience of both languages, reasoning about the performance of a C program is much, much easier than reasoning about non-trivial C++ programs' performance. Guesses based on local code inspection have an order of magnitude less uncertainty attached to them, which is basically what Rachel is saying here.

dtf 17y ago
Ugh. Try attacking the vector math required for most games programming these days in C, using macros and magic instead of classes and templates and operator overloading. I'd rather blow my own leg off with a bit of C++ any day.
- deleted 17y ago
  [deleted]
timr 17y ago
"Guesses based on local code inspection have an order of magnitude less uncertainty attached to them" ...which is why we have profiling tools that make it easy to detect performance hotspots. For the other 95% of our code, the expressiveness of C++ makes it easier to do more work in fewer lines. This is a far more important metric to any working developer (and it's a big reason why languages like Python and Ruby are popular.) Also, you're exaggerating. I wrote C++ for well over a decade, and I wrote in C before that, and used it again in graduate school for my research. While I can count on one hand the number of times that I was affected by "hidden" C++ costs, I was routinely blindsided by bad C code, where pointer errors, type safety gotchas, and inefficiency due to aliasing are de rigeur. You'd be crazy to write a non-trivial application in C today that wasn't an operating system.
- groby_b 17y ago
  Given that games more or less have to implement their own OS, I hope I'm not completely crazy yet ;) I am not talking about "business apps" (whatever that is). I'm talking about down-to-the-metal resource management, task scheduling, etc. I could probably live with those issues in the higher logic layers (although I'd argue a scripting language would make you much more efficient there). But the underlying "OS" as well as computationally intensive tasks do not benefit from C++ that much, and it causes a lot of collateral damage.
  - timr 17y ago
    " But the underlying "OS" as well as computationally intensive tasks do not benefit from C++ that much, and it causes a lot of collateral damage." No. C++ has some pretty huge advantages for performance-critical software. Generic programming makes it possible to write extremely succinct, high-performance code. Operator overloading allows the creation of vector and matrix libraries that look like real mathematical expressions, while evaluating to code that's as fast as anything you'll get from Fortran. I didn't write "business apps" (not sure where you got that). I wrote software that simulated proteins -- in other words, high-performance computing -- and except for FORTRAN, C++ was the best choice for the job. Doing the equivalent optimizations of a library like Boost::MPL in C is a nightmare of pointer arithmetic. When you throw in the fact that C++ makes it easy to avoid the memory leak, corruption and type safety issues that plague C code, you can easily see why C++ is becoming the language of choice in the HPC world.
    - groby_b 17y ago
      _why C++ is becoming the language of choice in the HPC world._ And yet, the HPC world looks for a new language: http://www.cs.sandia.gov/Conferences/SOS10/presentations/Tuesday/Snir.pdf http://www.cs.sandia.gov/Conferences/SOS10/presentations/Tue... And a lot of the HPC world still writes FORTRAN or C. (I.e. BLAS, LAPACK, et.al.) But then again, I don't spend that much time in the true HPC world. Maybe I'm missing a trend there. But from the outside, it looks like C++ is not quite what people wanted.
blub 17y ago
I am surprised to see that so many programmers still like to reason and guess what the performance of their program is instead of profiling it... And hearing C proposed as an alternative to C++ is mind boggling. I don't want to match malloc/free calls, strcat strings together or realloc pointers. I don't want to declare a bunch o function pointers in a struct and call it OOP. I don't want to use macros because C99 has poor adoption rate and C89 doesn't have inline. I don't want to watch the compiler blissfully convert unrelated types to one another just because it can. I don't want to pass types around as void* and lose any useful type information I might have had. I don't want to fumble with return codes. And in C++ I don't have to. I can use Qt, the STL and Boost and be very productive. Telling me to program in C is not even funny.
- groby_b 17y ago
  I propose a lower level than C++ for the kernel, and a higher level for the rest. C++ is simply at the wrong abstraction level. Oh, and I don't want to manually track resources myself, either. But guess what, somebody has to do. And on a game console, that's you. There's not much of an OS to speak of. You did notice I was talking about game development, right? ;)
  - blub 17y ago
    My reply was not targeted at you and I don't do game programming. Anyway: * smart pointers don't need an OS. * for me, C++ is at the exactly right abstraction level to allow me to use only C++ instead of "C++ + other language" or "other language and C for speed". Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages.
    - groby_b 17y ago
      _Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages._ I'll concede that as a valid concern, especially for smaller projects where everybody touches many areas of the code. As projects grow, a separation becomes easier. Add to that the fact that most games need scripting support anyways, and you'll see that the logistics overhead is at least not much different.

by kmavm 17y ago

dtf 17y ago

Ugh. Try attacking the vector math required for most games programming these days in C, using macros and magic instead of classes and templates and operator overloading. I'd rather blow my own leg off with a bit of C++ any day.

deleted 17y ago
[deleted]

timr 17y ago

"Guesses based on local code inspection have an order of magnitude less uncertainty attached to them" ...which is why we have profiling tools that make it easy to detect performance hotspots. For the other 95% of our code, the expressiveness of C++ makes it easier to do more work in fewer lines. This is a far more important metric to any working developer (and it's a big reason why languages like Python and Ruby are popular.) Also, you're exaggerating. I wrote C++ for well over a decade, and I wrote in C before that, and used it again in graduate school for my research. While I can count on one hand the number of times that I was affected by "hidden" C++ costs, I was routinely blindsided by bad C code, where pointer errors, type safety gotchas, and inefficiency due to aliasing are de rigeur. You'd be crazy to write a non-trivial application in C today that wasn't an operating system.

groby_b 17y ago
Given that games more or less have to implement their own OS, I hope I'm not completely crazy yet ;) I am not talking about "business apps" (whatever that is). I'm talking about down-to-the-metal resource management, task scheduling, etc. I could probably live with those issues in the higher logic layers (although I'd argue a scripting language would make you much more efficient there). But the underlying "OS" as well as computationally intensive tasks do not benefit from C++ that much, and it causes a lot of collateral damage.
- timr 17y ago
  " But the underlying "OS" as well as computationally intensive tasks do not benefit from C++ that much, and it causes a lot of collateral damage." No. C++ has some pretty huge advantages for performance-critical software. Generic programming makes it possible to write extremely succinct, high-performance code. Operator overloading allows the creation of vector and matrix libraries that look like real mathematical expressions, while evaluating to code that's as fast as anything you'll get from Fortran. I didn't write "business apps" (not sure where you got that). I wrote software that simulated proteins -- in other words, high-performance computing -- and except for FORTRAN, C++ was the best choice for the job. Doing the equivalent optimizations of a library like Boost::MPL in C is a nightmare of pointer arithmetic. When you throw in the fact that C++ makes it easy to avoid the memory leak, corruption and type safety issues that plague C code, you can easily see why C++ is becoming the language of choice in the HPC world.
  - groby_b 17y ago
    _why C++ is becoming the language of choice in the HPC world._ And yet, the HPC world looks for a new language: http://www.cs.sandia.gov/Conferences/SOS10/presentations/Tuesday/Snir.pdf http://www.cs.sandia.gov/Conferences/SOS10/presentations/Tue... And a lot of the HPC world still writes FORTRAN or C. (I.e. BLAS, LAPACK, et.al.) But then again, I don't spend that much time in the true HPC world. Maybe I'm missing a trend there. But from the outside, it looks like C++ is not quite what people wanted.

blub 17y ago

I am surprised to see that so many programmers still like to reason and guess what the performance of their program is instead of profiling it... And hearing C proposed as an alternative to C++ is mind boggling. I don't want to match malloc/free calls, strcat strings together or realloc pointers. I don't want to declare a bunch o function pointers in a struct and call it OOP. I don't want to use macros because C99 has poor adoption rate and C89 doesn't have inline. I don't want to watch the compiler blissfully convert unrelated types to one another just because it can. I don't want to pass types around as void* and lose any useful type information I might have had. I don't want to fumble with return codes. And in C++ I don't have to. I can use Qt, the STL and Boost and be very productive. Telling me to program in C is not even funny.

groby_b 17y ago
I propose a lower level than C++ for the kernel, and a higher level for the rest. C++ is simply at the wrong abstraction level. Oh, and I don't want to manually track resources myself, either. But guess what, somebody has to do. And on a game console, that's you. There's not much of an OS to speak of. You did notice I was talking about game development, right? ;)
- blub 17y ago
  My reply was not targeted at you and I don't do game programming. Anyway: * smart pointers don't need an OS. * for me, C++ is at the exactly right abstraction level to allow me to use only C++ instead of "C++ + other language" or "other language and C for speed". Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages.
  - groby_b 17y ago
    _Most C + HLL proponents underestimate the logistics overhead of using multiple programming languages._ I'll concede that as a valid concern, especially for smaller projects where everybody touches many areas of the code. As projects grow, a separation becomes easier. Add to that the fact that most games need scripting support anyways, and you'll see that the logistics overhead is at least not much different.