Karel Zak wrote: > On Sat, 2004-09-25 at 23:23 +0200, Manfred Spraul wrote: > > [EMAIL PROTECTED] 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 :-)
The reason MemSet is a win is not that the C code is great but because it eliminates a function call. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
