Invisible schrieb:
>  From what I've seen, only games programmers go to the extremes of using 
> obscure and elaborate low-level hackery to squeeze every last 
> femtosecond of performance out of the machine.

Those, and embedded software developers.

Post a reply to this message

Warp schrieb:
>   Well, sometimes it is useful to be able to poke at memory directly.
> For example, changing the sign of a floating point value is much faster
> by flipping that one bit at the end of it than doing it with the FPU.
> (Of course after this little trick your program will assume IEEE floating
> point numbers. But for many purposes that suffices.)

I would think that a good optimizing compiler would translate something 
like "x = -x;" to equally efficient code...?

Post a reply to this message

somebody schrieb:
> http://www.slipperybrick.com/2007/09/airline-seatbelt-engine-straps/

I cannot imagine this to be genuine: At the speed at which aircraft 
engines operate, these straps would either /be/ torn to pieces, or /do/ 
tear the blades to shreds.

The blades don't look that good either, so I'd expect the engine to just 
disintegrte impressively anyway next time it is operated at full throttle.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I would think that a good optimizing compiler would translate something 
> like "x = -x;" to equally efficient code...?

  Out of curiosity, I tested how gcc compiles this function with maximum
optimizations (-O3 -ffast-math -march=native):

void negate(double* values, unsigned amount)
{
    for(unsigned i = 0; i < amount; ++i)
        values[i] = -values[i];
}

  The relevant part of the asm output was:

	xorl	%eax, %eax
.L7:
	fldl	(%edi,%eax,8)
	fchs
	fstpl	(%edi,%eax,8)
	addl	$1, %eax
	cmpl	%eax, %esi
	ja	.L7

  So it is loading the values into the FPU one by one, negating them there
and then storing them back into RAM.

-- 
                                                          - Warp

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> somebody schrieb:
> > http://www.slipperybrick.com/2007/09/airline-seatbelt-engine-straps/

> I cannot imagine this to be genuine: At the speed at which aircraft 
> engines operate, these straps would either /be/ torn to pieces, or /do/ 
> tear the blades to shreds.

> The blades don't look that good either, so I'd expect the engine to just 
> disintegrte impressively anyway next time it is operated at full throttle.

  Genuine and genuine. It depends on your definition of "genuine".

  It *is* a genuine photograph in the sense that it's an unmanipulated
photo of an actual situation (ie. not staged for this photo in question).

  What is "not genuine" is just the false impression it gives. In other
words the real reason for the straps to be there may not be immediately
obvious to the viewer, thus the viewer gets confused and the wrong
impression, making this *perception* "not genuine".

  The real explanation for the straps is quite simple: They keep the blades
in place for transport of the engine, so that they don't rotate freely
during transport. The engine in this photo has probably just been readied
to be transported to maintenance or scrapping.

-- 
                                                          - Warp

Post a reply to this message

On 22-8-2009 9:54, Warp wrote:
> clipka <ano### [at] anonymousorg> wrote:
>> I would think that a good optimizing compiler would translate something 
>> like "x = -x;" to equally efficient code...?
> 
>   Out of curiosity, I tested how gcc compiles this function with maximum
> optimizations (-O3 -ffast-math -march=native):
> 
> void negate(double* values, unsigned amount)
> {
>     for(unsigned i = 0; i < amount; ++i)
>         values[i] = -values[i];
> }
> 
>   The relevant part of the asm output was:
> 
> 	xorl	%eax, %eax
> .L7:
> 	fldl	(%edi,%eax,8)
> 	fchs
> 	fstpl	(%edi,%eax,8)
> 	addl	$1, %eax
> 	cmpl	%eax, %esi
> 	ja	.L7
> 
>   So it is loading the values into the FPU one by one, negating them there
> and then storing them back into RAM.

For comparison, how would you code the bit reversal routine?
Then explain why that would be faster?
Will that differ on 32 and 64 bit architectures?
Will the result differ for exceptional cases: NaN, inf, subnormal 
numbers and 0? If so which implementation is more 'correct'?

Post a reply to this message

Am Sat, 22 Aug 2009 04:00:17 -0400 schrieb Warp:

>   Genuine and genuine. It depends on your definition of "genuine".
> 
>   It *is* a genuine photograph in the sense that it's an unmanipulated
> photo of an actual situation (ie. not staged for this photo in
> question).

Indeed:

http://www.snopes.com/photos/airplane/airchina.asp

Post a reply to this message

Florian Pesth schrieb:
>>   It *is* a genuine photograph in the sense that it's an unmanipulated
>> photo of an actual situation (ie. not staged for this photo in
>> question).
> 
> Indeed:
> 
> http://www.snopes.com/photos/airplane/airchina.asp

That's indeed a more credible background story (though I don't doubt 
many people would think otherwise, and readily believe the Air China story).

Post a reply to this message

Invisible wrote:
> Wouldn't this make it scientifically impossible to deliver a working 
> product?

The more complex a project is, the greater the likelihood of bugs appearing.

The more bugs there are, the more likely they are to be hard to find.

Some bugs are so infrequent, and so well hidden, that it would take the 
equivalent of dozens (or hundreds) of man-years to find them.  True, 
"with enough eyes all bugs are shallow," but sometimes the requisite 
number of eyes is just infeasible.

And it's perfectly possible to deliver a working product that has bugs 
in it ;)

...Chambers

Post a reply to this message

On Fri, 21 Aug 2009 15:08:27 +0100, Invisible wrote:

>> Yeah, it's kind of fun developing software for devices where
>> occasionally the only way to get any helpful debug information out of
>> the thing is by switching an LED on or off, and errors might just as
>> well be hardware-related.
> 
> Wouldn't this make it scientifically impossible to deliver a working
> product?

Clearly not, since such products exist. ;-)

Jim

Post a reply to this message