Cosmos
Cosmos copied to clipboard
CosmosOS
Long division is extremly slow
Area of Cosmos - What area of Cosmos are we dealing with?
Division, (implemented in x#)
Expected Behaviour - What do you think that should happen?
numbers should divide fast without much performance lost
Actual Behaviour - What unexpectedly happens?
significant speed impact (from 600 fps all the way down to 40)
Reproduction - How did you get this error to appear?
34671 / 1024 every frame
Version - Were you using the User Kit or Dev Kit? And what User Kit version or Dev Kit commit (Cosmos, IL2CPU, X#)?
devkit
it looks like we are using the div opcode from nasm i dont know if we can make it faster in a way that makes sense https://github.com/CosmosOS/XSharp/blob/master/source/XSharp/XSharp/Assembler/Gen1/x86/Divide.cs
The issue is with long not int, where we cannot use the div assembly instruction.
Is this really a bug? Division works, it's just slow, so I don't think it can be considered a bug. @terminal-cs @quajak
I'm not able to reproduce this bug. I'm even using C# division and have set fields to long, yet it did not impact performance. So, I'm assuming that using X# directly will not have any impact either. Could you give a bit more details please? @terminal-cs
I'm not able to reproduce this bug. I'm even using C# division and have set fields to
long, yet it did not impact performance. So, I'm assuming that using X# directly will not have any impact either. Could you give a bit more details please? @terminal-cs
I don't know what else i need to say here, all i know is that i divided a big number every frame and it had a huge performance impact
I'm not able to reproduce this bug. I'm even using C# division and have set fields to
long, yet it did not impact performance. So, I'm assuming that using X# directly will not have any impact either. Could you give a bit more details please? @terminal-csI don't know what else i need to say here, all i know is that i divided a big number every frame and it had a huge performance impact
Is the division that you gave (34671 / 1024) the actual one you did every frame or is it another one?
I'm not able to reproduce this bug. I'm even using C# division and have set fields to
long, yet it did not impact performance. So, I'm assuming that using X# directly will not have any impact either. Could you give a bit more details please? @terminal-csI don't know what else i need to say here, all i know is that i divided a big number every frame and it had a huge performance impact
Is the division that you gave (
34671 / 1024) the actual one you did every frame or is it another one?
another one I belive, I was dividing some memory variable so get it in mb
I'm not able to reproduce this bug. I'm even using C# division and have set fields to
long, yet it did not impact performance. So, I'm assuming that using X# directly will not have any impact either. Could you give a bit more details please? @terminal-csI don't know what else i need to say here, all i know is that i divided a big number every frame and it had a huge performance impact
Is the division that you gave (
34671 / 1024) the actual one you did every frame or is it another one?another one I belive, I was dividing some memory variable so get it in mb
Ah, so you were getting the amount of memory... I'll try that soon.
I tried with Result = GCImplementation.GetUsedRAM() / 1024; and yet my performance is practically the same (no major drop in performance).
GetUsedRAM returns an uint not a long
Yeah but isn't it the way to get used RAM? It's also what OP used (at least, getting used RAM) for their division.
Practically, 64-bit division while running in protected mode will always be slower than 32-bit division - just like 32-bit division is slower while in real mode. The only practical solution would be to use long mode instead. Until then, we can take a look at the GCC function _divdi3 and try to implement it in IL2CPU.
