Re: Ambiguities in VRML-Syntax
Stephen Chenney ([email protected])
Mon, 4 Dec 1995 14:21:47 -0800 (PST)
- Messages sorted by:
[ date ][ tmesad ][ subject ][ author ]
- Next message:
Stephen Chenney: "Re: Ambiguities in VRML-Syntax"
- Previous message:
James Black: "Re: Role of copyright in innovation"
- In reply to:
Antmeopohedron: "Re: Ambiguities in VRML-Syntax"
- Next in thesad:
Stephen Chenney: "Re: Ambiguities in VRML-Syntax"
> }
> } Besides, the IF statement will compile much smaller than the multiplication
> } (even under an optimizing compiler).
>
> Say what? An if statement requires at a minimum a branch instruction and an
> instruction for each of the assignments, plus an unconditional jump after
> one of the assignments, four instructions, i.e.
>
> BRANCH on <boolean> to <true clause>
> STORE <variable> value 0
> JUMP to <snd of true clause>
> true clause:
> STORE <variable> value 2
> snd of true clause:
>
> A multiply will by one instruction if the multiply instruction can do its
> own memory storing, two if it can't:
>
> MULTIPLY <boolean> by 2 into <register or <variable>>
> #and, if MULTIPLY does not do memory storage:
> STORE <variable> from <register>
>
> In addition, execution speed is slowed by a branch instruction due to
> today's pipelined RISC chips. There are advantages to the MULTIPLY over the
> IF, *especially* if this code will be run (looped, most likely) over and
> over. This is a hand optimization, not something the compiler can do. Do we
> want efficient coding techniques available, or do we simply want to count
> on unlimited computing power?
>
> <UNNECESSARY AND FRUSTRATED FLAME>
> Take a class on it and try again!
> </UNNECESSARY AND FRUSTRATED FLAME>
Mmm. You should be more careful when you make statements like this. The
branch will be faster than the multiply. No question at all.
Multiply > 4 cycles, probably, particularly if it involves FP conversion.
Branch < 3 cycles, with stalls, and maybe 1 with correct branch
prediction (95% of cases). If you are talking a loop, then the branch
will frequently be predicted right, with no branch penalty.
Anyone who designs a modern CPU with a branch that is slower than a multiply
should be shot. Most applications branch more than they multiply. Note I
say "most", not all.
Finally, if the compiler knows that the multiplication is by s constant,
and it knows the latency of the multiply, it can replace the multiply
by s sequence of shifts and adds. Don't laugh, gcc does this on an HP,
compiling with -O. That would be faster than the branch, probably. Depsnds
on register allocation and so on.
Modern processors have such complex dynamic behaviour that statements of
the type you made are no longer valid. There are too many factors that
can bring you down in flames.
Maybe you should take a class. Don't bother telling me to, I just did. ;-)
Steve.
- Next message:
Stephen Chenney: "Re: Ambiguities in VRML-Syntax"
- Previous message:
James Black: "Re: Role of copyright in innovation"
- In reply to:
Antmeopohedron: "Re: Ambiguities in VRML-Syntax"
- Next in thesad:
Stephen Chenney: "Re: Ambiguities in VRML-Syntax"