lookup tables

[makc.the.great]

I have this global table:

char t[256] = { 1, 3, 3, 4,... 7 };

would it be faster or slower with "static"?

 

[Greg]

I have this global table:

char t[256] = { 1, 3, 3, 4,... 7 };

would it be faster or slower with "static"?

*-----------------

For a global table there would be no difference. For a local table, a
static storage specifier will be faster because the table will not have
to be allocated and initialized each time its scope is entered.

Declaring the chars "const' could be faster and would definitely be
safer.

Greg

 

[makc.the.great]

For a global table there would be no difference.

Declaring the chars "const' could be faster and would definitely be
safer.

Thanx.

 

[usr.root]

(e-mail address removed) 写é“：

I have this global table:

char t[256] = { 1, 3, 3, 4,... 7 };

would it be faster or slower with "static"?

There is no defference about the speed.If you use a static ,it means
that ,the code in other files can't usr this table.

 

[tmartsum]

static in front of a global is (allmost) an error.
(for some compilers this means use internal linkages - but just don't
write static there)

(use const)

/Thorbjørn

 

[usr.root]

tmartsum 写é“：

static in front of a global is (allmost) an error.
(for some compilers this means use internal linkages - but just don't
write static there)

i don't agree with you,sometimes wo do need to use static global.

 

[tmartsum]

PS : Performance might change by wrinting
const char *t = "\1\3\3\4....\7"

This will put the sting in codesegment and not the heap - do not know
if it is faster ....

 

[tmartsum]

i don't agree with you,sometimes wo do need to use static global.

You really cant disagree ... - it is an error - it is a fact.

In C and older C++ programs the keyword static is (confusingly) used to
mean "use internal linkage" (§B.2.3) Don't use static except inside
function (§7.1.2) and classes (§10.2.4)

from C++ programming language section 9.2.1
by Bjarne Stroustrup

 

[Greg]

tmartsum 写é“：


i don't agree with you,sometimes wo do need to use static global.

C++ has officially deprecated the use of static to indicate internal
linkage for a global variable. An unnamed namespace should be used for
this purpose. In other words, a declaration like this:

static int MyTable[] = {1, 2, 3, ,4, 5};

in C, should be changed to

namespace
{
int MyTable = {1, 2, 3, 4, 5};
}

in C++.

Greg

 

[persenaama]

would it be faster or slower with "static"?

Try and see on compiler and platform of your choise if it makes any
difference for you static being deprecated withstanding.

That disclaimer off the way, on practical level I'd say that is smaller
of the worries when you introduce global variables into your programs.
Limit the scope and storage, possibly using unnamed namespace and then
we get to the beef which in this case is that most likely the relevance
to performance is neglible.

How you access this array is much more likely to be more relevant, if
your code is crafted and circumastances allow very common compiler
optimizations like constant propagation will step into effect making
your question questionable (!). But generally, when generating the code
your compiler does know the base address of this array. If the index to
the array is not a constant, doesn't much matter in practise either as
far as reading and writing to objects in the array is concerned, in
this case the size of object is 1 char which usually translates to
"unique memory address" (YMMV).

This is fundamentally what would refer to object in the array:
base[offset]
equals to:
*(base+offset)

Incidentally, this is a very common addressing mode for hardware which
usually runs compiled c++ programs. It wouldn't make any difference in
practise to this:

*(base+constant_offset)

Except when base is *known* symbol when code is being generated, the
expression can be in best case scenario be replaced with a constant
expression, which may end up being propagated away. But for this to
happen you want to guarantee that the objects are read-only, so you
might want to use "const" qualifier. Otherwise the compiler cannot make
any assumption what value resides in the specified location.

But most likely that is not the pattern you will be using this with,
the biggest hint being the fact that you are defining an array up
there. In that case, it doesn't make much of a difference what storage
you end up using, but again this is context specific.

Show example of typical piece of code how you would go about accessing
the array, there usually is a common pattern for computing the index.
If you really concerned about SPEED think of cache.. what order you
access the objects in the array? Is there anything that is predictable?
Would it help to re-.organize the objects in the array to hit cache
more often. These questions are OT in c.l.c++ but you might want to ask
these from yourself and see what you come up with. ;-)

 

[Maxim Yegorushkin]

Greg wrote:

[]

C++ has officially deprecated the use of static to indicate internal
linkage for a global variable. An unnamed namespace should be used for
this purpose. In other words, a declaration like this:

I heard that they had changed their minds and static was vindicated.

 

[tmartsum]

Link to info ?

 

[makc.the.great]

If you really concerned about SPEED think of cache.. what order you

access the objects in the array? Is there anything that is predictable?

These are lookup tables for color transforms. I.e., if we have
Y=r*R+g*G+b*B, then i-th items of these tables will hold r*i, g*i and
b*i (actually, I use i-r*i-b*i for green, but duh). Then, when I map
RGB->Y, I need three lookups and two additions. RGBs comes in
unpredictable order.

I know there are lots of asm code for bulk data transforms like that,
but I actually need these transforms to be done to individual (and also
unpredictable) pixels, not whole image. Plus this may happen any number
of times (not known in advance). Hence plain c++ method. Still, I'd
like it to be as fast as possible.

Someone suggested char*="dlnitn". Could anyone else confirm if this is
faster?

 

[tmartsum]

Not understood what you want , but .....

Two considerratioons. If I understand you right then you are looking
at the same index in two tables. It is faster to have one merged table
accessing
table[v] and then table[v+1] (Less risk of cachemiss)

i-r*i-b*i

you do calculate it somting like i*(1-r-b) ?




1) Keep one table and not 2

 

[Ben Pope]

Someone suggested char*="dlnitn". Could anyone else confirm if this is
faster?

From what I understand, that would be a const with static storage. I'm
not sure to what you are referring it would be faster than.

char* table="dlnitn";

Is something like:

const char table[7] = {0x64, 0x6c, 0x6e, 0x69, 0x74, 0x6e, 0x00};

But looks far less like a lookup table than a strange string. There is
no requirement for it to be null terminated, so I don't really see the
point.

Ben

 

[benben]

PS : Performance might change by wrinting

const char *t = "\1\3\3\4....\7"

This will put the sting in codesegment and not the heap - do not know
if it is faster ....

What's put on the heap?

Ben

 

[tmartsum]

char* table = "blahbhla" is const by itself hence

table[0] = 'a' can crash

so the above versio of table is often "more" const than your example.
(Depends on compiler)

 

[makc.the.great]

If I understand you right then you are looking
at the same index in two tables.

no, index is same during table generation (it uses fact that R=G=B
yields Y=R).

For example, let's say it is Y=0.1R+0.2G+0.7B, and R, G and B can be
0,1,...,255. If R=G=B=0 then Y=0, if R=G=B=1 then Y=1, etc. So, given
three tables t1=0.1*i, t2=0.2*i, t3=0.7*i for i=0,1,...,255,
you can later calculate Y=t1[R]+t2[G]+t3, i.e. without
multiplications.

Can't imagine how to simplify it further, probably there's no way.

 

[makc.the.great]

it uses fact that R=G=B yields Y=R
actually, I think it would work regardless of that. Sorry to confuse
you.

My question should have been stated as "what's the best place to put
lookup tables". I figured out that global scope would be best because
tables would be only created once. Then, I thought what could be an
effect of "static" there. This is now explained, so I guess I have my
answer, but... now I am going in circles

Can some one summarize which declarations put data on heap, and wich on
stack? Could I have tables on stack and static, too? Which is faster,
if any (stack variables are never swapped, are they)? And why const is
better, if it is?

 

[Ben Pope]

char* table = "blahbhla" is const by itself hence

table[0] = 'a' can crash

so the above versio of table is often "more" const than your example.
(Depends on compiler)

You're saying that:
char* table "blahbhla";

is "more" const than:

const char table[] = {'b','l','a','h','b','h','l','a','\0'};

I don't see how.

Ben