Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ahah, Apple does have different math

nntp.perl.org

Post reply on HN
Print view View original

31–37 of 37 posts

Re: Ahah, Apple does have different math

#31

Post by ars »

ajross wrote: post #6

This isn't a new problem. The 80-bit internal 8087 FPU precision has always been a mismatch for the 64 bit IEEE double representation, even before the presence of SSE registers (which don't have the 80 bit mode) complicated things. Intel 8087 code has always been able to produce different results for the same source code, depending on when/whether/which intermediate results get spilled to memory. The Motorola 68k FPU…

For people unfamiliar with this, "spilled to memory" means rounded to 64 bits (from 80).

x87 does floating point math with 80 bits (in registers). But the variables are stored in memory locations with 64 bits. So the results are rounded.

The problem comes from when to do the rounding. And that can vary depending on if a register is needed for something else, optimizations, the order of code, etc.

Re: Ahah, Apple does have different math

#32

Post by echaozh »

profquail wrote: post #27
Perceval wrote: post #26

Earlier quoted context omitted.

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?

Few people would come back and add the sensation back. If they do, they must have thought about it and been more rational.

Re: Ahah, Apple does have different math

#33

Post by sailormoon »

notauser wrote: post #11
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...

You can also use Unicode in comments, which may or ʎɐɯ ʇou be a bug but did surprise me.

Why on earth would the ability to use unicode in comments be a bug? Seems like a basic feature of any modern site.

Re: Ahah, Apple does have different math

#34

Post by ssp »

9oliYQjP wrote: post #15

Apple doesn't use the x87 floating point unit. They've never needed to because they can rely on the SSE2 unit since any Intel Mac ever created has one. This isn't necessarily the case on the PC even though every modern one will have it as well. I'm pretty sure gcc is set to compile floating point numbers using a SSE2 code-path by default on OS X.

One pedantic correction: SSE is the 4-wide floating point instruction set. SSE2 added integer instructions using the same registers.

Re: Ahah, Apple does have different math

#35

Post by barrkel »

tentonova2 wrote: post #23
barrkel wrote: post #22

Earlier quoted context omitted.

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.

The vote is clearly in, and the majority is siding with Apple. I haven't changed my position, though, and the more you write in this thread, the more convinced I am that you don't know what you're talking about. The technical reasons are not strong; SSE2 is primarily for floating point ops and SIMD vectorized ops. Most user code does not use floating point, and it's hard for compilers to extract latent parallelism to produce vectorized code.

However, if you put the technical reasons aside, and only focus on the business reasons for making a choice here, it's clear to me that the best way to go is to fall in line with the existing precedents for the platform. That way maximizes your business upside. There is no business reason for wanting 16-byte alignment, only business reasons for not wanting it.

The technical case would need to outweigh the business case in order for it to win. But I don't see the technical case as being that strong. Floating point code is rare. Outside of scalable vector-oriented UI libraries and domain-specific number crunching, it's hardly ever used. Many architectures survived for decades with only optional support for floating point, in a coprocessor. Many embedded architectures still use emulated FP, if it's needed at all.

And I really meant it about shockingly naive back there. It tells me everything I need to know about what you know about commercial compilers: that you think of them in the academic sense of being the bit that turns text into code. There's more to it than that in the real world.

Re: Ahah, Apple does have different math

#36

Post by wendroid »

On plan9

    Trying compiler constants first...

    f  is 0.12345, rounded to 0.1235, expanded to 0.123450003564357760000000000000
    d  is 0.12345, rounded to 0.1235, expanded to 0.123450000000000000000000000000
    ld is 0.12345, rounded to 0.1235, expanded to 0.123450000000000000000000000000

    Now trying derived values...

    f  is 0.12345, rounded to 0.1235, expanded to 0.123450003564357760000000000000
    d  is 0.12345, rounded to 0.1235, expanded to 0.123450000000000000000000000000
    ld is 0.12345, rounded to 0.1235, expanded to 0.123450000000000000000000000000
So don't blame the architecture

Re: Ahah, Apple does have different math

#37

Post by [deleted] »

barrkel wrote: post #35
tentonova2 wrote: post #23

Earlier quoted context omitted.

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.

The vote is clearly in, and the majority is siding with Apple. I haven't changed my position, though, and the more you write in this thread, the more convinced I am that you don't know what you're talking about. The technical reasons are not strong; SSE2 is primarily for floating point ops and SIMD vectorized ops. Most user code does not use floating point, and it's hard for compilers to extract latent parallelism to…

[deleted]
Post reply on HN