NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/lang/pascal/4818

Text File | 1992-08-12 | 1.7 KB | 33 lines

Newsgroups: comp.lang.pascal
Path: sparky!uunet!sun-barr!cs.utexas.edu!torn!news.ccs.queensu.ca!mast.queensu.ca!dmurdoch
From: [e-mail] (Duncan Murdoch)
Subject: Re: Why are set operations so Slow?
Message-ID: <[e-mail]>
Lines: 21
Sender: [e-mail] (Netnews control)
Organization: Queen's University
References: <[e-mail]> <[e-mail]> <[e-mail]>
Date: Wed, 12 Aug 1992 14:15:13 GMT

In article <[e-mail]> [e-mail] (|S| Norbert Juffa) writes:
>Since sets are stored with maximum compression ( [250..255] takes only one
>byte), I can't see how to avoid the expansion into a 32-byte buffer before
>every operation. What optimizing compiler's like SBP+ can easily speed up are
>tests like: ReadLn (Ch); IF Ch IN ValidChars THEN ..., where ValidChars is a
>SET OF CHAR with only very few set members. This can be optimize to a chain
>of IF...THEN...ELSEs and I am sure this is what SBP+ does. TP 7.0 is supposed
>to feature the same optimization.

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.

I've been told that there are some people on Genie who have pretty well
dissected the TP code generator, so perhaps changes there would be possible.
It would be hard to trust the results, though.

Duncan Murdoch
[e-mail]