Live data from Hacker News

Revisiting the Business Card Raytracer

fabiensanglard.net

11–20 of 54 posts

Re: Revisiting the Business Card Raytracer

#11
post #9
post #5

i love what fabien is doing with his website! also been experimenting with pure html with an itsy-bitsy amount of css. for months now i wondered how to display code without involving javascript. that textarea is so perfect! and i bet you when you copy and paste into word or your todo list application they won't even try to be "smart" about knowing what "rich text" is... that's very cool.

i am glad that there is a small village of indomitable developers holding out against tens of megabytes of reactive functional progress modern javascript frameworks. thank you

There is a place for both.

Re: Revisiting the Business Card Raytracer

#13
post #2

101,000ms to 150ms is a phenomenal speedup. Props

To be fair, the thing he started with was totally unreadable and fits on a business card and the thing he ended up with was readable, but didn't fit. It isn't apples-to-apples.

The original is 1,287 bytes after removing comments and line endings where possible. After just a bit of search-and-replace to shrink variable names, I got the new one down to 2,373 bytes including the same error checking and output at the end. So 1.8 business cards, which is not too bad.

And no I haven't tried to compile it. https://pastebin.com/LDRd6U4e

Re: Revisiting the Business Card Raytracer

#14
post #8
post #7

Earlier quoted context omitted.

Yeah, use of SSE registers does not imply SIMD, since x87 is gone in x86-64, so even scalar FP has to use SSE registers. The asm snippets for v::operator*() in the "Optimization level 1" section use scalar SSE arithmetic only (mulss). (There's some use of movaps to move data around, but it's a stretch to call that SIMD.) I think the "leverage" sentence you quoted and the "with SIMD taken care of" one shortly after ar…

> since x87 is gone in x86-64, so even scalar FP has to use SSE registers. No, it’s still there. What’s actually going on is that all x86-64 CPUs support SSE2, so there is little reason to use x87 in 64-bit code. (You can use it for 80-bit precision. OTOH, for most purposes, 80-bit precision is actively harmful, and x87 is an incredible mess, so almost no one wants it.)

You're right - thanks for the correction!

Re: Revisiting the Business Card Raytracer

#16
post #6

> Opening the binary with Binary Ninja revealed that clang had already managed to leverage the SSE registers. X86-64 uses SSE registers for all floating point operations. I'm not sure that the author realized that they were looking at an -O0 binary. -O0 does not do vectorization (or anything else for that matter).

Looking at it on Godbolt, it doesn't really leverage SSE on -O3, either. You can get a reasonable grasp of whether it's using SSE effectively or not just by looking at the instruction names. mulss: multiplication of a single single-precision floating point value. mulsd: multiplication of a single double-precision floating point value. mulps: multiplication of a packed group of single-precision floating point values.…

Off topic: I teach compilers in high school and godbolt.org looks amazing, thanks for the link!

Re: Revisiting the Business Card Raytracer

#17
post #6

Earlier quoted context omitted.

Looking at it on Godbolt, it doesn't really leverage SSE on -O3, either. You can get a reasonable grasp of whether it's using SSE effectively or not just by looking at the instruction names. mulss: multiplication of a single single-precision floating point value. mulsd: multiplication of a single double-precision floating point value. mulps: multiplication of a packed group of single-precision floating point values.…

Off topic: I teach compilers in high school and godbolt.org looks amazing, thanks for the link!

Wow, really cool that there are high schools teaching compilers.

Re: Revisiting the Business Card Raytracer

#18
post #11
post #9

Earlier quoted context omitted.

i am glad that there is a small village of indomitable developers holding out against tens of megabytes of reactive functional progress modern javascript frameworks. thank you

There is a place for both.

It’s not so much that there’s a place for both rather than both necessarily exist as two points in the same space.

But the reality is that more websites than not these days will send you many megabytes of JS, mainly for the purpose of tracking you and extracting money/time from you, under the guise of “user experience”.

So when I see some of those rare people who still actually care about quality, speed, performance, accessibility, etc I make sure to appreciate their work.

Re: Revisiting the Business Card Raytracer

#19
post #8
post #7

Earlier quoted context omitted.

Yeah, use of SSE registers does not imply SIMD, since x87 is gone in x86-64, so even scalar FP has to use SSE registers. The asm snippets for v::operator*() in the "Optimization level 1" section use scalar SSE arithmetic only (mulss). (There's some use of movaps to move data around, but it's a stretch to call that SIMD.) I think the "leverage" sentence you quoted and the "with SIMD taken care of" one shortly after ar…

> since x87 is gone in x86-64, so even scalar FP has to use SSE registers. No, it’s still there. What’s actually going on is that all x86-64 CPUs support SSE2, so there is little reason to use x87 in 64-bit code. (You can use it for 80-bit precision. OTOH, for most purposes, 80-bit precision is actively harmful, and x87 is an incredible mess, so almost no one wants it.)

> 80-bit precision is actively harmful

How comes? Unexpected clipping when converting back and forth to 64bits?

Re: Revisiting the Business Card Raytracer

#20
post #5

i love what fabien is doing with his website! also been experimenting with pure html with an itsy-bitsy amount of css. for months now i wondered how to display code without involving javascript. that textarea is so perfect! and i bet you when you copy and paste into word or your todo list application they won't even try to be "smart" about knowing what "rich text" is... that's very cool.

Yeah, damn, I thought I'd done well getting my page+css+font down to ~100kB (css/font cached after first load, so ~2kB on subsequent pages) but his site is tiny. Even with his CSS inlined to save a request the entire page is 15kB gzipped.
Post reply on HN