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> <ROCKWELL.91May10233855@socrates.umd.edu>
Date: Wed, 15 May 91 21:28:42 GMT

In article <ROCKWELL.91May10233855@socrates.umd.edu> 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.

