Newsgroups: comp.arch Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!wuarchive!gumby!umich!dgsi!paulh From: paulh@cimage.com (Paul Haas) Subject: Re: Compilers and efficiency Message-ID: <1991May15.212842.11852@cimage.com> Reply-To: paulh@dgsi.UUCP (Paul Haas) Organization: Cimage Corp, Ann Arbor, MI References: <9782@mentor.cc.purdue.edu> <11411@mentor.cc.purdue.edu> <653@ctycal.UUCP> <1991May8.205106.6039@Stardent.COM> <28297C23.6984@tct.com> Date: Wed, 15 May 91 21:28:42 GMT In article rockwell@socrates.umd.edu (Raul Rockwell) writes: > >At work we have a hand-optimized assembly routine to convert from a >bit array to a list of indices. It gets used a lot. > >Please note that a bit list is very handy for dealing with selection >problems. They are very compact, and have very predictable size >requirements. > ... >Raul Rockwell Our product also uses bit lists to store selection lists. According to gprof my rather naive find_next_bit() function (coded in C) took an insignificant amount of run time. In our application we have to render each selected entity, and that takes far longer than the bit twiddling. To see if a new instruction would be usefull, it helps to have a some numbers to show how much it would speed up a real application. For our application we will probably get a measurable improvement (with a profiler you can measure lots of insignificant things :-)) when we can use 64 bit words. Sometimes the selection lists are rather sparse, so we spend some time scanning for the next non-zero word. 64 bit words will speed up lots of applications. -- Paul Haas paulh@cimage.com (313) 761-7478 I am not now, nor have I ever been an official spokesman for Cimage Corporation.