|
Usually, the steroid injected, genetically altered bananas do the magic. But yes, sometimes they need a superbike.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
I did test about this before:
pointer increasing is faster than index increasing.
i.g.
WORD*p0=...;
WORD*p1=...;
this code is faster:
for(i=0;i<1000;i++)
{
*p0=*p1;
p0++;
p1++;
}
than:
for(i=0;i<1000;i++)
{
p0[i]=p1[i];
}
|
|
|
|
|
thanks, i'll try something similar to this. cheers for helpful comments.
|
|
|
|
|
such timing experiments are tricky. Here are some things to consider:
- compiler settings, including debug vs release
- timer inaccuracies; make sure to have a timer with good accuracy
- cache effects; when testing several alternatives, the first will often loose because the data hasn't been cached yet.
etc.
Luc Pattyn [Forum Guidelines] [My Articles]
The quality and detail of your question reflects on the effectiveness of the help you are likely to get.
Show formatted code inside PRE tags, and give clear symptoms when describing a problem.
|
|
|
|
|
memcpy is generally fastest. I've found several places where VS2008 (at least) optimized a loop like above into a memcpy.
|
|
|
|
|
I chose a few memory copying functions and did a profiling, and I see memcpy is the fastest (VS 2008). I haven't gone to the extent to see what the compiler has optimized it out into; I only did profiling, several times. memcpy was slightly faster on an average.
Also, a modern compiler must be able to optimize your code out to something that's fastest, unless of course you write some deliberate bad code.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Many compilers (including MS C++) support intrinsic function calls which are inlined during the compile phase. This includes calls to memcpy, memcmp, memset, strcpy, acos, asin and more. If you have not already enabled intrinsic functions you might wanna give it a try.
For more information on intrinsic functions click --> here <--
1300 calories of pure beef goodness can't be wrong!
|
|
|
|
|
I knew of intrinsic functions, but I hadn't known that memcpy was amongst the list of functions that the MS C++ compiler has intrinsic versions of.
Thanks.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
memcpy will be faster, in general.
and if you want to get crazy, an SSE/MMX version of memcpy can be even faster.
|
|
|
|
|
Here is info copied from google search:
============================
FILETIME
Introduction It shows elapsed time from 00:00:00 on Jan 1, 1601. It is expressed per 100 nano-seconds.
conversion fomula from FILETIME to time_t is
( FILETIME - 0x19DB1DED53E8000 ) / 10000000;
Recordable range from : 00:00:00 on Jan 1, 01601 ( 00000000 : 00000000 )
to : 14:36:10 on Mar 28, 60056 ( FFFFFFFF : FFFFFFFF )
=============================
from info above, unit in FILETIME is 100 nano-seconds, or 10^(-4) millisecond.
Is my understanding about FILETIME unit correct?
If yes, how do we generate a so small time value for the unit?
|
|
|
|
|
Reported info is correct, see [^].
includeh10 wrote: from info above, unit in FILETIME is 100 nano-seconds, or 10^(-4) millisecond.
Is my understanding about FILETIME unit correct?
If you're curious about, try to call the QueryPerformanceFrequency [^] function on your system.
Anyway, I guess the system (HW+OS ) is allowed to be less accurate than the .1 microsec interval specified by the FILETIME struct. For instance suppose the system being accurate just up to 1 millisecond interval, still the FILETIME struct info is valid (you'll get always 4 zeroes at the end).
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
Yes, the units are 100ns. So, to convert a FILETIME to seconds, multiply by 10,000,000.
includeh10 wrote: If yes, how do we generate a so small time value for the unit?
? You don't. That's the point - the units of FILETIME are small enough that 1 FILETIME is smaller than just about any time you'll ever want to express.
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: That's the point - the units of FILETIME are small enough that 1 FILETIME is smaller than just about any time you'll ever want to express.
Not valid for me: I reach almost the light speed on my GSR...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
CPallini wrote: Not valid for me: I reach almost the light speed on my GSR
Is too valid! - c = 30m/FILETIME!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: Is too valid! - c = 30m/FILETIME!
Yes, but we've quite different FILETIME s for the same file...
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
The Lorentz transformation[^]? In that case, the file size will change as well.
Travelling at the speed of light is probably the only way for Vista not to be a bloated pig
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: Travelling at the speed of light is probably the only way for Vista not to be a bloated pig
Unfortunately mass-energy equivalence theorem states that "As the object approaches the speed of light, the relativistic mass becomes infinite..."
Therefore, I think that Vista can already travel at the speed of light, and "not" being a bloated pig idea is beyond all hopes.
...If you get the drift of what I'm codswalloping about.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
But it's linear sizes would reduce to be infinitesimally small, so Vista would be tiny (in volume).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
My head asplode, sir.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Too much Vista - take a Weven pill and all will be well with you!
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Actually yes. Scraped Vista off my home PC (running the 7 pill now) I'm a happy man. I work with XP at office, and there's no trace of Vista, any more in my life. Happy man, me.
Did I mention that I'm a happy man?
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
Whereas soon I'm going to start using Vista for the first time I have two PCs on my desk @ work. One's my 'corporate network' PC...that I use for e-mail and....well, e-mail really. That currently runs Windows 2000 (yep, you read that right) like the thousands of other employees here. We got an e-mail yesterday basically saying that over the next 3-6 months, Vista and Office 2007 would be rolled out to our PC estate. I have to say I'm really looking forward to using Vista on a poxy old Pentium 4 PC with 1GB of RAM. My co-worker, with a 2.2GHz Celeron and 512MB of RAM is looking forward to it even more
My second PC @ work currently runs XP. If I could be bothered, I'd upgrade to Weven. But it works, so I probably won't...for a while. Got a Weven VM, though.
At home, it's OS X all the way, apart from my Weven VM that I use to run Visual Studio (and Office on the rare occasion that iWork isn't enough for working with Office docs).
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
Stuart Dootson wrote: My co-worker, with a 2.2GHz Celeron and 512MB of RAM is looking forward to it even more
Good luck with your new endeavour. It's going to be one hell of a ride.
It is a crappy thing, but it's life -^ Carlo Pallini
|
|
|
|
|
I'm thinking of a little wager on how far through the boot process it gets before the machine gives up under the strain of the unfair challenge
Java, Basic, who cares - it's all a bunch of tree-hugging hippy cr*p
|
|
|
|
|
I am implementing MODBUS protocol. I want to try my C/C++ program between serial port and USB port on single PC before executing code in microcontrollers. Please give me some hint!!!
|
|
|
|