So, to clarify...
BlitzMax Forums/BlitzMax Programming/So, to clarify...
| ||
| I've heard that short(16 bit) or byte(8 bit) variables offer no speed advantages over int(32 bit). This is because most processors only take data in 32-bit chunks, right? Now I wonder, is this blitz-specific? For instance, in C, I'm pretty sure you can have four seperate variables processed in one 'pass' by a 32-bit processor if the variables are all 8-bit. Does anyone here know about this? I know there have been many times I wish I could declare smaller-capacity variables as a tradeoff for increased speed (up to 4x, theoretically). ie array1:byte[800,600] array2:int[800,600] Array1 should run 4x as fast through the processor. |
| ||
| You really shouldn't worry about this kind of thing. If you want your applications to perform better, messing around with variable types is not the way to go. The same goes for unrolling loops or using gotos and labels instead of functions. If my memory serves me correctly, all byte values are converted to 32bit integers before operations are performed on them, at least for x86 processors, so there would be a very small speed penalty for using bytes instead of ints. For all languages, choosing a better algorithm to perform a calculation and removing redundant calculations will always have a far greater effect than these minor changes. In the current version of BlitzMAX, using FlushMem in the right place will also make a big difference (although the next update should improve the memory management side of things). |
| ||
| I recently converted all the Bytes used in my project to Ints (where I could) and I got 3-4% increase in speed, with a similar increase in memory usage. I originally assumed using Bytes for any variable that would not be less than 0 or above 255 would be faster. |
| ||
| Hmm I see, Robert. I can't remember where I read this article, but I could swear that it said some C programmers designed their functions so that their variable sizes would add up to be multiples of 32 so that they were fed to the processor more efficiently. Am I mis-informed? |
| ||
| Processors are so darn fast these days the performance difference wouldn't be worth 1/100th the effort to change all the variables. I would assume having the variables multiples of 32 would probably decrease fragmentation in the processor pipeline a little, but its not really gonna make any difference. |
| ||
| It all depends on what you are doing. In C++ when doing per pixel operations any speed increase was welcome and making a routine work with int instead of long or float sometimes gave a massive performance increase. These days however we don't work at the per pixel level as a rule, so any speed gains tend to be minimal. I would just use the variable type that is enough to hold your data ( so as not to be wasteful of memory ) and concentrate on honing your algorithms for any required speed increase. Program it first and if it is fast enough all well and good, but if your routine is too slow only then consider optimisations. |
| ||
| I once optimised the variable usage of a processor intensive func and sucesffully changed 5000ms calc time to 7700 ms calc time. I call it the bizarro optimization. and I wouldn't reccomend trying it, whatever the arctile says. |
| ||
| I normally use bytes/shorts only for arrays and of course storing in disk. Maybe the speed penalty for one conversion byte->int is minor, but when you do that hundred times per sec, it's a lot of minor penalties you could avoid. I always choose speed prior to memory usage (with limits of course). |
| ||
| With 64 bit processing, I'm sure the same question will arise once again. They are valid points. |
| ||
| the best optimiser of code is often not the programmer but the compiler... |
| ||
| Bytes and shorts may actually be slower since they are not nessecarilly word aligned in memory (dunno if BlitzMAX pads them for you tho', I'm guessing not). |
| ||
| I can't remember where I read this article, but I could swear that it said some C programmers designed their functions so that their variable sizes would add up to be multiples of 32 so that they were fed to the processor more efficiently. I'd have to see the original article to be able to make any comment. All I will say is to re-state my earlier point that low-level optimisations should really be left to the compiler. |
| ||
| The best way to optimize your code is to pick the proper algorithms for the task at hand. The vast majority of the time, an inefficient algorithm is to blame for poor performance... |
| ||
| Robert, I read that article a long while ago, and I'm pretty sure it was on the internet, so it's probably gone. You all make good points. I dunno. I guess I was naively hoping there was some hidden method to programming that was rarely shared and taken advantage of. (Something that would make my water simulations go faster!) (these: ) http://www.blitzbasic.com/Community/posts.php?topic=52378 |
| ||
| There was an article series at CUJ (or was it DrDobbs?) some months ago from Michael Abrash about optimizations these days. He wrote about simple (easy to follow) realworld examples where a linear search was faster than a binary serach until the searchspace was 64 elements - this was just because mispredicted branches are dead slow compared to braindead linear number/memorycrunching. It's a pretty simple example why it depends very much on the situation, optimize an algorithm may be an option, optimize memorysize, memoryaccess, datatypes, whatever too - but the most important thing is - get used to profile your optimizations *and* understand what/why you optimize something in the way you do it. Just turn ints into bytes won't work - chances are high that as soon as you don't know why and in which situation one or the other may be faster you won't get it right. Finally keep in mind that most of your code doesn't need to be the most effective, hundrets, even thousands of simple operations aren't worth any effeorts if they only need 0.5% of your cpu time - double their speed will boost your app by only 0.25% - hardly worth anything. |
   |