I'm creating a textured ray-cast engine for the Prizm and I think this point-plot routine is a bottleneck on the speed. Would there be a significant speed boost to drawing if the plot routine below was written in assembly?


Code:


Is there any documentation about Prizm assembly or online resources I could use to try and re-write this? I don't have any knowledge about assembly, so I'm unsure where I would start with this.

Actually you can make your C code much better try this

Code:

I see that plot code you posted to be very wide spread I never understood where it came from. The code I posted does the same thing but faster.

Probably from the "useful routines" thread.



I have replaced the old code with this one in my Utilities add-in, even if drawing, in this add-in, doesn't need to be really fast (hence I'm not making it inline as that would result in a binary size increase).

Thanks for the better optimized routine ProgrammerNerd. I'm still interested if anyone has information on Prizm assembly, however. Would the speed increase make it worth learning?

If you're plotting a crapload of pixels, just inline the memory operation instead of using the function. That'll save more cycles than converting to Assembly.

See GCC 6.39 An Inline Function is As Fast As a Macro





From the above, use inline static void plot(int x0, int y0, unsigned short color) {/* ... */} instead.

Thank you for the clarification; there was a notable speed increase with that change.

Hi, I'm new here, and I just register here to reply
Just to say that with some Planète-Casio members, we've been working on an asm pixel plot routine...
Seeing some of the posts above, I don't know if it would be faster but I just say it exists


Code:


Perheaps this isn't what you'd like to know, but we can gain almost 25 % of time by using it instead of the first you said (the one not inlined), depending of the purpose ...
For this purpose, it would perheaps not be better than inlined, but in some other case, i don't know...

So, that's all for this post ( ), I just wanted to show you this and why not, having some feedbacks .

Ps : sorry for my potential bad English, I tried to do my best, but i had some hesitation .

Could this be inlined? That might give an even better performance boost.

I'd actually expect simply inlining the original routine to give at least a 25% performance boost. Also, I was the author of that original one; it was written before we had a color_t type. ProgrammerNerd, I believe GCC optimizes my two-byte write pair to be equivalent to a single short write anyway.

Yes, they already said inlining the original gave a performance boost... I was wondering if inlining the ASM would then give an even better performance boost.

After I replaced your routine with his, the CPU usage of the Prizm emulator (which is related to the time the emulated SH CPU keeps processing instead of in a simple loop waiting for a key in GetKey, per total time) on the main screen of my Utilities add-in (on which the analog clock calls plot() a lot per draw and gets drawn multiple times per second), dropped significantly - the fan of my computer used to kick in after a while when at that screen, with the new routine it no longer kicks in, or does so at a slower speed.
I have reverted to the old routine again, only to see the fan get to work sooner again. It's back at ProgrammerNerd's one. So there's definitely a difference between the two versions, even after compiler optimizations.

The obvious way to do a scientific comparison is to have GCC emit assembly for each option (-S), and compare them.

I suspect a pure-C version with correct inlining and optimization will perform better than an inline-assembly version, since when inlined the constant folding pass should be able to generate addresses more efficiently rather than recomputing on every call. In degenerate cases where you write to a fixed location, it should optimize to a store to the appropriate address.

I'd imagine that this will be even faster. It is untested but should work.

Code:

I have four different functions which draw to the VRAM; would it be a good idea (e.g. more efficient) to make a global variable that stores the VRAM's memory address instead of recreating it every function call?

Something like this possibly?

Code:

It won't matter; any decent optimizing compiler will replace the usage of the constant with an immediate value in the final code.

Edit: Just make sure it's a const.

When it is created in the drawing functions? Also, did I put the 'const' in the right place there?

Edit:
Never mind about that; I just realized that what I was suggesting doesn't really make any sense in the first place.

Any progress on getting some solid optimizations in, Ygyax? Did you compare the output assembly generated from the two varieties, as Tari suggested?

Yes, there has been some rather significant optimization. I opted to go with the static inlined C version of the pixel plotting routine instead of the assembly one, and I have converted all of the floating point math to fixed point. I also created a sine table for Sine and Cosine calculations. I'd like to release a demo of it soon, as it runs surprisingly well without overclocking, but there is still one major bug I need to fix. I already went into detail about it here though, so I'll leave the discussion about it there.