Re: [PHP4BETA] Hoard

From: Date: Wed, 03 Nov 1999 01:29:47 +0000
Subject: Re: [PHP4BETA] Hoard
References: 1  Groups: php.version4 
Request: Send a blank email to php-version4+get-5848@lists.php.net to get a copy of this message
>> If so (or if it's something that someone could use as a 'bolt-on' addition >> when compiling PHP), then exactly what benefits could it bring to PHP? They >> say it "can dramatically improve the performance of multithreaded programs", >> but in what way? > >It improves performance for threaded programs running on SMP boxes, and >yes, it might be possible to do a bolt-on job. > >> It seems (from my interpretation) that as Hoard speeds up memory allocation, >> that this will only make a big difference for the CGI version of PHP, as >> memory is allocated primarily on a program's startup/shutdown. The Apache >> module version of PHP is always in memory, is it not? > >Well, memory is still allocated. Not as often, true, but third-party libs >that just call malloc/free directly that are linked into PHP might benefit >as well. There is really no way to know if it will speed things up until >you give it a whirl. Memory allocation on most systems isn't such a big deal, unless you're allocating and deallocating extremely frequently, like inside of a loop (like many C++ programs do, instantiating and destroying dynamically-created objects). It is fairly difficult to improve upon the SysV malloc strategy, unless you know something pretty clear about your memory-usage patterns (ie. irregular-size or sub-blocksize chunks, frequent alloc/free usage, etc.) This 'Hoard' is likely targetted toward users who are using C++ heavily, and are spending large amounts of processor time in malloc/free - which will not scale well with additional processors, since there would be a race condition on the free-memory chain. Notice how often the benchmarks allocate memory, compared to doing 'real' work - this is probably not indicative of performance on a normal system.

« previous php.version4 (#5848) next »