3 ms·

> Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense. I feel like this entire

> Additionally, modern processors all have at minimum 64 bit buses, so exposing anything other than 64 bit scalar types makes no sense. I feel like this entirely disregards the caching costs of using >2x more memory in some cases, speed of float32 vs float64 operations on CPU, and potential CPU <-> GPU memory transfers. EDIT: Nvm disregard this comment, I just noticed the existence of: PackedByteArray, PackedInt32Array, PackedInt64Array, PackedFloatArray, PackedDoubleArray Anything set of numbers needed by the GPU or big enough to affect the cache will probably use those arrays.

jackmott42 3y ago
In the context of function parameters at the edge of C# and c++ I don't think it will ever amount to a large amount of memory being wasted. The cache point may be relevant, but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. So maybe not so bad.
- jayd16 3y ago
  >but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. How do you figure? Are you saying there should be no tight loops that hit engine code, none that live in the C#/scripting lifecycle or all tight loops should be rewritten in C++? The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me.
  - badsectoracula 3y ago
    > The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me. As a game developer you do not have access to Unity's C++ code so to maintain some performance Unity needs to do that. But this is not the case with Godot or even Unreal where any intensive code should be written (or at least, rewritten) in C++ and use the scripts only to drive the behavior.
    - jayd16 3y ago
      This seems inaccurate. You can certainly write C++ for Unity. People usually don't. Its a pain and C# performance is good. IL2CPP allows the compiler to optimize across game and engine code so its rare to write C++ plugins. Unreal also supports generating C++ from blueprints. But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.
      - johnnyanmac 3y ago
        It's such a bizarro world after a bunch of UE discussions to suddenly see people dismiss scripting concerns with "well just write that code in C++. Blueprints is slow". I'm usually the one saying that, but that's as a professional developer who needs to optimize all that stuff (and TBH the blueprint code tends to have some bad performance choices even before discussing the BP perf loss). Hearing people dismiss the performance of something as basic as a raycast with "well just code in C++", while many people (including this founder) say that Godot focuses on simplicity sounds counter-intuitive. So is GDScript a lie for anything slightly intensive (and again, raycast. I'm using "intense" in the loosest of words) and I should simply make my whole game an engine module? But I keep hearing that "I should just try GDScript it's really easy and you come around to it!" Feels like a motte and bailey.
        badsectoracula 3y ago
        What i wrote wasn't making your whole game an engine module (i.e. writing everything in C++) but writing your intensive code in C++ and using scripting (be it blueprints, GDScript or whatever) to drive that intensive code. There is nothing counterintutive in that, it is right in the name of scripting languages: they're meant to script behavior. And the dismissal isn't about having a raycast being slow, but about using too many raycast queries in script to do something reusable that should be in native code in the first place. If your scripting language ends up in your performance profile chances are you are using it wrong. The occasional raycast query in scripts to make a decision is fine, doing thousands of individual raycast queries from scripts is not - if nothing else, make an API that accepts multiple raycast queries at once, performs it in C++ in a single call (so you only get the scripting overhead for that single call) and gives the result back. But IMO if, as mentioned in the article, you are going to make a controller that is to be used by multiple entities in the game, then you should make it in C++ - potentially with script hooks to customize the behavior, if needed.
  - 3seashells 3y ago
    Tight loops mean:develope one specialized function call which gets a field of data and works on it.. Resurfacing after the job is done. You may even invert direction, handing over a pure script language function (no context) + the data, so the c++ engine may crunch the data at least in parallel small script vms without stack, similar to a shader.
- lainga 3y ago
  I think part of the problem is that using GDExtension is like a two-way FFI. You can call (C++) extension functions from GDScript, but the same interface and overhead are used to call (lib) Godot functions from the (C++) extension. AFAIK it's not like there's a <godot_impl.h> with engine functions that the compiler could inline. Here's a good example (look, there I am!), although it's a bit old and actually led to perf improvement: https://github.com/godotengine/godot-cpp/issues/1063 https://github.com/godotengine/godot-cpp/issues/1063
gabereiser 3y ago
Yes, however, by the time they fix the dictionary hack glue code as described, PCI bus transfer speeds will have increased (again). I’m a fan of making everything 64bit from an api level, but sometimes you have to work with the right type for the architecture.
deleted 3y ago
[deleted]

jackmott42 3y ago

In the context of function parameters at the edge of C# and c++ I don't think it will ever amount to a large amount of memory being wasted. The cache point may be relevant, but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. So maybe not so bad.

jayd16 3y ago
>but generally if you are calling into C++ in tight loops from your scripting language in a game you have already screwed up. How do you figure? Are you saying there should be no tight loops that hit engine code, none that live in the C#/scripting lifecycle or all tight loops should be rewritten in C++? The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me.
- badsectoracula 3y ago
  > The elephant in the room, Unity, cross compiles the C# to C++ which makes this blanket statement about all games even more confusing to me. As a game developer you do not have access to Unity's C++ code so to maintain some performance Unity needs to do that. But this is not the case with Godot or even Unreal where any intensive code should be written (or at least, rewritten) in C++ and use the scripts only to drive the behavior.
  - jayd16 3y ago
    This seems inaccurate. You can certainly write C++ for Unity. People usually don't. Its a pain and C# performance is good. IL2CPP allows the compiler to optimize across game and engine code so its rare to write C++ plugins. Unreal also supports generating C++ from blueprints. But saying 'oh you shouldn't use the nice language anyway' is just making excuses. Obviously they're meant to be used to call engine code.
    - johnnyanmac 3y ago
      It's such a bizarro world after a bunch of UE discussions to suddenly see people dismiss scripting concerns with "well just write that code in C++. Blueprints is slow". I'm usually the one saying that, but that's as a professional developer who needs to optimize all that stuff (and TBH the blueprint code tends to have some bad performance choices even before discussing the BP perf loss). Hearing people dismiss the performance of something as basic as a raycast with "well just code in C++", while many people (including this founder) say that Godot focuses on simplicity sounds counter-intuitive. So is GDScript a lie for anything slightly intensive (and again, raycast. I'm using "intense" in the loosest of words) and I should simply make my whole game an engine module? But I keep hearing that "I should just try GDScript it's really easy and you come around to it!" Feels like a motte and bailey.
      - badsectoracula 3y ago
        What i wrote wasn't making your whole game an engine module (i.e. writing everything in C++) but writing your intensive code in C++ and using scripting (be it blueprints, GDScript or whatever) to drive that intensive code. There is nothing counterintutive in that, it is right in the name of scripting languages: they're meant to script behavior. And the dismissal isn't about having a raycast being slow, but about using too many raycast queries in script to do something reusable that should be in native code in the first place. If your scripting language ends up in your performance profile chances are you are using it wrong. The occasional raycast query in scripts to make a decision is fine, doing thousands of individual raycast queries from scripts is not - if nothing else, make an API that accepts multiple raycast queries at once, performs it in C++ in a single call (so you only get the scripting overhead for that single call) and gives the result back. But IMO if, as mentioned in the article, you are going to make a controller that is to be used by multiple entities in the game, then you should make it in C++ - potentially with script hooks to customize the behavior, if needed.
- 3seashells 3y ago
  Tight loops mean:develope one specialized function call which gets a field of data and works on it.. Resurfacing after the job is done. You may even invert direction, handing over a pure script language function (no context) + the data, so the c++ engine may crunch the data at least in parallel small script vms without stack, similar to a shader.
lainga 3y ago
I think part of the problem is that using GDExtension is like a two-way FFI. You can call (C++) extension functions from GDScript, but the same interface and overhead are used to call (lib) Godot functions from the (C++) extension. AFAIK it's not like there's a <godot_impl.h> with engine functions that the compiler could inline. Here's a good example (look, there I am!), although it's a bit old and actually led to perf improvement: https://github.com/godotengine/godot-cpp/issues/1063 https://github.com/godotengine/godot-cpp/issues/1063

gabereiser 3y ago

Yes, however, by the time they fix the dictionary hack glue code as described, PCI bus transfer speeds will have increased (again). I’m a fan of making everything 64bit from an api level, but sometimes you have to work with the right type for the architecture.

deleted 3y ago

[deleted]