472,364 Members | 2,174 Online

# efficiency of && vs. array

hi,

i'm working with data for a clinical trial. i write data edit-checks
using a program called DataFax, which has its own built-in programming
language which is loosely based on C. as such, the code example might
not have the exact same syntax as C, but the principle is the same.

i'm working on a edit check that will test a series of values, like
so:

if (a == 1 && b == 1 && c == 1 && d == 1)
then....

it occured to me that i could store a, b, c, and d in an array and use
an iterator perform the same function:

number i = 1;
group TEST a, b, c, d; /* create an array called TEST and store a,b,c,d
*/
if (condition) {
while (i <= 4) {
if (TEST[i] == 1) {...;}
i = i + 1;}
then....

my question is: which one of these methods is the best practice? is one
inherently more efficient than the other? am i making sense?

thanks,

chris

Feb 10 '06 #1
21 1408
christopher wrote:

hi,

i'm working with data for a clinical trial. i write data edit-checks
using a program called DataFax, which has its own built-in programming
language which is loosely based on C. as such, the code example might
not have the exact same syntax as C, but the principle is the same.

i'm working on a edit check that will test a series of values, like
so:

if (a == 1 && b == 1 && c == 1 && d == 1)
then....

it occured to me that i could store a, b, c, and d in an array and use
an iterator perform the same function:

number i = 1;
group TEST a, b, c, d; /* create an array called TEST and store a,b,c,d
*/
if (condition) {
while (i <= 4) {
if (TEST[i] == 1) {...;}
i = i + 1;}
then....

my question is: which one of these methods is the best practice?
is one
inherently more efficient than the other? am i making sense?

The first way is computationally less intensive.

--
pete
Feb 10 '06 #2
christopher wrote:
i'm working with data for a clinical trial. i write data edit-checks
using a program called DataFax, which has its own built-in programming
language which is loosely based on C. as such, the code example might
not have the exact same syntax as C, but the principle is the same.

i'm working on a edit check that will test a series of values, like
so:

if (a == 1 && b == 1 && c == 1 && d == 1)
then....

it occured to me that i could store a, b, c, and d in an array and use
an iterator perform the same function:

number i = 1;
group TEST a, b, c, d; /* create an array called TEST and store a,b,c,d
*/
if (condition) {
while (i <= 4) {
if (TEST[i] == 1) {...;}
i = i + 1;}
then....

my question is: which one of these methods is the best practice? is one
inherently more efficient than the other? am i making sense?

My recommendation is to program for maximum clarity. The difference in
efficiency is probably negligible (you know the three rules of
optimization, right?). What representation to use depends on where the
variables a, b, c and d come from. Are they related? How are they related?
August

--
I am the "ILOVEGNU" signature virus. Just copy me to your
signature. This email was infected under the terms of the GNU
Feb 10 '06 #3
no - i don't know the three rules of optimization. what are they?

Feb 10 '06 #4
christopher wrote:

no - i don't know the three rules of optimization. what are they?

I can only remember the first two:

First rule of optimization: "Don't do it."
Second rule (for experts only): "Don't do it yet."

--
pete
Feb 10 '06 #5
christopher said:
no - i don't know the three rules of optimization. what are they?

I thought there were only two. They are:

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it /yet/.

My candidate for Rule 3 would be: If you must do this damn silly thing,
don't do it in this damn silly way.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Feb 10 '06 #6
Richard Heathfield wrote:
christopher said:
no - i don't know the three rules of optimization. what are they?

I thought there were only two. They are:

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it /yet/.

My candidate for Rule 3 would be: If you must do this damn silly thing,
don't do it in this damn silly way.

Mine would be: find out where to optimise by measurement, not guesswork.

--
Chris "do as I say, not as I have done ..." Dollin
Feb 10 '06 #7
"christopher" <co*****@gmail.com> wrote:
hi,

i'm working with data for a clinical trial. i write data edit-checks
using a program called DataFax, which has its own built-in programming
language which is loosely based on C. as such, the code example might
not have the exact same syntax as C, but the principle is the same.

i'm working on a edit check that will test a series of values, like
so:

if (a == 1 && b == 1 && c == 1 && d == 1)
then....

it occured to me that i could store a, b, c, and d in an array and use
an iterator perform the same function:

number i = 1;
group TEST a, b, c, d; /* create an array called TEST and store a,b,c,d
*/
if (condition) {
while (i <= 4) {
if (TEST[i] == 1) {...;}
i = i + 1;}
then....

my question is: which one of these methods is the best practice? is one
inherently more efficient than the other? am i making sense?

It occured to me that you could write a, b, c, and d to a file and read
them back from that file everytime you need them. You could then use
some encryption to make the process of reading from the file more
secure.

You are not by any chance working on any IT project paid for by the
British government?
Feb 10 '06 #8
"christopher" <co*****@gmail.com> wrote:
no - i don't know the three rules of optimization. what are they?

Don't do it.
Don't do it yet.
Don't do it unless you measure the effect.
Feb 10 '06 #9

christopher wrote:
hi,

i'm working with data for a clinical trial. i write data edit-checks
using a program called DataFax, which has its own built-in programming
language which is loosely based on C. as such, the code example might
not have the exact same syntax as C, but the principle is the same.

i'm working on a edit check that will test a series of values, like
so:

if (a == 1 && b == 1 && c == 1 && d == 1)
then....

it occured to me that i could store a, b, c, and d in an array and use
an iterator perform the same function:

number i = 1;
group TEST a, b, c, d; /* create an array called TEST and store a,b,c,d
*/
if (condition) {
while (i <= 4) {
if (TEST[i] == 1) {...;}
i = i + 1;}
then....

my question is: which one of these methods is the best practice? is one
inherently more efficient than the other? am i making sense?

thanks,

chris

Assuming that the language you use is like C, and the "..." doesn't
suppress any important details of the variant, then:

1) The expresssion handling of C fix that if, by example, if a==1 is
false, the remainder expression is not evaluated. However, in the loop
version, it seems that all the comparations will be done before to
execute or not the "then" clause.

2) Use TEST[i] instead of a named variable goes, in most part of
compilers, to more CPU expensive evaluation:
* "a" could be translated with: 1) read memory at address of a.
memory"

3) And, of course, there are also the time to init "i", ...

Kind regards.

Feb 10 '06 #10
Chris Dollin said:
Richard Heathfield wrote:
christopher said:
no - i don't know the three rules of optimization. what are they?

I thought there were only two. They are:

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it /yet/.

My candidate for Rule 3 would be: If you must do this damn silly thing,
don't do it in this damn silly way.

Mine would be: find out where to optimise by measurement, not guesswork.

That's another way of saying the same thing. :-)

Actually, please forgive me for saying so, Chris, but I think mine is more
generally useful.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Feb 10 '06 #11
Richard Heathfield wrote:
Chris Dollin said:
Richard Heathfield wrote:
christopher said:

no - i don't know the three rules of optimization. what are they?

I thought there were only two. They are:

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it /yet/.

My candidate for Rule 3 would be: If you must do this damn silly thing,
don't do it in this damn silly way.
Mine would be: find out where to optimise by measurement, not guesswork.

That's another way of saying the same thing. :-)

Well ... certainly mine is an instance of yours, but yours applies to
more situations than optimisation [1] ...
Actually, please forgive me for saying so, Chris, but I think mine is more
generally useful.

[2]
.... but gives less specific guidance; which works best is likely
target-dependent.

3. Don't be stupid about it.

[1] EG swimming from London to Paris by way of Seattle.

[2] Forgive? Moi? My grudges are held for eternity! No second of my time
will be wasted in avoiding plotting your downfall!! My arcane influence
is unavoidable!!!

<fx:knocking/>

Why, there's Alec Guinness and his friends, come for a pint!!!!

--
Chris "try, or try not -- there is no do" Dollin
Feb 10 '06 #12
christopher wrote:
hi,

i'm working with data for a clinical trial. i write data edit-checks
using a program called DataFax, which has its own built-in programming
language which is loosely based on C. as such, the code example might
not have the exact same syntax as C, but the principle is the same.

i'm working on a edit check that will test a series of values, like
so:

if (a == 1 && b == 1 && c == 1 && d == 1)
then....

it occured to me that i could store a, b, c, and d in an array and use
an iterator perform the same function:

number i = 1;
group TEST a, b, c, d; /* create an array called TEST and store a,b,c,d
*/
if (condition) {
while (i <= 4) {
if (TEST[i] == 1) {...;}
i = i + 1;}
then....

my question is: which one of these methods is the best practice? is one
inherently more efficient than the other? am i making sense?

Assuming that you have considered the rules from previous post on
premature optimisation and decided that they do not apply to your case,
and assuming that a, b, c, d are of integer type then:

if (1 & a & b & c & d) {

}

will be probably slightly faster since it generates only one test which
should be better on processors with branch prediction.

a+, ld.
Feb 10 '06 #13
Laurent Deniau said:
Assuming that you have considered the rules from previous post on
premature optimisation and decided that they do not apply to your case,
and assuming that a, b, c, d are of integer type then:

if (1 & a & b & c & d) {

}

will be probably slightly faster since it generates only one test which
should be better on processors with branch prediction.

But it doesn't test a, b, c and d against 1. Rather, it checks whether they
have the least significant bit set. Not the same thing.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Feb 10 '06 #14
Chris Dollin said:

3. Don't be stupid about it.

That's even more widely applicable, as it applies to absolutely everything.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Feb 10 '06 #15
Richard Heathfield wrote:
Laurent Deniau said:

Assuming that you have considered the rules from previous post on
premature optimisation and decided that they do not apply to your case,
and assuming that a, b, c, d are of integer type then:

if (1 & a & b & c & d) {

}

will be probably slightly faster since it generates only one test which
should be better on processors with branch prediction.

But it doesn't test a, b, c and d against 1. Rather, it checks whether they
have the least significant bit set. Not the same thing.

Are you sure?

a+, ld.
Feb 10 '06 #16

Laurent Deniau wrote:
Richard Heathfield wrote:
Laurent Deniau said:

Assuming that you have considered the rules from previous post on
premature optimisation and decided that they do not apply to your case,
and assuming that a, b, c, d are of integer type then:

if (1 & a & b & c & d) {

}

will be probably slightly faster since it generates only one test which
should be better on processors with branch prediction.

But it doesn't test a, b, c and d against 1. Rather, it checks whether they
have the least significant bit set. Not the same thing.

Are you sure?

a+, ld.

a=3;

if (a==1) /* jumps to else */
if(1&a) /* jumps to then */

(not tested).

Feb 10 '06 #17
Richard Heathfield wrote:
Laurent Deniau said:

Assuming that you have considered the rules from previous post on
premature optimisation and decided that they do not apply to your case,
and assuming that a, b, c, d are of integer type then:

if (1 & a & b & c & d) {

}

will be probably slightly faster since it generates only one test which
should be better on processors with branch prediction.

But it doesn't test a, b, c and d against 1. Rather, it checks whether they
have the least significant bit set. Not the same thing.

Sorry you are right (I had bool in mind):

if ((1 & a & b & c & d) == (1 | a | b | c | d)) {
}

should be better.

a+, ld.
Feb 10 '06 #18
Richard Heathfield wrote:
Chris Dollin said:

3. Don't be stupid about it.

That's even more widely applicable, as it applies to absolutely
everything.

In context, `it` is bound to `optimisation` ...

I'm stopping now. Buy you a pint sometime?

--
Chris "try, or try not -- there is no do" Dollin
Feb 10 '06 #19
Chris Dollin said:
Richard Heathfield wrote:
Chris Dollin said:

3. Don't be stupid about it.
That's even more widely applicable, as it applies to absolutely
everything.

In context, `it` is bound to `optimisation` ...

....and optimisation is bound t... oh, skip it. It wasn't all that funny
anyway.
I'm stopping now.
Good plan.

Better plan - although finding the time could be an insoluble opportunity!

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Feb 10 '06 #20
Richard Heathfield wrote:
Chris Dollin said:
Richard Heathfield wrote:
christopher said:

no - i don't know the three rules of optimization. what are they?
I thought there were only two. They are:

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it /yet/.

My candidate for Rule 3 would be: If you must do this damn silly thing,
don't do it in this damn silly way.

Mine would be: find out where to optimise by measurement, not guesswork.

That's another way of saying the same thing. :-)

Actually, please forgive me for saying so, Chris, but I think mine is more
generally useful.

I would have put something like this as rule 4 and for rule 3 have
something like:

3) See if you have a performance problem.

The point being that you can see if you have a problem generally rather
more easily than doing the measurements to find out where the
performance bottle neck is. Why go to that effort if you don't need to?
--
Flash Gordon
Living in interesting times.
Although my email address says spam, it is real and I read it.
Feb 10 '06 #21

"Richard Heathfield" <in*****@invalid.invalid> wrote

Rule 1: Don't do it.

Rule 2 (for experts only): Don't do it /yet/.

My candidate for Rule 3 would be: If you must do this damn silly thing,
don't do it in this damn silly way.

My rule would be: remove the giftwrapping if you don't want to give the code
to someone else.

Everyone says that you should try algorithmic optimisation first, which is
true as far as it goes. Often, however, the main reason prgorams run slower
than required is because they are reformatting and recalcuating data to make
it easy to pass to lower-level functions.

For instance I have model which is described by torsion angles along a set
of links. The obvious way to get it into Cartesian coordinates is to pass in
the angles, and do rotations. However the set of allowed angles is rather
small. Therefore I can speed it up by precalcuating sines and cosines, but
only at the price of tying my allowed angle set to the conversion routine.
As it happens, the discrete angle set is causing us all types of problems,
so I was able to rewrite the program in about two hours to use continous
angles, to see whether improvement in flexibility was worth it. It would