Live data from Hacker News

Even faster asin() was staring right at me

16bpp.net

21–30 of 68 posts

Re: Even faster asin() was staring right at me

#21
post #3

I think it is `atan` function. Sin is almost a lookup query.

On modern machines, looking things up can be slower than recomputing it, when the computation is simple. This is because the memory is much slower than the CPU, which means you can often compute something many times over before the answer from memory arrives.

Not just modern machines, the Nintendo64 was memory bound under most circumstances and as such many traditional optimizations (lookup tables, unrolling loops) can be slower on the N64. The unrolling loops case is interesting. Because the cpu has to fetch more instructions this puts more strain on the memory bus.

If curious, On a N64 the graphics chip is also the memory controller so every thing the cpu can do to stay off the memory bus has an additive effect allowing the graphics to do more graphics. This is also why the n64 has weird 9-bit ram, it is so they could use a 18-bit pixel format, only taking two bytes per pixel, for cpu requests the memory controller ignored the 9th bit, presenting a normal 8 bit byte.

They were hoping that by having high speed memory, 250 mHz, the cpu ran at 90mHz, it could provide for everyone and it did ok, there are some very impressive games on the n64. but on most of them the cpu is running fairly light, gotta stay off that memory bus.

https://www.youtube.com/watch?v=xFKFoGiGlXQ (Kaze Emanuar: Finding the BEST sine function for Nintendo 64)

Re: Even faster asin() was staring right at me

#25

> It also gets in the way of elegance and truth. That’s quite subjective. I happen to find trigonometry to be elegant and true. I also agree that trigonometric functions lack efficiency in software.

>> It also gets in the way of elegance and truth.

Where did that come from in the article?

Re: Even faster asin() was staring right at me

#26
post #18
post #12

Earlier quoted context omitted.

Interesting. About 20 years ago, it must have been the other way around because I remember this paper [1] where the authors were able to speed up the log function by making use of a lookup table in the CPU cache. [1] https://www.researchgate.net/profile/Nikki-Mirghafori/public...

It........depends. I make things faster all the time by leveraging various CPU caches, sometimes even disk or networked disks. As a general principle though, memory lookups are substantially slower than CPU (and that has indeed changed over time; a decade or three ago they were close to equal), and even cache lookups are fairly comparatively slow, especially when you consider whole-program optimization. That isn't to…

Logarithms are interesting because there's hardware to approximate them built into every modern processor as part of floating point. If you can accept the error, you can abuse it to compute logs with a single FMA.

An example of an exp and a log respectively from my personal library of bit hacks:

    bit_cast((int32_t)(fma(12102203.2f, x, 0x3f800000)));

    bit_cast((uint32_t)(-0x3f800000 - 36707.375f*x)) + 7;

Re: Even faster asin() was staring right at me

#27

I haven't kept up with C++ in a few years - what does constexpr do for local variables? constexpr double a0 = 1.5707288;

The compiler can substitute the value how it sees fit. It's like #define, but type-safe and scoped. Maybe it's folded into expressions, propagated through constant expressions, or used it in contexts that require compile-time constants (template parameters, array sizes, static_assert, other constexpr expressions). I mean, not in this case of pi/2, where it's more about announcing semantics, but in general those are t…

It can do this with const too or even a normal variable that just happens to not vary.

Re: Even faster asin() was staring right at me

#28
post #21
post #3

Earlier quoted context omitted.

On modern machines, looking things up can be slower than recomputing it, when the computation is simple. This is because the memory is much slower than the CPU, which means you can often compute something many times over before the answer from memory arrives.

Not just modern machines, the Nintendo64 was memory bound under most circumstances and as such many traditional optimizations (lookup tables, unrolling loops) can be slower on the N64. The unrolling loops case is interesting. Because the cpu has to fetch more instructions this puts more strain on the memory bus. If curious, On a N64 the graphics chip is also the memory controller so every thing the cpu can do to stay…

The N64 was a particularly unbalanced design for its era so nobody was used to writing code like that yet. Memory bandwidth wasn't a limitation on previous consoles so it's like nobody thought of it.

Re: Even faster asin() was staring right at me

#29

I haven't kept up with C++ in a few years - what does constexpr do for local variables? constexpr double a0 = 1.5707288;

It is required to be evaluated at compile time, and it's const.

An optimizing compiler might see through a non-constexpr declaration like 'double a0 = ...' or it might not. Constexpr is somewhat more explicit, especially with more complicated initializer expressions.

Re: Even faster asin() was staring right at me

#30

> It also gets in the way of elegance and truth. That’s quite subjective. I happen to find trigonometry to be elegant and true. I also agree that trigonometric functions lack efficiency in software.

>> It also gets in the way of elegance and truth. Where did that come from in the article?

I revisited that article and ... now I have no idea. Maybe I stumbled into some other trig-related article and came back here. Or maybe this one had some A/B content going on?

The only thing I remember at this point is that I copied and pasted that sentence (I didn't type it.) Even search doesn't find the sentence anywhere but HN.

Post reply on HN