Re: tweaking MemSet() performance - 7.4.5
Karel Zak <zakkr@zf.jcu.cz>
From: Karel Zak <zakkr@zf.jcu.cz>
To: Manfred Spraul <manfred@colorfullife.com>
Cc: mcolosimo@smtp-bedford.mitre.org, Marc Colosimo <mcolosimo@mitre.org>, List pgsql-hackers <pgsql-hackers@postgreSQL.org>
Date: 2004-09-29T08:46:18Z
Lists: pgsql-hackers
On Sat, 2004-09-25 at 23:23 +0200, Manfred Spraul wrote: > mcolosimo@mitre.org wrote: > > >>If the memset > >>bypasses the cache then the following access will cause a cache line > >>miss, which can be so slow that using the faster memset can result in a > >>net performance loss. > >> > >> > >> > > > >Could you suggest some structs to test? If I get your meaning, I would make a loop that sets then reads from the structure. > > > > > > > Read the sources and the cpu specs. Benchmarking such problems is > virtually impossible. > I don't have OS-X, thus I checked the Linux-kernel sources: It seems > that the power architecture doesn't have the same problem as x86. > There is a special clear cacheline instruction for large memsets and the > rest is done through carefully optimized store byte/halfword/word/double > word sequences. > > Thus I'd check what happens if you memset not perfectly aligned buffers. > That's another point where over-optimized functions sometimes break > down. If there is no slowdown, then I'd replace the postgres function > with the OS provided function. > > I'd add some __builtin_constant_p() optimizations, but I guess Tom won't > like gcc hacks ;-) I think it cannot be problem if you write it to some .h file (in port directory?) as macro with "#ifdef GCC". The other thing is real advantage of hacks like this in practical PG usage :-) Karel -- Karel Zak http://home.zf.jcu.cz/~zakkr