Re: Table compression

Peter Flass <Peter_Flass@Yahoo.com>
2 Oct 2005 02:49:23 -0400

          From comp.compilers

Related articles
[3 earlier articles]
Re: table compression heng@Ag.arizona.edu (Heng Yuan) (2001-11-08)
Re: table compression mickunas@cs.uiuc.edu (Dennis Mickunas) (2001-11-08)
Table compression leonardo@dcc.ufmg.br (Leonardo Teixeira Passos) (2005-09-27)
Re: Table compression anton@mips.complang.tuwien.ac.at (2005-09-30)
Re: Table compression hannah@schlund.de (2005-09-30)
Re: Table compression cleos@nb.sympatico.ca (Cleo Saulnier) (2005-09-30)
Re: Table compression Peter_Flass@Yahoo.com (Peter Flass) (2005-10-02)
Re: Table compression paul@parsetec.com (Paul Mann) (2005-10-02)
Re: Table compression cfc@shell01.TheWorld.com (Chris F Clark) (2005-10-03)
Re: Table compression henry@spsystems.net (2005-10-13)
| List of all articles for this month |

From: Peter Flass <Peter_Flass@Yahoo.com>
Newsgroups: comp.compilers
Date: 2 Oct 2005 02:49:23 -0400
Organization: Road Runner
References: 05-09-130 05-09-138
Keywords: parse, practice

All other things being equal, it's *always* better to be efficient.
Obviously there are trade-offs, but frequently it doesn't take much
more effort, if any, to do things the right way. It's just lazy to
say that with (big memories)|(fast CPUs)|(<fill in the blanks>) it
doesn't matter.


Hannah Schroeter wrote:


> Hello!
>
> I'm actually more replying to John's comment than to the original
> question.
>
> Leonardo Teixeira Passos <leonardo@dcc.ufmg.br> wrote:
>
>>[...]
>
>
> In fact, John wrote:
>
>>[Since computer memories have gotten so big, does anyone care about
>>table compression any more? When your whole compiler had to fit into
>>64K, compressing a few K out of the table was a big deal. But now, a
>>typical Windows program has a megabyte of unused libraries that aren't
>>work stripping out, so why waste time with the tables? Well, unless
>>you're squeezing it into an embedded chip, but even they have a lot
>>more memory than they used to. -John]
>
>
> I'd guess you'd still have a better cache behaviour if the tables
> or a bigger fraction thereof fits into the L1 d-cache. So I'd think
> table compression may still make sense nowadays.


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.