Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Eric Sosman <esosman@ieee-dot-org.invalid> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Small Variant Records in C |
| Date | 2011-12-19 17:19 -0500 |
| Organization | A noiseless patient Spider |
| Message-ID | <jcod9i$ajn$1@dont-email.me> (permalink) |
| References | (7 earlier) <fb727845-65e8-48a2-8cc9-a44d0c2d6f05@z12g2000yqm.googlegroups.com> <jcns0c$kl0$1@dont-email.me> <f74b6815-7230-41a7-9c7f-78b342138c64@l29g2000yqf.googlegroups.com> <jco6bg$ruj$1@dont-email.me> <4dacb061-5794-4e16-941f-b8e86f4b96d0@m10g2000vbc.googlegroups.com> |
On 12/19/2011 4:38 PM, Marco Devillers wrote:
>> Can you octuple your cache when you octuple your memory use?
>
> Come again? I hope I can 'octuple' a lot of things if I know what
> it means.
Double = times two, triple (treble) = times three, ...
octuple = times eight. My point being that it is often possible
to add RAM to a system, up to some limit, but less frequently
possible to expand a system's caches. The lowest-level cache can
sometimes be grown (if so, usually by doubling, once), but higher-
level caches almost never. The only way to grow the on-chip cache
is to get a new CPU chip.
> I guess you are referring to the above wasteful scheme?
Yes.
> I know I
> need to design something which aims at the current hybrid of 32bit/
> 64bit processor models such that I can hopefully get away with packing
> RTTI information into 32 or 64 bits headers instead of representing
> each field with 64 bits. And that also supposes some understanding of
> how, say, on Intel x64, C instructions and data representations are
> usually compiled to specific data and microinstructions and the
> resulting memory/cache behavior of programs, instead of the logically
> correct but not very world aware representation I have now.
No. Forgive the mixed metaphor, but you've gone down into the
weeds before taking the fifty-thousand-foot view. At this stage you
do *not* need to aim at any particular family of processors, you do
*not* need to pay heed to instruction sets, you do *not* need to think
about microinstructions or pipeline architecture or any such matters.
And the only thing you need to know about memory and caches (again,
at this stage) is that memory is slow and cache is limited. This
means that bloat has a speed penalty, sometimes a dramatic penalty.
It's not worth while to save 1K out of a data structure with six
instances, but it probably *is* worth while to save 8B out of a data
structure you will create by the hundreds of thousands.
More mixed metaphors: You're driving a car that hasn't been tuned
since the Clinton administration, on under-inflated tires, with an empty
boat trailer dragging behind, and you're fond of jackrabbit starts.
Your fuel economy, of course, is dismal -- and it absolutely does not
matter one tiny little bit what brand of motor oil you use. Cure your
bad driving habits, unhitch the trailer, pump up the tires, give the
jalopy some maintenance, and *then* you can start thinking about
which oils are slipperier under what conditions.
Tricks of the kinds Kaz mentions are the super-fancy motor oil,
to be used after you've already wrung the utmost out of "normal"
methods and find you still need more zip. They will not solve your
problem with the eight sacks of concrete mix in your trunk.
> PS. Note that this is just a project I once started to learn some
> stuff and implement some new and funny ideas given what I read. It is
> in no means a production compiler or a research project. Consequently,
> some design choices I made are goofy and nice, some are plain horrible.
There's nothing wrong with learning by exploration; in fact, it's
got a lot to recommend it. But this doesn't mean you should ignore
good sense altogether!
--
Eric Sosman
esosman@ieee-dot-org.invalid
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-18 10:16 -0800
Re: Small Variant Records in C Seebs <usenet-nospam@seebs.net> - 2011-12-18 18:50 +0000
Re: Small Variant Records in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-18 15:00 -0500
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-18 12:23 -0800
Re: Small Variant Records in C Seebs <usenet-nospam@seebs.net> - 2011-12-18 21:15 +0000
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-18 14:13 -0800
Re: Small Variant Records in C Seebs <usenet-nospam@seebs.net> - 2011-12-19 00:26 +0000
Re: Small Variant Records in C "BartC" <bc@freeuk.com> - 2011-12-19 02:25 +0000
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-18 19:08 -0800
Re: Small Variant Records in C "BartC" <bc@freeuk.com> - 2011-12-19 17:24 +0000
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-19 11:43 -0800
Re: Small Variant Records in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-19 15:21 -0500
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-19 13:38 -0800
Re: Small Variant Records in C James Kuyper <jameskuyper@verizon.net> - 2011-12-19 16:48 -0500
Re: Small Variant Records in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-19 17:19 -0500
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-19 15:14 -0800
Re: Small Variant Records in C "BartC" <bc@freeuk.com> - 2011-12-19 21:44 +0000
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-19 14:02 -0800
Re: Small Variant Records in C Kaz Kylheku <kaz@kylheku.com> - 2011-12-19 18:38 +0000
Re: Small Variant Records in C jgk@panix.com (Joe keane) - 2012-01-04 03:52 +0000
Re: Small Variant Records in C Ian Collins <ian-news@hotmail.com> - 2012-01-04 20:25 +1300
Re: Small Variant Records in C Tim Rentsch <txr@alumni.caltech.edu> - 2012-01-25 15:53 -0800
Re: Small Variant Records in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-18 18:35 -0500
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-18 16:01 -0800
Re: Small Variant Records in C Seebs <usenet-nospam@seebs.net> - 2011-12-19 00:26 +0000
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-18 17:02 -0800
Re: Small Variant Records in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-18 19:53 -0500
Re: Small Variant Records in C "BartC" <bc@freeuk.com> - 2011-12-19 01:36 +0000
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-18 18:21 -0800
Re: Small Variant Records in C "BartC" <bc@freeuk.com> - 2011-12-19 02:52 +0000
Re: Small Variant Records in C Marco Devillers <marco.devillers@gmail.com> - 2011-12-18 19:17 -0800
Re: Small Variant Records in C Eric Sosman <esosman@ieee-dot-org.invalid> - 2011-12-19 09:24 -0500
Re: Small Variant Records in C "BartC" <bc@freeuk.com> - 2011-12-19 17:18 +0000
csiph-web