Darren New wrote:
> Invisible wrote:
>> (Notice that guy who said he couldn't just add a new integer field to
>> a data structure because it would break a few thousand other
>> functions? Does that sound like good abstraction you to?)
> 
> I think that was a few thousand callback functions. I.e., when an event
> happened, it called you with "process_your_event(int1, int2, voidp)" and
> you'd have to recode all those headers.
> 
> (Honestly, I think that would be rather easy, myself.)
> 

It looked like the problem was that the voidp was being free()ed in the
event handler, and the data they wanted to pass into the event handler
was something that couldn't/shouldn't be sent to free(). Maybe copying
that data out to a malloc block would have taken too much time, since it
was for controller inputs.

Post a reply to this message

Warp wrote:
> Darren New <dne### [at] sanrrcom> wrote:
>> I take it you've never seen a program written for a cell phone, a set-top 
>> box, or an MP3 player?
> 
>   Does the iPhone count as one of those?-)

If it's part of operating the phone, sure. If it's an add-on game or 
something, probably less so. When you're trying to cut battery usage so you 
turn off the receiver half-way thru getting a packet because you can tell 
from the first half that you're not interested in the second half, that's 
squeezing out performance.

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

Warp wrote:
>   Hasn't happened to me in, like, a decade.

Me neither. It doesn't mean I like spending the time ensuring it doesn't 
happen. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   Understanding the structure of the universe
    via religion is like understanding the
     structure of computers via Tron.

Post a reply to this message

"Darren New" <dne### [at] sanrrcom> wrote in message
news:4a8dd657$1@news.povray.org...

> http://www.gamasutra.com/view/feature/4111/dirty_coding_tricks.php
>
> I especially like the last one.

If you think programmers are bad:

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

(even if that's not genuine, I've seen enough similar "engineering" hacks).

Post a reply to this message

Invisible schrieb:
> Safe languages don't permit race conditions in the first place.

You're far off from reality there.

Any language that can access a file allows you to program a race 
condition. All you need to do is write two programs to access the same 
file intermittently in a suitable manner.

Any language that can /not/ access a file is useless in practice.

Thus, if safe languages don't permit race conditions in the first place, 
then it follows that safe languages must be useless in practice.

(Some other OS resources will probably qualify as building blocks for a 
race condition generator, too; in this sense, file access is only given 
an example.)

Post a reply to this message

Invisible schrieb:
>>> I especially like the claims of "every time we added debug code, the 
>>> bug went away". Surely it is impossible to work under such conditions...
>>
>> Well, I tell you that's pure reality.
> 
>> 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?

I'm not sure what you mean by this.

If you're saying, "wouldn't this make it impossible to prove that the 
product is working properly", then yes: Such a proof is impossible for 
virtually /every/ real-life product. Welcome to real-world software (and 
hardware) development.

If you're saying, "if you can't get any debug information out of the 
device except for an LED, how can the product be of use anyway?", then 
you're missing the fact that there might be other interfaces to the 
outside world, which just happen to be unavailable for debugging 
information (e.g. they're not initialized yet when the error occurs, or 
the interface protocol provides no means to introduce any "side channel").

Post a reply to this message

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