Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
1–10 of 83 posts
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#2The original link in HN is in: https://news.ycombinator.com/item?id=37561762
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#3> 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.
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#4> 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,…
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.
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#5Yet
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#6> 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,…
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.
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#7> 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,…
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.
>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.
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#8> 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,…
[deleted]
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#9Strong response.
I'm not sure I would have been so generous to the author of the article this is in reply to. But I suppose that's a skill of a successful open source leader -- to turn interactions with critics into productive discussions rather than arguments, and perhaps even turn the critics into supporters.
It seems to have been that author who chose the FUD-ful title "Godot is not the new Unity". I guess there are times in life where you face a choice: be fair, reasonable, and intelligent, or... just try to get them clicks.
Well, that article got a lot of click. Good job?
Re: Article reply “Godot is not the new Unity” from Juan Linietsky (BDFL of Godot)
#10> 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,…
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.
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 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: