On Tue, 17 Oct 2000 16:44:34 -0500, in povray.advanced-users you wrote:

>David Wilkinson wrote:
>
>>       #debug concat(A1[Rowcount][Colcount])
>
>Why concatenate one string? :)

You're right David, concatenation is  absolutely redundant, although it does no
harm in this instance.  It's a good example of how bugs arise when you are
re-using code and don't think it through carefully enough :-)
----------------------
dav### [at] hamiltonitecom
http://hamiltonite.com/

Post a reply to this message

Pabs <pab### [at] hotmailcom> wrote:
: Maybe they thought that the compiler would insert instructions to convert an
: int to a double at runtime, unlikely though it is?

  Current compilers can do lots of optimizations. Some of them are even
surprising.
  I was once debugging this kind of code (in C++):

int main()
{
    int i = 1;
    cout << i << endl;
}

  It was very strange since the debugger didn't execute the 'int i=1;' line
at all and it didn't even show the value of the variable 'i'.
  I thought that "what the **** is wrong with this?" until I realized that
I had all compile optimizations turned on. I turned them off and then the
debugging worked as expected.

  What happened was that the optimizations made by the compiler had converted
the above code to one equivalent to this:

int main()
{
    cout << 1 << endl;
}

  The compiler had completely wiped out the 'i' variable and that's why the
debugging looked so strange :)

  Btw, too many times I see code like this:

a = var>>2;  // equivalent to: a = var/4;

  The idea is that shifting is usually a lot faster than dividing so people
optimize by hand in this way.
  This, however, is nowadays made in vain and makes only the code harder to
read. I'd say that every current C(++) compiler can internally optimize this:

a = var/4;

to this:

a = var>>2;

so it's not necessary to do it by hand.

  Sometimes the optimizations made by a compiler are just marvelous. For
example most implementations of gcc convert this kind of code:

(var << 5)|(var >> 27);

(supposing that 'var' is an unsigned int of size 32 bits)
to this (in assembler):

rol [Variable], 5

(ie. "rotate the value [Variable] to the left 5 positions").

  In C there's no operation to rotate values like in most assemblers so you
have to do it with two shifts and one or.
  It's just incredible how the compiler can figure out that what you are
actually trying to do is a rotation and compiles the rather complex command
into one rotation assembler instruction (instead of two shifts and an or).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Hi Warp, you recently wrote in povray.advanced-users:

>   I have seen this written in C:
> 
> double x = (double)(1.0);
> 
>   I'm just wondering why this wasn't enough:
> 
> double x = 1;

Maybe the programmer previous written that line as

DBL x = (DBL) 1.0;

and had DBL defined as float, but didn't want to add the 'f' onto the
1.0.

Then he did a global search and replace and replaced DBL with double?

- Lutz
  email : lut### [at] stmuccom
  Web   : http://www.stmuc.com/moray

Post a reply to this message

Lutz Kretzschmar <lut### [at] stmuccom> wrote:
: Then he did a global search and replace and replaced DBL with double?

  Why would he do that?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

David Wilkinson wrote:

> You're right David, concatenation is  absolutely redundant, although it does no
> harm in this instance.  It's a good example of how bugs arise when you are
> re-using code and don't think it through carefully enough :-)

Hmm, sounds like MS...

--
David Fontaine  <dav### [at] faricynet>  ICQ 55354965
My raytracing gallery:  http://davidf.faricy.net/

Post a reply to this message

Warp wrote:

> Pabs <pab### [at] hotmailcom> wrote:
> : Maybe they thought that the compiler would insert instructions to convert an
> : int to a double at runtime, unlikely though it is?
>   It's just incredible how the compiler can figure out that what you are
> actually trying to do is a rotation and compiles the rather complex command
> into one rotation assembler instruction (instead of two shifts and an or).

Ever seen the sh*t f**cking code msvc produces with no optimisations for things
like the following?
++i;
the code is something like (I'm not to proficient in assembly so don't tease)
mov eax, i
add eax, 1
mov i, eax
The side effect is what we want since the value returned by the operator is just
discarded
What a waste of clock cycles - even I could tell you that
inc i
or something similar would achieve the desired result
Just because its compiled in debug mode doesn't mean I want the code to be bloated
like a bl**dy f**cking pig.
Grrrrrrrrrrrr!
Death to M$VC & M$ - NOW
--
Bye
Pabs

Post a reply to this message

In article <39ed87d0@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

> (supposing that 'var' is an unsigned int of size 32 bits)
> to this (in assembler):

Ah, so you are learning assembler (variants) now...

> rol [Variable], 5
>
> (ie. "rotate the value [Variable] to the left 5 positions").

Just curious, which architecture were you compiling for here?

>   In C there's no operation to rotate values like in most assemblers so you
> have to do it with two shifts and one or.

Yes, and there are many more tricks:

main:
 addi $0, $0, 10
 addi $1, $1, 15
 andi $2, $2, 0
 andi $3, $3, 0
for:
 andi $2, $2, 0
 beq  $0, $2, ret
 srl1 $0, $0
 sll1 $1, $1
 andi $2, $0, 1
 subi $2, $2, 1
 not  $2, $2
 and  $2, $1, $2
 add  $3, $3, $2
 j    for
ret:
 j    ret


Assume j is a unconditional jump, and srl1/sll1 are logical right/left
shifts by one bit.  Further assume all values are unsigned 8 bit ints.  $0
to $3 are registers (MIPS assembly notation), your input is in $0 and $1,
and the result is in $2.

What is this program doing?


   Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <39EE5D5E.CCAB2069@hotmail.com> , Pabs <pab### [at] hotmailcom>  
wrote:

> Ever seen the sh*t f**cking code msvc produces with no optimisations for
> things like the following?
> ++i;

Maybe it is optimising, but in a different way than you expect. On the one
hand "i" might be needed somewhere else and inc i could only work on
register variables (sorry, I don't know x86 assembler too well).  This doing
either would give the same performance.  Especially if "i" is stored in a
rather complicated place or only used once, or a global variable, or a
million other things.

Or it might well be that the sequence it generates executes faster on modern
processors that translate your code to internal RISC-like instructions (like
P6 and later do).  Why come to this conclusion?

Well, what you see is a load/store (i.e. most RISC processors) way of
handling the problem.  Basically a load/store architecture based processor
will not have complex operations that work on memory and data at the same
time.  Everything first has to be loaded into a register, then it will be
processed and then placed back in memory.  This is usually more efficient
because these processors have much larger register files, 32 or even 64
registers compared to the 8 registers a x86 has.


    Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <39ee868d$1@news.povray.org> , "Thorsten Froehlich" 
<tho### [at] trfde> wrote:

> and the result is in $2.

Correction: the result is in $3 or cousre.  And btw, you may assume all
registers are inited to 0.


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
: Maybe it is optimising, but in a different way than you expect. On the one
: hand "i" might be needed somewhere else and inc i could only work on
: register variables (sorry, I don't know x86 assembler too well).

  The 'inc' instruction works also directly with memory locations
(ie. variables) but is slower than an 'inc' on a register. But of course
loading the variable first on a register, incrementing the register and
then storing the register on the variable is not faster (it's actually slower,
I think).
  And besides, if it's not optimizing (as the original poster said), it
should generate the simplest code, not the fastest.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):_;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message