Site
News
Files Visual Basic
Strings
Math
General
Properties
Memory
Methods Search
Testing Inline ASM-VB
Strings
Math
General
Memory Search
Using inline ASM
Submit!
News
Files Visual Basic
Strings
Math
General
Properties
Memory
Methods Search
Testing Inline ASM-VB
Strings
Math
General
Memory Search
Using inline ASM
Submit!
For…Next: Always use longsNever use anything else than longs in loops.
Longs are the fastest variable type in Visual Basic.
It's easy to explain why: They are 32bit, your processor is 32 bit, and every other type that isn't 32 bit needs to be converted to 32 bit (which takes time).
Okay, now I could have used integers for this test. Integers are slower than longs,
but just running an test between a long and integer, without anything between For...Next, will not really matter.
But in larger loops, you'll always see that the Long variable type will win in performance.
So that's why I decided to use a single. And you can see the difference between it, definetly.
I might add that I haven't used the normal test system for this test: 1 iteration, done 5 times.
But the long and single test both contained 100000 iterations, so it should be all right.
Code used:
User contributed notes:
Code: |
| Single % faster than Long | Single (sec) | Long (sec) |
| 957,1% | 0,004279 | 0,000405 |
| 741,1% | 0,003412 | 0,000406 |
| 741,1% | 0,003412 | 0,000406 |
| 748% | 0,003433 | 0,000405 |
| 741,3% | 0,003413 | 0,000406 |
User contributed notes:
| Author: Sr. Guapo () | Date: 02:06 17/06/2004 |
| Isn't a single 32 bit (in VB6)? I guess the decimal must effect it also, since VB must cast the single to a long every iteration... | |
| Author: Jamie AKA A5c11Char5et () | Date: 18:05 26/05/2005 |
|
I would think everybody knows that a single loop is slower than a long (32bit integer) loop. Maybe I'm wrong?!? Jamie AKA A5c11Char5et |
|
| Author: Tanner "DemonSpectre" Helland (www dot tannerhelland dot com) | Date: 06:06 03/06/2005 |
| I can't believe somebody believed that just because singles are 32-bit they'd be comparable to longs...but in case Sir Guapo's not alone, the simplest explanation is this: even though singles and longs are both 4-byte data types, their encoding is completely different. A function like 'long++' requires nothing more than a simple binary adder within the processor; 'single++', however, requires a whole crapload of binary work because of the mantissa and everything else. Integer data-types (as in whole number data-types) will always be faster for addition and subtraction than will fraction data-types. | |
| Author: Tom (hurendo_kun at hotmail dot com) | Date: 15:06 08/06/2005 |
| I believe the assumption is that you'll be coding for older CPU's that don't have highly optimized 32-bit FPU's. The performance difference between integral and floating-point operations on a modern CPU/FPU is negligible. (The fact that the two can work in tandem is food for thought.) | |
| Author: Tom (hurendo_kun at hotmail dot com) | Date: 15:06 08/06/2005 |
| I'm sorry, I meant to say 80-bit FPU's. | |
| Author: Alan () | Date: 20:06 10/06/2005 |
| I ran the exact same test as above on my Pentium processor (which are optimized for floating point). The long was faster; however, the single was only 50% slower than the long as opposed to the 750% suggested above. Integer data types will probably always dominate by some small fraction, but with increasing optimization, floating points will continue to get closer and closer until it really doesn't matter. | |
| Author: BYTE-Smasher () | Date: 14:08 05/08/2005 |
|
Oddly enough, when I used longs for all my loops, my framerate seemed to drop from 100fps to 50fps... it seems (on this system at least) that variant was actually preforming better than long. I even tried declaring the variables as variant to make sure, and sure enough, they were faster than longs. I'm not sure why this would be... it makes no sense to me whatsoever |
|
| Author: Tom (hurendo_kun at hotmail dot com) | Date: 04:09 23/09/2005 |
|
Hmm. Can we see your code? What operating system and service pack are you using? As for speed differences, I believe Almar was using an older chipset/OS combo for these tests. That's actually a good thing, because it really shows the difference, whereas on a modern system you won't even notice. |
|
| Author: Someone () | Date: 09:12 18/12/2005 |
|
Can we see a test from integer to longs? Maybe ints perform faster? (and thats what byte-smashers variant was cast to?) |
|
| Author: Tanner again (www dot tannerhelland dot com) | Date: 04:07 13/07/2006 |
|
I guess the point is that unless you absolutely have to, use Longs for loop variables. Hopefully there isn't a case where you'd need a single... I'd find it more interesting to compare long/integer math to single/double math. How does integer addition compare to floating point addition? Is there much of a difference? |
|
| Author: yup, Tanner again (www dot tannerhelland dot com) | Date: 05:07 13/07/2006 |
|
Interesting- I ran the above test on my AMD 2800+ (~1.6ghz) but upped the iterations from 100,000 to 10,000,000. Even at that size it was unable to clock the Long loop any more accurately than .000001 seconds, while the Single loop clocked in at 1.65 seconds on its fastest iteration. So if you're running an AMD processor, stick to Longs! Sheesh! |
|
| Author: TheShau (shauros at walla dot com) | Date: 14:08 04/08/2006 |
|
I think you're completely off here. The slow down is because you used a floating point number against an integer number. When I tried with an Integer against a Long it came out exactly the same as it should be. And no there is no slowdown when using 16 and 8 bit number on a 32 bit processor, non at all. You can check the clock tables in masm's help, or look for the manufacturer's documentation of the different processors. |
|
| Author: TheShau (shauros at walla dot com) | Date: 15:08 04/08/2006 |
|
I did some testing to proof this. I tested a double loop so the resaults would be clear: Public Sub TestOne() Dim I As Single, J As Single For I = -32768 To 32766 For J = -32768 To 32766 Next J Next I End Sub Public Sub TestTwo() Dim I As Long, J As Long For I = -32768 To 32766 For J = -32768 To 32766 Next J Next I End Sub Public Sub TestThree() Dim I As Integer, J As Integer For I = -32768 To 32766 For J = -32768 To 32766 Next J Next I End Sub These are the resaults: Single - 65.92578 seconds Long - 42.37891 seconds Integer - 42.70313 seconds The little difference beetween Long and Integer is probably coincidental but I didnt bother checking for such a small difference. |
|
| Author: Almar () | Date: 18:08 04/08/2006 |
| This test is just to show the difference, it'd be really silly to use singls for loops unless you'd really need them! | |
| Author: TheShau (shauros at walla dot com) | Date: 23:08 04/08/2006 |
|
The description states: They are 32bit, your processor is 32 bit, and every other type that isn't 32 bit needs to be converted to 32 bit (which takes time). My point is thats just not true, the slowness above is due to comparing floating point against integer numbers, loops with integers and bytes aren't slower then loops with longs. And if they are, although tests show they arent, then it's strictly a VB limitation and not an issue with 32 bit processors, or 64 for that matter. Like you said no one in their right mind would use a floating point variable when only integers are needed. I've done tests with bytes, integers and longs, and any differences in execution times are random and go both ways. As a side note there are floating point formats that allow for the same efficiency as integers, for example half and half numbers, but those cannot be properly implemented in VB. |
|
| Author: Tanner Helland (tannerhelland at hotmail dot com) | Date: 00:08 05/08/2006 |
|
Boy, some people take this seriously :p Figured I'd update this one more time, with information from tests on my computer running Integer loops vs. Long loops. Test1 is the Integer loop, Test2 is the Long loop. Both tests are triple-layered loops from -32768 to +32767, each test iterated 50,000 times. (Compiled to native code, since VBIDE is inconsistent at best.) -------------------------------------------------- % faster 0.9|24.9|24.9|24.9|24.9 Test1|0.000253|0.000313|0.000313|0.000313|0.000313 Test2|0.000251|0.000251|0.000251|0.000251|0.000251 -------------------------------------------------- % faster 1|10.7|24.9|24.8|24.9 Test1|0.000253|0.000313|0.000313|0.000313|0.000313 Test2|0.000251|0.000283|0.000251|0.000251|0.000251 -------------------------------------------------- % faster 0.8|25.1|24.9|25.1|24.9 Test1|0.000253|0.000314|0.000313|0.000313|0.000313 Test2|0.000251|0.000251|0.000251|0.000251|0.000251 -------------------------------------------------- % faster 0.8|24.9|24.8|24.9|24.8 Test1|0.000253|0.000313|0.000313|0.000313|0.000313 Test2|0.000251|0.000251|0.000251|0.000251|0.000251 -------------------------------------------------- No difference, eh? My AMD processor seems to say otherwise - and the results are surprisingly consistent. Seems that Longs are about 25% faster than Integers. |
|
| Author: TheShau (shauros at walla dot com) | Date: 17:08 05/08/2006 |
|
I've tried again and again and the only way I managed to replicate your resaults is when choosing "No Optimization". I also tested different loops in assembly, with varrying 16 bit and 32 bit sizes. I tested loops with counters in the form of registers, memory variables and local variables, which as far as I understand are defined on the stack. I also tested different loop structures and it always always comes out the same. And yes I take this specific efficiency trick seriously because almost every program has lots of loops, few of which need the range of a long variable and if they are faster this can have a significant effect in some of the programs I'm working on and practicularly in graphic operations. If you could perhaps mail me some of the projects that produce this resaults, because I would very much like to know how you managed to speed up the code. And sorry about spamming the message board a bit :\ |
|
| Author: Tanner Helland (tannerhelland at hotmail dot com) | Date: 23:08 23/08/2006 |
|
The exact code is described in my above post - I'm sure you can recreate it. The project was compiled to native code with all optimizations checked. 'Favor Pentium Pro' was NOT checked. And I'm not saying whether or not these results are typical - for my machine (on an AMD processor, again) they were surprisingly consistent, though. |
|
| Author: francis (flightline at airtelbroadband dot in) | Date: 04:12 29/12/2006 |
|
I find integers run fastest! at no stage have I been able to repeat your examples and obtain faster results with longs What could I be doing wrong? Regards Francis |
|