On Monday 11 May 2009 21:43:33 Tim Soderstrom wrote: > On May 11, 2009, at 11:46 AM, Francesco Riosa wrote: > > On Monday 11 May 2009 17:53:59 Tim Soderstrom wrote: > >> On May 11, 2009, at 10:47 AM, Francesco Riosa wrote: > >>> On Monday 11 May 2009 16:53:23 Jay Pipes wrote: > >>>> Francesco Riosa wrote: > >>>>> gcc -c -Q -O3 --help=optimizers | grep funroll-loops > >>>>> -funroll-loops [disabled] > >>>>> > >>>>> -funroll-loops is the first branch in the root of evil, don't rely > >>>>> on it, > >>>>> even force -O3 isn't as good as it seem often. > >>>> > >>>> Hehe, yes, I'm aware of the dangers :) /me is not a Gentoo user ;) > >>> > >>> No comment, you little anti-gentoo fanboy :) > >> > >> Actually, what about -Os (without -funroll-loops)? -Os does more > >> optimizations than -O2 but fewer than -O3 in an effort to produce a > >> smaller foot-print. I have not done an extensive test, but did notice > >> that it made noticeably smaller binaries when I used it. > > > > Actually it does some less: > > -falign-jumps > > -falign-labels > > -falign-loops > > -finline-functions > > -freorder-blocks > > -ftree-ch > > -ftree-pre > > > > -Os is -O2 minus code growing optimizations > > I did use -Os with mysql 5.1 happily and with a rather noticeable > > slimmer > > mysqld, expecially on 64 bit (yes I'm a bit richer too) > > Right so the question is - what is more important to cache in L1/L2/L3 > - Drizzle or the data it is operating on? I'm thinking the latter. > Does unrolling loops really help all that much if the data we need to > work on isn't in the cache? If the code footprint is smaller, that > means we can put more data into cache. Besides, it's harder to control > the caching of data (I would think) than controlling the code foot- > print.
All from memory ... of stuff which i don't master, so take it with a graint of salt. L1,L2 caches are very small, and no serious table could be fit into them, so caching make no sense, also if I recall it correctly there are separate caches for instruction and data. That said, the question it's more, is the unrolled loop faster enough to compensate for the code it will keep out of L1/L2/L3 cache? the general consensus fro the comments I've read is "dont do it yourself", this kind of optimization is too tight to the processor, and out of control. As opposed to this tecnique there are ways to parallelize some loops. For big enough loop at least (which are the opposite of the loops that can be unrolled). Seem to recall it was explained/implemented in intel threading library, something they released to help programmers do effective parallelization. Another question, that maybe some hardware conscious could answer: the cpu builded in this century aren't able to do branch prediction and prefetching on more than one branch? > > Practically, I haven't looked near that deep when it comes to DB > performance so I'm mostly just commenting for the safe of > conversation :) idem, belive it or not I was more interested in stability while running the dbserver > >> I agree, however, for things other than desktop applications that > >> don't do a lot of context-switching, -funroll-loops is terrible > >> because it makes the program size so much bigger, which tends to eat > >> up a lot of cache. Again, I haven't do an extensive test, but that's > >> what I found out on a high level when I played around with it. > >> > >> http://funroll-loops.info/ > > > > already in my bookmarks ... since 2005 ;) > > I loved that site even when I was a Gentoo user. I refuse to call > myself a ricer because the only optimizations I used were -O3 and > later -Os. Well, that and -fomit-frame-pointer occasionally :) > > Tim S. _______________________________________________ Mailing list: https://launchpad.net/~drizzle-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~drizzle-discuss More help : https://help.launchpad.net/ListHelp
