Depending on the application and what else is going-on, PBO could boost by 10% or more. IIRC, it requires a "clean" termination of the application to get the flow.data file written.
There are some writeups on improving BIND performance:
ftp://ftp.cup.hp.com/dist/networking/briefs/that while not directly applicable, the methodologies may apply. In this day and age, the references to puma and its profiles should be replaced with something like prospect -
http://www.hp.com/go/prospectHigh sched_yield() could indeed be poor thread synchronization design - it could also mean some non-trivial mutex contention. By default the pthread_mutex_lock call will "spin" for a short time while trying to acquire a lock (the spinning being cheaper than a full sleep/wakup path. If the trhead is making several sched_yield() calls in a row just pior to calling ksleep() in a tusc trace (remember to use the -l option to display lwpids !-) (or you notice something like a 5 or 7 to one ratio between kspeep and sched_yield in glance) it suggests lock contention. You will then later see some other thread calling kwakeup() with similar arguments to the ksleep() call. One of those is the address of the mutex, which you could use to track-down the mutexes with contention. One of these days we'll have to get a mutex lock contention tool out there to the world at large...
IIRC, default for the compiler is to compile for the architecture (eg PA2.0) on which the compile takes place. The "best" way to ask for 64-bit these days is to use +DD64 - that way you will have one less thing to remember when you migrate to IPF.
Another possibly useful tool would be pi (
ftp://ftp.cup.hp.com/dist/networking/tools/) which can be used to display things like tlbmiss rates and cache miss rates and the like. If you see more than a fraction of a percent in handling tlbmisses then you may want to chatr your binary for a larger page size (see the chatr manpage)
You can probably also notice an increase in cache misses when you go to 64-bit from 32-bit, reflecting the increased size of pointers, and so the use of a larger number of cache lines. Some of that can be mitigated if you make sure your structures are layed-out well for 64 bit and don't leave unused holes. Typically, that means putting the pointers and longs (8 byte quantities in 64-bit) first, then the ints, then the shorts etc. If you put say the ints first, and only have three ints in the struct, followed by a pointer, there will be a four-byte "hole" between the third int and the pointer - longs and pointers in LP64 have to be on an eight byte boundary, and IIRC, structs get aligned on the most restrictive alignment of their members.
As for sockets performance, you can check that independent of your application by using netperf -
http://www.netperf.org/ and compare across your platforms.
Also keep in mind to compare the "raw" horsepower of all the systems you are using. If you don't do much floating point, you might normalize your results to SPECint2000. PA2.0 systems can run the gamut from anchient and slow 160 MHz boxes to current generation 875 MHz systems.
And as aways, those suggestions to be up on the latest patches - especially the ones talking about thread performance - is goodness.
there is no rest for the wicked yet the virtuous have no pillows
