fixed point was a mistake
Uncategorized
82
Posts
27
Posters
12
Views
-
-
scalar
flat random triangles/sec 1,049,510 -> 1,210,082
flat random pixels/sec 460,701,636 -> 529,507,748
+15%tiled (x4 workers)
flat random triangles/sec 5,440,951 -> 11,253,417
flat random pixels/sec 2,388,405,031 -> 4,924,271,126
+106% -
@eniko BTW are you using only scalar math or are you leveraging SIMD extensions? IIUC one of the advantages of fixed-point math is that you could implement some stuff on x86 even with the oldest, crustiest SIMD stuff (hello MMX!) and get at least some benefits
@gabrielesvelto i'm not using any SIMD atm so its scalar only
-
To be clear, everything improved 0-35% from the previous implementation that used floating point after switching to fixed point
So the current threaded random triangles with flat color metric (fixed point) is 2x as fast as the previous threaded random triangles with flat color metric (floating point)
@eniko it would take some staring at assembly to know for sure, but one possibility is that the lack of needing to care about floating point specials (inf, nan) lets the optimizer do a better job. Float semantics are hard for compilers to work around without fastmath (do not use fastmath.)
-
@eniko it would take some staring at assembly to know for sure, but one possibility is that the lack of needing to care about floating point specials (inf, nan) lets the optimizer do a better job. Float semantics are hard for compilers to work around without fastmath (do not use fastmath.)
@ataylor but the single threaded random flat color triangles metric only improved by +15%
and all the threading does is take 4 worker threads, split the screen into 4 quadrants, and have each of them call the regular single-threaded renderer for every triangle on their quadrant
-
@ataylor but the single threaded random flat color triangles metric only improved by +15%
and all the threading does is take 4 worker threads, split the screen into 4 quadrants, and have each of them call the regular single-threaded renderer for every triangle on their quadrant
@eniko that is quite odd. What is the relative speedup between threaded and unthreaded for each? (Like, float single threaded versus multi threaded and so on.)
-
@eniko that is quite odd. What is the relative speedup between threaded and unthreaded for each? (Like, float single threaded versus multi threaded and so on.)
@ataylor
random flat color triangles x9.3
random gouraud triangles x4.7
fullscreen flat color triangles x2.2
fullscreen gouraud triangles x2.8 -
@eniko @oblomov Did the conversion only affect the pure computation part, or did some buffer formats/sizes change too?
I'm thinking if you did something like f32 to u8 per channel for the framebuffer, the tiles now fit in cache and that can be a huge speedup.
Verify by testing just one of the four quadrant threads, or alternatively just non threaded version with lower resolution.
-
@slyecho as in threaded flat color random triangles with fixed point is 2x as fast as threaded flat color random triangles with floating point
@eniko Yeah that makes sense, ints are faster.
-
@ataylor
random flat color triangles x9.3
random gouraud triangles x4.7
fullscreen flat color triangles x2.2
fullscreen gouraud triangles x2.8@eniko that seems… weird. I would expect close to 4x for all of these, tbh.
-
@eniko @oblomov Did the conversion only affect the pure computation part, or did some buffer formats/sizes change too?
I'm thinking if you did something like f32 to u8 per channel for the framebuffer, the tiles now fit in cache and that can be a huge speedup.
Verify by testing just one of the four quadrant threads, or alternatively just non threaded version with lower resolution.
-
-
-
-
@eniko@mastodon.gamedev.place @lina@vt.social @oblomov@sociale.network ..probably cache performance getting better due to more thread-wise allocation of space??
-
-
-
-
To be clear, everything improved 0-35% from the previous implementation that used floating point after switching to fixed point
So the current threaded random triangles with flat color metric (fixed point) is 2x as fast as the previous threaded random triangles with flat color metric (floating point)
ah, it might actually be cache after all. if i drop resolution to 80x50 then scalar->threaded is only 4.4x
-
@oblomov @eniko @lina no idea if this applies here, but I remember reading something about multi-threading yielding more performance improvement than the number of threads in some cases, because some CPU architectures have memory cache per-core, so more threads means more cache memory which can overcome a bottleneck. As a rule of thumb, I believe multi-thread performance is hard to measure and hard to understand 😉
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@youen @eniko @lina as I mentioned in the other reply, it is of course possible, but I'd find it extremely surprising. I'm assuming the data size and access patterns are similar, and the FPU should have more registers and shield be able to retire more instructions per cycle than the ALU + with fixed point there's generally a higher op density for equivalent abstract operation in the numbers (consider a multiplication in fixed point vs in floating point).
-
@eniko says "i won't infodump without permission, but here's the short version", writes two hundred words anyway. the struggle to contain oneself can sometimes really be immense, huh 🫠
-
@eivind @NanoRaptor the skibidi is going great on the other hand
-
@eniko I am swamped with work right now, otherwise I would ask for permission to infodump :D
TLDR is there's thousands (or at least multiple hundred) counters inside the CPU that tick up for all kinds of performance- and otherwise relevant events (cache misses for example) and each OS gives you a way to read these out, plus the kernel can make sure it's properly accounted per process or thread and whatnot. some of these counters are preposterously specific, like uhhhhhh "Number of cycles dispatch is stalled for integer scheduler queue 3 tokens". But there's usually a little selection of commonly useful ones available with some extra simple command.
It's absolutely fascinating what you can, in theory, do if you want to dig really really really far down, but to be honest, I usually get very little really actionable insights from anything more intricate than the most basic ones ;(
absolutely a skill issue from my end I'm convinced!
-
How well would it work to do it in two passes at 160x50x4?
-
@TheBreadmonkey @jbenjamint geniusinely ;-)
-
@ygathgoch @TheBreadmonkey that's how capoeira was born. Also I'm sure there's some Ranma episode about a Dancing School of Martial Arts
-
@eniko @oblomov @lina I was mostly trying to find a potential explanation to the x5 gain instead of x4.
There might be multiple factors playing together to make things even more confusing...
About the difference floating vs fixed point, it could be floating point is FPU bound, while for fixed point the bottleneck was the memory cache? Though honestly I'm not experienced enough with such low level considerations.
