Interesting Article for using Boost for Remote Call Framework
Hi An interesting article on using boost for remote call framework. http://www.codeproject.com/threads/RMI_For_Cpp.asp Rgds Rajeev
"Mottengte, Rajeev Kumar" <Rajeev.Mottengte@ipc.com> wrote in message news:1D6EDDB3E43F3B40BC089CCFEE99DB7D01855D92@exnanycmbx1.corp.root.ipc.com...
Hi
An interesting article on using boost for remote call framework.
Interesting indeed. The author claims that boost.serialization is 5 times slower than some of his other libs. Is that a know problem with boost.serialization or is the claim wrong? -Thorsten
I did notice this article and took note of the claim. This is a very interesting topic to me and one that merits a "science project". I invested much effort in making sure code was generated at compile time whenever possible so I would be disappointed at such a result. My past experience in this area is that one really has to undertake a serious effort to gather this kind of data. I've been through before with my sort program (www.rrsd.com) and now believe that there is no short cut in this area. Anecdotal information is usually very misleading. I would guess there is likely a few areas where performance is getting bogged down. I might suspect the stl used in object tracking. However, in the past, whenever I really looked at these questions with a good statistical profiler, I've always found that bottle necks in places where I never would have suspected. So, this is an interesting area which needs a serious look. Robert Ramey
"Robert Ramey" <ramey@rrsd.com> wrote in message news:ddj03f$mcc$1@sea.gmane.org...
I did notice this article and took note of the claim.
This is a very interesting topic to me and one that merits a "science project". I invested much effort in making sure code was generated at compile time whenever possible so I would be disappointed at such a result.
My past experience in this area is that one really has to undertake a serious effort to gather this kind of data. I've been through before with my sort program (www.rrsd.com) and now believe that there is no short cut in this area. Anecdotal information is usually very misleading. I would guess there is likely a few areas where performance is getting bogged down. I might suspect the stl used in object tracking. However, in the past, whenever I really looked at these questions with a good statistical profiler, I've always found that bottle necks in places where I never would have suspected.
So, this is an interesting area which needs a serious look.
I haven't read the article, but, IIRC there was discussion elsewhere concerning the overhead involved in reconstructing the xxx_(i|o)archive for similar message passing applications. Could this be the issue here as well? Jeff Flinn
There wasn't really enough data to pin anything down. Its going to take a significant effort to gather such data. Which raises an intereing question: Boost has a strong infrastructure for testing library correctness. This infrastructure permits comparison of libraries accross different environments. If someone had nothing else to do, it would be interesting to develop a parallel infrastructure for testing performance. questions are regularly posted to the list regarding performance of all the libraries. Usually, any data is largely anecdotal. To really address these questions, something more is needed. Robert Ramey Jeff Flinn wrote:
"Robert Ramey" <ramey@rrsd.com> wrote in message news:ddj03f$mcc$1@sea.gmane.org...
I did notice this article and took note of the claim.
This is a very interesting topic to me and one that merits a "science project". I invested much effort in making sure code was generated at compile time whenever possible so I would be disappointed at such a result.
My past experience in this area is that one really has to undertake a serious effort to gather this kind of data. I've been through before with my sort program (www.rrsd.com) and now believe that there is no short cut in this area. Anecdotal information is usually very misleading. I would guess there is likely a few areas where performance is getting bogged down. I might suspect the stl used in object tracking. However, in the past, whenever I really looked at these questions with a good statistical profiler, I've always found that bottle necks in places where I never would have suspected.
So, this is an interesting area which needs a serious look.
I haven't read the article, but, IIRC there was discussion elsewhere concerning the overhead involved in reconstructing the xxx_(i|o)archive for similar message passing applications. Could this be the issue here as well? Jeff Flinn
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
"Robert Ramey" <ramey@rrsd.com> writes:
There wasn't really enough data to pin anything down. Its going to take a significant effort to gather such data. Which raises an intereing question:
Boost has a strong infrastructure for testing library correctness. This infrastructure permits comparison of libraries accross different environments.
If someone had nothing else to do, it would be interesting to develop a parallel infrastructure for testing performance.
questions are regularly posted to the list regarding performance of all the libraries. Usually, any data is largely anecdotal. To really address these questions, something more is needed.
Not long ago I built the raw facilities into bjam that are needed for measuring the execution time of any build step (including one that runs programs). I need to do performance testing for the MTL rewrite, so I'll be using that. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Thorsten Ottosen <nesotto <at> cs.aau.dk> writes:
"Mottengte, Rajeev Kumar" <Rajeev.Mottengte <at> ipc.com> wrote in message news:1D6EDDB3E43F3B40BC089CCFEE99DB7D01855D92 <at> exnanycmbx1.corp.root.ipc.
com...
Hi
An interesting article on using boost for remote call framework.
Interesting indeed.
The author claims that boost.serialization is 5 times slower than some of his other libs. Is that a know problem with boost.serialization or is the claim wrong?
-Thorsten
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Hi, What I meant was that the total performance of my framework, measured in messages passed per second, was around 5 times slower when using Boost. Serialization, than when using a similar serialization framework that I developed myself.
From the profiling I did I'm pretty sure that the performance problems had to do with the construction/destruction of the archive classes, and probably had nothing to do with the actual serialization.
The tests I ran were remote method invocations over a loopback TCP connection, to a thread in the same process. Each invocation involves creating 4 archive objects (passing args in and out on both client and server ends), and with Boost.Serialization I couldn't get beyond 1000 invocations/sec, while getting almost 5000 when using my own serialization framework. Jarl.
As I said before, I am interested in these results. And I suspect a few culprits. But without output from a profiler its very hard to know where the slowness is. My past experience in this area leads me to suspect that one slow part of a program sucks up a way disproptionate amount of CPU time. Often the first couple of small changes will double or triple performance. I would be surprised if just setting up an archive is a long process - but who knows. I'm also wondering about how much compilers really inline code. This is a key variable re performance of templated code like this and I'm sure its hard to pin down. Worse yet, I'm betting it varies all over the place for different compilers. Robert Ramey
Robert Ramey <ramey <at> rrsd.com> writes:
I'm also wondering about how much compilers really inline code. This is a key variable re performance of templated code like this and I'm sure its hard to pin down. Worse yet, I'm betting it varies all over the place for different compilers.
No kidding, for templated, inlined code like RCF, I've found huge differences in performance just by compiling the same program with a different compiler. Modern versions of Visual C++ and CodeWarrior come out the best, while gcc (3.x) is a real slowpoke, producing code that is both fat and slow. Hopefully with successive compiler releases those differences will fade, but who knows. Jarl.
From the profiling I did I'm pretty sure that the performance problems had to do with the construction/destruction of the archive classes, and probably had nothing to do with the actual serialization.
The tests I ran were remote method invocations over a loopback TCP connection, to a thread in the same process. Each invocation involves creating 4 archive objects (passing args in and out on both client and server ends), and with Boost.Serialization I couldn't get beyond 1000 invocations/sec, while getting almost 5000 when using my own serialization framework.
Just a naive question: Can the archive objects be recycled? If there is any memory allocation in during archive construction (or if they were constructed on the heap), then that will likely dwarf all other factors. Just a quick 2c worth, John.
At 11:15 AM +0100 8/13/05, John Maddock wrote:
From the profiling I did I'm pretty sure that the performance problems had to do with the construction/destruction of the archive classes, and probably had nothing to do with the actual serialization.
Just a naive question: Can the archive objects be recycled?
There was some discussion of this in late July, subject "Boost.Serialization archive constructor performance". A brief summary of that thread: I encountered similar issues with archive construction significantly impacting throughput. I patched the source to allow archive reuse, and did indeed find that it had a significant impact. But it is not clear where the time is actually going. My first thought was that the construction of some archive members which are STL containers was using up lots of time, but examining those constructors in detail didn't seem to support this. That's as far as I got before putting the examination aside temporarily. When I return from vacation I'm planning to look into this more carefully, unless somebody beats me to it.
Kim Barrett wrote:
There was some discussion of this in late July, subject "Boost.Serialization archive constructor performance". A brief summary of that thread:
I encountered similar issues with archive construction significantly impacting throughput. I patched the source to allow archive reuse, and did indeed find that it had a significant impact. But it is not clear where the time is actually going. My first thought was that the construction of some archive members which are STL containers was using up lots of time, but examining those constructors in detail didn't seem to support this. I've managed to pinpoint the bottleneck: it's containers reallocations of dynamic storage. Each time serialization is performed at least one dynamic memory allocation for each container is neccessary.
If containers are reused then these allocations are performed only once, because STL containers don't deallocate underlying storage in their clear/reset/... methods. -- With respect, Alex Besogonov (cyberax@elewise.com)
Alex Besogonov <cyberax@elewise.com> writes:
If containers are reused then these allocations are performed only once, because STL containers don't deallocate underlying storage in their clear/reset/... methods.
I think that is only guaranteed to apply to vector. On some implementations it applies to other containers as well. -- Dave Abrahams Boost Consulting www.boost-consulting.com
participants (9)
-
Alex Besogonov -
David Abrahams -
Jarl Lindrud -
Jeff Flinn -
John Maddock -
Kim Barrett -
Mottengte, Rajeev Kumar -
Robert Ramey -
Thorsten Ottosen