Which Endian routine is better?
in [Visual Basic]
|
Prev: VB 6 & VS?
Next: C:\WINDOWS\system32\ieframe.dll\1
From: Donald Lessau on 19 Mar 2010 03:56 "Karl E. Peterson" <karl(a)exmvps.org> schrieb im Newsbeitrag news:OFif0pvxKHA.812(a)TK2MSFTNGP06.phx.gbl... > > ... > I expected that the native code results would be fastest. In no way did I > expect them to be immeasurable! Thoughts? > Please read the first three points near the top of the page under "It's tricky to set up a speed test for ForNext loops:" here: http://www.xbeat.net/vbspeed/c_ForNext.htm Sounds similar to what you experienced now. Don
From: dpb on 19 Mar 2010 11:00 Donald Lessau wrote: > "Karl E. Peterson" <karl(a)exmvps.org> schrieb im Newsbeitrag > news:OFif0pvxKHA.812(a)TK2MSFTNGP06.phx.gbl... >> >> ... >> I expected that the native code results would be fastest. In no way >> did I expect them to be immeasurable! Thoughts? >> > > Please read the first three points near the top of the page under "It's > tricky to set up a speed test for ForNext loops:" here: > http://www.xbeat.net/vbspeed/c_ForNext.htm > > Sounds similar to what you experienced now. Dug into the results of the optimizer for some conditions similar, indeed. Interesting to know this one is tied in w/ the integer overflow flag as the only interaction of the user w/ the compiler. I don't interpret the results as _necessarily_ being that much related to the specific overflow check itself as in that only that if it is requested the optimizer doesn't get rid of the integer that's asked to be checked. The conclusions on the branching are probably also a little too simplistic as well altho certainly branch prediction is going on. W/ modern CPUs the cache size and hit/miss can make so much difference in timing that is outside the actual compiler optimization effects that it can mask what is what unless one actually looks at that as well. These kinds of optimization issues have been pushed in Fortran compilers harder and earlier than in most C compilers owing in large part to the concentration of Fortran in compute-bound applications and the features of the language syntax intended to promote the ability to optimize whereas C code tends to have areas that inhibit the ability to optimize as much owing to the compiler having less it can be sure of as to effects of possible optimizations. Some of these differences have been reduced in the later C Standards and C++ and as compiler optimization technology has improved. The end result, those of us w/ extensive Fortran experience are not at all surprised by the results here and tend to, in fact, expect such things fairly routinely... :) I'd never looked at the actual optimization in VB5/6 to any extent as I've always used Fortran extensively w/ VB and essentially VB was the front end to the compute engine except for places where the overall complexity/time wasn't large enough to need to worry about speed inside VB. IOW, if I wanted/needed better performance, I've simply written that part in Fortran and called it from VB for the entire time 32-bit VB has existed. :) --
From: Karl E. Peterson on 19 Mar 2010 12:44 Tony Toews [MVP] wrote: > Karl E. Peterson <karl(a)exmvps.org> wrote: > >> System is ... 10MB RAM > > You're showing your age. Errr, experience, yeah that's it experience. Arrrgh! :-) -- ..NET: It's About Trust! http://vfred.mvps.org
From: Karl E. Peterson on 19 Mar 2010 12:48 Donald Lessau wrote: > "Karl E. Peterson" <karl(a)exmvps.org> schrieb... >> >> ... >> I expected that the native code results would be fastest. In no way did I >> expect them to be immeasurable! Thoughts? >> > > Please read the first three points near the top of the page under "It's > tricky to set up a speed test for ForNext loops:" here: > http://www.xbeat.net/vbspeed/c_ForNext.htm > > Sounds similar to what you experienced now. Good use of the Clue Stick, thanks... :-) -- ..NET: It's About Trust! http://vfred.mvps.org
From: Mike Williams on 19 Mar 2010 17:04
"Karl E. Peterson" <karl(a)exmvps.org> wrote in message news:euXhNN4xKHA.2552(a)TK2MSFTNGP04.phx.gbl... >> Mike Williams wrote: >> The fact that your own results at first sight appear to indicate >> that the t(0) block is no longer being optimized out . . . > > We may be interpreting things differently? To me, t(0) > -- the empty loop -- wasn't optimized out at all. It took > a measurable duration. erm . . . that's what I said! One nice thing to note here though is the suggestion at the link posted Donald Lessau of placing If fFoo Then lFoo = lFoo + 1 in the test loop to prevent the For Next loop itself being totally optimised out without needing to remove the "No Integer Overflow Checks" optimization if that's what suits any specific test. >> My initial thoughts are that there may be a small problem >> with the initialisation of the cStopWatch Class, and that >> perhaps the very first reading it returns is for some reason >> invalid or not quite correct? That seems unlikely though >> knowing that your cStopWatch Class has beein in use . . > > It's been downloaded many, many 10s of 1000s of times > and no one's ever suggested there was a problem before. I did say it was unlikely, and I did also say that being written by you it was certainly built using very high quality code, but I don't recall ever using it myself and on the assumption that it was based on timeGetTime I just wanted to rule out the possibility that it might be returning an erroneous result on its first use on the grounds that I know the first set of timed results immediately after calling timeBeginPeriod can evaluate to zero if you don't initially wait the appropriate period after first using timeBeginPeriod, so that for a series of timings on the same block of code its is possible to get results like 0, 13,13,12,13,etc. I know that the actual timings were not in that range of course, but I was clutching at straws and I just wanted to cover all the bases. Unfortunately, that straw broke, as I half expected it to! (Now I'm really in trouble. In my other posts I've been typing Z's all over the place instead of S's and in this one I'm saying things like "cover all the bases" . . . and I'm putting apostrophes where they don't belong. I really do think I might be turning into a Yank <g>). > But really, the code is very similar to yours, except that the > Reset method waits for a timer tick before returning, in an > attempt to halve the margin of error. (Aw heck, I'll just > paste a copy below, so you won't have to click a link. > Cool? <g>) Thanks Karl. I'll hang onto that one. >> Are you perhaps using a few different projects in your tests >> and have you by any chance failed to tick the "Remove Integer >> Overflow Checks" optimization in the project that produced >> the above results? In fact, to my mind that is the most likely >> cause of the change of behaviour, far more likely than a problem >> with your timer initialization. > > Oh he11. Y'know, a guy can really *try* to be thorough, and then > ... <sigh> Yes, you nailed it. I was definitely toggling stuff all over > the place, trying to find where it fell down. And obviously took > more than a single step at a time, at some point ... :-| See . . I told you I wasn't really blaming your timer Class, Karl <g>. The first straw I clutched at broke, but the second one saved me ;-) Mike |