6 ms·

> C has no pattern for breaking out of multiple for loops at the same time. True, but it is cleaner to reorganize the code into several functions and use the r

> C has no pattern for breaking out of multiple for loops at the same time. True, but it is cleaner to reorganize the code into several functions and use the return value to propagate across layers if needed. Performance should be the same. > it's not applicable here Why? If there is a new/delete pair anywhere, it should have been an object. > Game developers have a long-seated distrust of std::vector, and for good reasons. Which reasons? std::vector (and std::unique_ptr) is universally useful (unlike many other std data structures) and codegen should be on par as a new/delete pair. If the std is completely broken in some of the console platforms they need to support (likely from what I hear here) then it can also be done with a custom heap array wrapper. So I don’t see the reason why that shouldn’t have been an object.

Jasper_ 6y ago
> True, but it is cleaner to reorganize the code into several functions and use the return value to propagate across layers if needed. I disagree. Having to jump to another function definition which is inline is a bigger mental block than following a goto. The large amount of arguments you'd need to pass might also be a barrier, as is the mental overhead of checking to see if this function might be called from elsewhere. But reasonable people can disagree on this point. I suggest you try to clean up the function yourself and see if your function-ed version is in any way improved. > Why? If there is a new/delete pair anywhere, it should have been an object. The case we want is that we have a large array of pairwise collisions. This is a temporary array used inside the method. If we ever have more than this, we need a new (contiguous) array. Are you suggesting that the code should have done something like this? template<typename T> class TempArray { T* storage; void resize(int n) { delete[] storage; storage = new T[n]; }; I mean, sure, it's a very minor cleanup. It changes like, two lines though, and makes us have to access the array through an awkward ->storage pointer. Not ideal IMO. > codegen should be on par as a new/delete pair. Here's modern MSVC. Let's play "spot the difference": https://gcc.godbolt.org/z/KqR-LN https://gcc.godbolt.org/z/KqR-LN I'm not even doing anything but allocating the vector / array. It took me 2 minutes to navigate to godbolt and type this in. Don't just say "should be"... test it yourself!
- Remnant44 6y ago
  If you enable /Ox, the codegen basically drops to what you would expect: the vector version drops down essentially identical code to the new/delete (modulo a memset to enforce the clear to zero condition) It is a good illustration of why debug stl builds are such hot garbage though...
  - gmueckl 6y ago
    It is a good illustration for why using the STL is not always a good idea: you can't blindly take the perf hit from that kind of overhead in a debuggable build of a game that you still want to run at reasonably interactive frame rates.
    - jfkebwjsbx 6y ago
      False, most standard libraries out there allow you to configure whether you want extra checks or not.
      - gmueckl 6y ago
        But at least in the case of MSVC that comfiguration option leads to binary incompatibilities that make it an all or nothing option for everything that gets linked together statically. And the checks are so heavy that the "all" option becomes unbearably slow quite quickly. If your project hits a reasonable size, you end up requiring some clever solutions.
- flipchart 6y ago
  I'm still getting up to speed on C++ (& ASM) so forgive the ignorance - are the differences you're referring to all the cleanup code that the vector does in the destructor? As a side note, you're not calling delete[] on the array code, but I suppose it makes little difference if you take the vector cleanup into account.
- westmeal 6y ago
  unfortunately MSVC produces hot garbage asm, clang and gcc produce pretty much the same asm output using your example.

Jasper_ 6y ago

> True, but it is cleaner to reorganize the code into several functions and use the return value to propagate across layers if needed. I disagree. Having to jump to another function definition which is inline is a bigger mental block than following a goto. The large amount of arguments you'd need to pass might also be a barrier, as is the mental overhead of checking to see if this function might be called from elsewhere. But reasonable people can disagree on this point. I suggest you try to clean up the function yourself and see if your function-ed version is in any way improved. > Why? If there is a new/delete pair anywhere, it should have been an object. The case we want is that we have a large array of pairwise collisions. This is a temporary array used inside the method. If we ever have more than this, we need a new (contiguous) array. Are you suggesting that the code should have done something like this? template<typename T> class TempArray { T* storage; void resize(int n) { delete[] storage; storage = new T[n]; }; I mean, sure, it's a very minor cleanup. It changes like, two lines though, and makes us have to access the array through an awkward ->storage pointer. Not ideal IMO. > codegen should be on par as a new/delete pair. Here's modern MSVC. Let's play "spot the difference": https://gcc.godbolt.org/z/KqR-LN https://gcc.godbolt.org/z/KqR-LN I'm not even doing anything but allocating the vector / array. It took me 2 minutes to navigate to godbolt and type this in. Don't just say "should be"... test it yourself!

Remnant44 6y ago
If you enable /Ox, the codegen basically drops to what you would expect: the vector version drops down essentially identical code to the new/delete (modulo a memset to enforce the clear to zero condition) It is a good illustration of why debug stl builds are such hot garbage though...
- gmueckl 6y ago
  It is a good illustration for why using the STL is not always a good idea: you can't blindly take the perf hit from that kind of overhead in a debuggable build of a game that you still want to run at reasonably interactive frame rates.
  - jfkebwjsbx 6y ago
    False, most standard libraries out there allow you to configure whether you want extra checks or not.
    - gmueckl 6y ago
      But at least in the case of MSVC that comfiguration option leads to binary incompatibilities that make it an all or nothing option for everything that gets linked together statically. And the checks are so heavy that the "all" option becomes unbearably slow quite quickly. If your project hits a reasonable size, you end up requiring some clever solutions.
flipchart 6y ago
I'm still getting up to speed on C++ (& ASM) so forgive the ignorance - are the differences you're referring to all the cleanup code that the vector does in the destructor? As a side note, you're not calling delete[] on the array code, but I suppose it makes little difference if you take the vector cleanup into account.
westmeal 6y ago
unfortunately MSVC produces hot garbage asm, clang and gcc produce pretty much the same asm output using your example.