Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!


Click here to return to the 'Install an optimized BIND 9.2.3Beta' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
Install an optimized BIND 9.2.3Beta
Authored by: Arakageeta on May 14, '04 10:50:09PM

By the way, there's a good chance that multi-threading will boost performance on single processor machines too.

Say you have 100 units of computing to do and each unit must be done in order, then a single threaded app will likely perform the task faster than a multi-threaded app since mult-threaded apps have a certain amount of overhead attached to thread management. However, if the units of computing can be broken into smaller blocks, one thread can handle each block and all blocks can be processed at once.

So what's the big deal if you only have one processor? All computation has to go through one processor, right? So what are the gains?

Consider this general case. Of your 100 blocks, 10 required disk accesses. Disk accesses are biggest bottle-neck to computing today. In a single threaded app, we have to wait for each disk access before moving onto the next units-- THIS ADDS UP! Why wait when there is other code that can be executed? Say that the 100 units can be broken into 10 units of 10 each containing a single disk access. When one thread blocks (jargon for when a thread must stop while waiting for a resource, like a disk) the next thread can go on ahead and do it's work

Your milage may vary on how well threading is implemented in an app. You'll get the most out of threads in problems were the data processing can be broken into seperate unrelated tasks. An example of this would be, say, a web server or any application that processes queries/requests.



[ Reply to This | # ]
Install an optimized BIND 9.2.3Beta
Authored by: uridium on Nov 04, '05 01:50:02PM

If your optimising you can also make it more portable. If you for instance run it over a mix older machines (for instance 750GX g3's) & newer kit (eg g5's) and want a common bin to roll out over {nfs,afp,smb} and have the latest tiger dev tools, you can create a fat binary using MAB's. If you set your CFLAGS to include: "-arch ppc -arch ppc64" this will let you run the same thing in/on 64bit mode on your g5 and in 32bit mode on your g3. OSX's got $CLUE which part to run for which binary without switches. Eg.. simple program dumping word size from sizeof(long):

(on the 32bit 750GX g3-400)
downshift:~ %./mabLuv-arch_DPaction

32 bit

(On the 64bit 970 g5-1.8ghz)
springer:~ %./mabLuv-arch_DPaction

64 bit

As far as $BLOAT factor goes, it's not that bad, here's the file sizes for ppc32bit, ppc64bit and the fat MAB bin:

-rwxr-xr-x 1 uridium uridium 13800 Oct 23 23:43 mabLuv-arch_ppc
-rwxr-xr-x 1 uridium uridium 12688 Oct 23 23:43 mabLuv-arch_ppc64
-rwxr-xr-x 1 uridium uridium 34280 Oct 23 23:42 mabLuv-arch_DPaction

Roughly double. Nice though if your messing with a few dozen or a cluster of machines and have the policy of rolling out a common binary without having to compile on each node.



[ Reply to This | # ]