Recent Articles
Handling a Subversion Repository URL Change
Sunday, May 3, 2009
If your repository URL changes, you can use the following command to fix existing snapshots.
vfat Mounts Default to Lowercase Shortnames
Tuesday, April 21, 2009
I want a "this is brain-damage" quote from Linus for this mess.
VirtualBox or VMWare Virtual Machine at Login
Sunday, April 12, 2009
How to start a virtual machine in X when a user logs in.
Dialog Progress Bar Through Pipe
Sunday, April 12, 2009
How to use dialog to display a script progress bar and communicate progress to it through a named pipe.
Ottawa Linux Symposium 2008
Sunday, July 27, 2008
Here are some pictures from the 2008 Linux Symposium.
Clay Shirky: Institutions vs. collaboration
Monday, July 14, 2008
This is a rather interesting talk that takes some very foundational ideas from open source software development, P2P networks, and social networking and implies that these paradigms can apply to a lot more.
Who's General Failure and why's he reading my disk?
Projects
Development...Where...
Just a little example that shows the time differences between post and pre-increment on STL iterators. If you understand how they work, it's exactly as expected.
Compile with:
Results in:
Pipes on Linux and Win32
Coroutines in C
C/C++ Guide
Using CVS
Getting Started with Automake and Autoconf
General Programming Info
Nullsoft Installer
Development...Where...Where Preincrement is Faster than Postincrement
Tuesday, September 19, 2006 by digitalpeer
/*
* Times the difference between using ++i and i++ on iterators in a loop.
*/
#include <iostream>
#include <vector>
#include <sys/time.h>
using namespace std;
struct timespec s;
inline void start()
{
(void)clock_gettime(CLOCK_REALTIME,&s);
}
inline void stop()
{
struct timespec now;
(void)clock_gettime(CLOCK_REALTIME,&now);
unsigned int diff = (unsigned int)((double)(now.tv_sec-s.tv_sec) * 1000.0) +
(unsigned int)((double)(now.tv_nsec-s.tv_nsec) / 1000000.0);
cout << diff << "ms" << endl;
}
int main()
{
vector<int> v;
for (unsigned int x = 0; x < 1000000;x++)
{
v.push_back(x);
}
{
start();
for (vector<int>::iterator i = v.begin(); i != v.end();++i)
{
(*i)++;
}
stop();
}
{
start();
for (vector<int>::iterator i = v.begin(); i != v.end();i++)
{
(*i)--;
}
stop();
}
return 0;
}
Compile with:
$ g++ itertest.cpp -lrt
Results in:
$ ./a.out 28ms 36ms $ ./a.out 28ms 38ms $ ./a.out 28ms 37ms $ ./a.out 28ms 41ms
Related Local Pages
Wrapping C/C++ Function DefinitionsPipes on Linux and Win32
Coroutines in C
C/C++ Guide
Using CVS
Getting Started with Automake and Autoconf
General Programming Info
Nullsoft Installer
Comment Tuesday, March 20, 2007 by
anonymous
You can't measure performance on unoptiimzed code; your test case is meaningless. Any reasonable compiler will optimize away your entire program. You must write a loop that does minimal but necessary work and re-test your timings on optimized code.
Comment Tuesday, November 4, 2008 by
Emil Wojak
The fact that it's unoptimized is irrelevant, when trying to prove, that preincrement is faster. I agree, that the compiler might optimize out copying the iterator when the value returned from postincrement operator is not used. This would make both increments at most equally fast. However, it is not a good practice to rely thoroughly on the optimizer and writing filthy code. Not always will the compiler be that smart, and using preincrement even on simple types develops good habits and makes your program independent of optimizer lottery.
Comment Tuesday, November 3, 2009 by
anonymous
"The fact that it's unoptimized is irrelevant, when trying to prove, that preincrement is faster"
Well, If preincrement is NEVER faster in optimized code, I would find this observation pretty relevant don't you think?
I do not agree with your perspective AT ALL. Nothing is worse than code which is hard to read because some douchebag obfuscates it with trivial optimizations that the compiler does anyway, like. using ">> 1" instead of "/ 2". My view is quite the opposite - rely on the optimizer as much as possible and keep the code clean and easy to read and maintain. And yes, in my opinion, "++i" makes the code a bit harder to read because it pops out as unusual.
Well, If preincrement is NEVER faster in optimized code, I would find this observation pretty relevant don't you think?
I do not agree with your perspective AT ALL. Nothing is worse than code which is hard to read because some douchebag obfuscates it with trivial optimizations that the compiler does anyway, like. using ">> 1" instead of "/ 2". My view is quite the opposite - rely on the optimizer as much as possible and keep the code clean and easy to read and maintain. And yes, in my opinion, "++i" makes the code a bit harder to read because it pops out as unusual.
Comment Wednesday, November 4, 2009 by
anonymous
This example is an exercise in understanding why this happens, which Emil understands. Preincrement is sometimes faster, even in optimized code. It all boils down to making a copy being more expensive than not. There is something to be said about maintaining readability and avoiding being cute, but the use of preincrement does not fall under either of those. A trivial optimization like this can make a huge impact. Preincrement isn't the only alternative to optimizing out a costly postincrement operation, but it doesn't matter if you don't understand the problem. My perspective is an optimizer won't fix ignorance.
Comment Tuesday, November 10, 2009 by
anonymous
My perspective is an optimizer won't fix ignorance. Well said.
