home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!gatech!darwin.sura.net!jvnc.net!yale.edu!ira.uka.de!uka!uka!news
- From: S_JUFFA@iravcl.ira.uka.de (|S| Norbert Juffa)
- Newsgroups: comp.lang.pascal
- Subject: Re: Why are set operations so Slow?
- Date: 13 Aug 1992 17:48:18 GMT
- Organization: University of Karlsruhe (FRG) - Informatik Rechnerabt.
- Lines: 19
- Distribution: world
- Message-ID: <16e792INNm3j@iraul1.ira.uka.de>
- References: <Aug07.232901.50322@yuma.ACNS.ColoState.EDU> <Bstu1E.ArL@knot.ccs.queensu.ca> <16b4c7INN88n@iraul1.ira.uka.de> <dmurdoch.5.713628912@mast.queensu.ca>
- NNTP-Posting-Host: irav1.ira.uka.de
- X-News-Reader: VMS NEWS 1.23
- In-Reply-To: dmurdoch@mast.queensu.ca's message of Wed, 12 Aug 1992 14:15:13 GMT
-
- In <dmurdoch.5.713628912@mast.queensu.ca> dmurdoch@mast.queensu.ca writes:
-
- > The claim I saw in the Stoney Brook pamphlet was that operations on sets
- > were converted to the equivalent bitwise operations when possible. If S is
- > a set of 250..255, then S+[251] would be compiled to do a bitwise OR of 2
- > into S. That's not a choice that was available to you in improving the RTL;
- > you'd have to go back further, and change the code generator.
- >
- Well, it just occured to me that most of the info TP passes to the library
- routines for set handling is know at compile time. So the code generator
- could precompute the offset into the byte array representing the set and
- the appropriate bit mask to greatly speed up most set operations, at least
- if constants are involved somewhere.
-
- Norbert
- -------------------------------------------------------------------------------
- Norbert Juffa email: S_JUFFA@IRAVCL.IRA.UKA.DE Live and let live!
-
-
-