[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Texmacs-dev] Efficiency of C++ switch-statements
From: |
Joris van der Hoeven |
Subject: |
Re: [Texmacs-dev] Efficiency of C++ switch-statements |
Date: |
Wed, 12 Nov 2003 11:36:33 +0100 (CET) |
> "Density" in the current GCC implementation is expressed as a ratio
> of number of labels over the range of the cases. For example if you're
> requesting optimization for size, then it might be that the switch is
> dense if that ratio is greater than 1/3, otherwise it might be 1/10.
Are you sure about these numbers (1/3 and 1/10)?
By default, optimization is for speed, right (so 1/10)?
> | I hope so! Maybe that you have to give the user some control
> | over the optimization. If the code is optimized for small size,
>
> Well, a big concern with GCC is that it already has far too many
> options, and not all combinations of them are fully tested. Anytime a
> new option is added (at user level), it implies a new combinatorial
> complexity. So, there is some resistance to put options about any
> single decision made by the compiler...
Well, optimization over size/speed should already provide some control.
> | 2) A table with 200 items is not that large in memory for
> | present standards.
>
> Well, it is not clear off hand that even when you're optimizing for
> speed a branch table of size 200 with only 5 relevant entries will be
> faster, compared to a series of less than five compares. It depends
> on other factors like the costs of instructions or the cache lines,
> or... all other low-level details you usually don't care about.
Yes, but I am thinking about branch tables of size 150
with between 10 and 30 relevant entries... :^)
> | Finally, I think that if you switch over an enum,
> | then the likelyness of table lookup should be increased.
>
> I don't know. I don't believe it makes any difference with C enums.
> C++ enums are a bit different, since the C++ standard allows for short
> ranges -- and g++ does take advantages of that in some minor cases.
Enums (without explicit numbers for the items) are by default dense,
and they usually serve a dense purpose. So there should be a bonus
with regards to the required density rate.
> I don't know if Texmacs has routines to report on time it spends in
> various parts...
Not really; I can easily add such routines for clearly identified tasks.
But if I want to optimize typesetting efficiency, with hundreds of
subroutines, then I have to use tools like gperf. I spent a few days
doing that in the past, but this is a heavy operation.
Re: [Texmacs-dev] Efficiency of C++ switch-statements, Dan Martens, 2003/11/11