Which Endian routine is better?
in [Visual Basic]
|
Prev: VB 6 & VS?
Next: C:\WINDOWS\system32\ieframe.dll\1
From: Nobody on 19 Mar 2010 20:40 "Mike Williams" <Mike(a)WhiskyAndCoke.com> wrote in message news:eRc%236e6xKHA.4492(a)TK2MSFTNGP05.phx.gbl... > "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. VB6+SP5 doesn't optimize empty loops out according to assembly output, and also to the fact that in your and Karl's tests an empty loop takes 86+ ms. If VB optimized the loop out, you would get 0 or 1 ms. See the assembly output in my post in this thread. In case it didn't make it to the newsgroups, here is Google's version: http://groups.google.com/group/microsoft.public.vb.general.discussion/msg/1688a4a428ed12d7 It shows that in case of t(0), VB6 assembly output is the same whether all optimizations are enabled, or using the default. In both cases, VB6 didn't remove the empty loop. In case of t(1), with all optimizations enabled, VB6 assembly output shows that what's inside the loop was optimized out, but not the loop itself. This produced the same output as an empty loop. This explains why t(0) = t(1) when all optimizations are enabled. In case of using the default optimization settings, what's inside the loop in t(1) gets compiled. In case of t(1), with all optimizations enabled, moving the resultant variable "wd" from a local to a modal level variable forces VB to compile what's inside the loop.
From: Mike Williams on 20 Mar 2010 08:44 "Nobody" <nobody(a)nobody.com> wrote in message news:OfYP4X8xKHA.5132(a)TK2MSFTNGP05.phx.gbl... > VB6+SP5 doesn't optimize empty loops out according to > assembly output, and also to the fact that in your and Karl's > tests an empty loop takes 86+ ms. If VB optimized the loop > out, you would get 0 or 1 ms. Yeah, you're quite right. By the time I was getting to the last few message in that thread my brain was getting really addled, and of course I had all that worry about constant exposure to the newsgroup turning me into a Yank, and so I ended up not quite knowing what was doing! I'm starting to feel much better now that I've had a rest <g> Mike
From: Karl E. Peterson on 23 Mar 2010 20:39
Mike Williams wrote: > "Karl E. Peterson" <karl(a)exmvps.org> wrote... >>> Mike Williams wrote: > 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>). LOL! Hope for you yet... <gd&r> >> 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. Stick it in your templates\classes folder. ;-) >>> 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 ;-) I'm the screw-up here. Much as I'd like to look askance at others... I can certainly see why you'd suggest the range of possibilities you did. No sweat. :-) -- ..NET: It's About Trust! http://vfred.mvps.org |