Ahah, Apple does have different math • Hacker News Board

Re: Ahah, Apple does have different math

#21

Post by tentonova2 » Tue, Jan 05, 2010, 11:15 PM UTC

barrkel wrote: post #20

tentonova2 wrote: post #18

Earlier quoted context omitted.

The stack is not actually aligned on function entry, because the return address is on top, so more alignment will be needed to avoid SSE2 locals being misaligned. The stack has --known alignment-- on entry, which removes the need to compute alignment at runtime. Any other approach requires more instructions overall. It's not so hard for the callee side of the ABI to make sure the stack is aligned if it's going to use…

But instead of aligning the stack in one location, the callee, now it needs to be aligned everywhere. It's pretty probable that's more instructions everywhere. And it's not a "minutely simplified compiler port". That statement is startlingly naive. Do you have any idea how much hand-coded inline assembly, both in the runtime library and in customer code, needs to be carefully reviewed and modified to port from a plat…

But instead of aligning the stack in one location, the callee, now it needs to be aligned everywhere. It's pretty probable that's more instructions everywhere.

SSE2 is used everywhere. That's unlikely.

And it's not a "minutely simplified compiler port". That statement is startlingly naive. Do you have any idea how much hand-coded inline assembly, both in the runtime library and in customer code, needs to be carefully reviewed and modified to port from a platform without this requirement to one with it? Particularly since almost every other platform targeting the same architecture doesn't have the requirement?

Do you have any idea what the advantages are of being able to use SSE2+ everywhere? I find your position to be startling naive, especially given the fact that the vast majority of the existing Mac OS X developer base did not have any hand-coded inline assembly targeted at x86-32.

Other than game developers, how many legacy x86-32 developers is Apple genuinely interested in courting? Even for game developers (or JIT authors, or otherwise) with an overabundance of x86 4-byte-alignment-assuming assembly, fixing stack alignment is an annoying issue, not an impossible one.

Re: Ahah, Apple does have different math

#22

Post by barrkel » Tue, Jan 05, 2010, 11:19 PM UTC

tentonova2 wrote: post #21

barrkel wrote: post #20

Earlier quoted context omitted.

But instead of aligning the stack in one location, the callee, now it needs to be aligned everywhere. It's pretty probable that's more instructions everywhere. And it's not a "minutely simplified compiler port". That statement is startlingly naive. Do you have any idea how much hand-coded inline assembly, both in the runtime library and in customer code, needs to be carefully reviewed and modified to port from a plat…

But instead of aligning the stack in one location, the callee, now it needs to be aligned everywhere. It's pretty probable that's more instructions everywhere. SSE2 is used everywhere. That's unlikely. And it's not a "minutely simplified compiler port". That statement is startlingly naive. Do you have any idea how much hand-coded inline assembly, both in the runtime library and in customer code, needs to be carefully…

Ah yes, Apple doesn't want any more developers for its platform. I forgot about that.

Re: Ahah, Apple does have different math

#23

Post by tentonova2 » Tue, Jan 05, 2010, 11:22 PM UTC

barrkel wrote: post #22

tentonova2 wrote: post #21

Earlier quoted context omitted.

But instead of aligning the stack in one location, the callee, now it needs to be aligned everywhere. It's pretty probable that's more instructions everywhere. SSE2 is used everywhere. That's unlikely. And it's not a "minutely simplified compiler port". That statement is startlingly naive. Do you have any idea how much hand-coded inline assembly, both in the runtime library and in customer code, needs to be carefully…

Ah yes, Apple doesn't want any more developers for its platform. I forgot about that.

No, Apple made a perfectly sane business and technical decision to optimize for their users and existing developer base rather than a small subset of the non-Apple developer base who would have issue with 16-byte stack alignment.

The reasoning makes sense and I'd have done the same. I fixed our code and moved on.

Re: Ahah, Apple does have different math

#24

Post by pmorici » Tue, Jan 05, 2010, 11:37 PM UTC

profquail wrote: post #5

FooBarWidget wrote: post #2

It has been long known that one cannot rely on floating point for precise calculations, e.g. monetary values. One should use integers instead or some kind of other precise representation. But it does surprise me that even on the same CPU architecture you cannot expect every machine to produce the same results.

I concentrated in optimization and numerical analysis for my undergrad degree in Math, and I'm still surprised on a regular basis how many programmers out there don't know about the inaccuracies and errors that come out of floating-point representations.

Are you really that surprised. Crappy programmers abound and many introductory programming classes have students write programs to calculate monetary things using floating point so it's no small wonder many people think it's ok.

Re: Ahah, Apple does have different math

#25

Post by jwr » Tue, Jan 05, 2010, 11:38 PM UTC

profquail wrote: post #5

FooBarWidget wrote: post #2

It has been long known that one cannot rely on floating point for precise calculations, e.g. monetary values. One should use integers instead or some kind of other precise representation. But it does surprise me that even on the same CPU architecture you cannot expect every machine to produce the same results.

I concentrated in optimization and numerical analysis for my undergrad degree in Math, and I'm still surprised on a regular basis how many programmers out there don't know about the inaccuracies and errors that come out of floating-point representations.

My thoughts exactly. Tom Christiansen brings these things up as if they were a huge surprise, but they aren't, or at least shouldn't be.

To put it another way, it isn't Apple doing something wrong. If your code depends on rounding errors in FP representations, your code is buggy.

That's also why good numerical algorithms are hard to design. You need to worry about losing precision. As a simple example, if you calculate (a-b)c and a is almost equal to b, you're much better off doing ac-b*c. These tricks are important.

Re: Ahah, Apple does have different math

#26

Post by Perceval » Tue, Jan 05, 2010, 11:44 PM UTC

profquail wrote: post #3

Tell PG: When I submitted this article, HN stripped the "!" characters out of the title...but I was then able to edit the story and put them back in there. I suppose that means there's a small bug in there somewhere...

It's probably a feature not a bug, designed to automatically de-sensationalize sensationalist titles!!!

Re: Ahah, Apple does have different math

#27

Post by profquail » Wed, Jan 06, 2010, 12:17 AM UTC

Perceval wrote: post #26

profquail wrote: post #3

Tell PG: When I submitted this article, HN stripped the "!" characters out of the title...but I was then able to edit the story and put them back in there. I suppose that means there's a small bug in there somewhere...

It's probably a feature not a bug, designed to automatically de-sensationalize sensationalist titles!!!

Good point (I don't like sensational titles either) -- but shouldn't HN disallow you to edit the title and put them back in then?

Re: Ahah, Apple does have different math

#28

Post by lg » Wed, Jan 06, 2010, 12:48 AM UTC

profquail wrote: post #3

Tell PG: When I submitted this article, HN stripped the "!" characters out of the title...but I was then able to edit the story and put them back in there. I suppose that means there's a small bug in there somewhere...

i think it's because editing doesn't apply the mysterious scrubrules, might be intentional.

Re: Ahah, Apple does have different math

#29

Post by brettnak » Wed, Jan 06, 2010, 12:52 AM UTC

profquail wrote: post #5

FooBarWidget wrote: post #2

It has been long known that one cannot rely on floating point for precise calculations, e.g. monetary values. One should use integers instead or some kind of other precise representation. But it does surprise me that even on the same CPU architecture you cannot expect every machine to produce the same results.

I concentrated in optimization and numerical analysis for my undergrad degree in Math, and I'm still surprised on a regular basis how many programmers out there don't know about the inaccuracies and errors that come out of floating-point representations.

As did, I. I am a professional programmer now and didn't go through the CS school ( To all sophomores out there: We do exist. ) Do they really not teach this sort of thing in a formal CS school?

Re: Ahah, Apple does have different math

#30

Post by wtallis » Wed, Jan 06, 2010, 2:10 AM UTC

brettnak wrote: post #29

profquail wrote: post #5

Earlier quoted context omitted.

I concentrated in optimization and numerical analysis for my undergrad degree in Math, and I'm still surprised on a regular basis how many programmers out there don't know about the inaccuracies and errors that come out of floating-point representations.

As did, I. I am a professional programmer now and didn't go through the CS school ( To all sophomores out there: We do exist. ) Do they really not teach this sort of thing in a formal CS school?

Most CS undergraduate programs in the US suck enough these days that numerical analysis isn't taught at the undergrad level. For example, at my school, undergraduates get to choose between the automata/grammars/computability class and a "numerical methods" class that is really watered down. There is a two-semester undergraduate numerical analysis class, but as I recall it can't count toward your degree except as a general elective. To get numerical analysis to count as a CS elective, you have to take the graduate level class.