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

Optimizing the Particle Life: From 400 to 4M particles

programmingattack.com

Post reply on HN
Print view View original

61–70 of 71 posts

Re: Optimizing the Particle Life: From 400 to 4M particles

#61

Post by _neil »

bee_rider wrote: post #15

Since I’m on my phone, I can only try the 2D js versions, but the quadtree version does seem to provide some really obvious and nice frame rate improvements. It seems like good work, although I don’t know much about this field. Sidenote: I’m often too self conscious to put anything technical online with my real name on it, probably a bit of imposter syndrome or something. I think based on > For one of my programming…

Give yourself to the embarrassment. Publish for your past self. Or publish for someone smarter to come along and correct you.

(Currently trying to take this advice as well)

Re: Optimizing the Particle Life: From 400 to 4M particles

#62

Post by Etheryte »

Twirrim wrote: post #51
bscottmay wrote: post #39

Earlier quoted context omitted.

Yeah, an all-numpy version runs in less than 1ms on my M1 air import numpy as np l = 10_000 t = np.empty(l, dtype=np.float32) j = np.arange(l) t = 0.02 \* j t *= (0.03 * j) t -= (0.04 \* j) t /= 0.05 \* (j + 1)

So rather than spend 10-20 minutes reading about numpy, the author wrote 3 other implementations...? The fact that they ran the C code without the optimisation flags and compared it that way makes me think Javascript was what they actually wanted to write this one in anyway.

The author, by the looks of it from the article, is a uni student. Rather than straw-manning this into a language war, we should laude the fact that they managed to write the same thing in a number of different languages to begin with.

Re: Optimizing the Particle Life: From 400 to 4M particles

#63

Post by jlarocco »

jasonjmcghee wrote: post #53
wzdd wrote: post #6

Earlier quoted context omitted.

Simply compiling it with -O3 produces something which completes in half the time of the JavaScript version (350ms for C, 750ms for JS), so perhaps that. Edit for Twirrim: on this system (Ryzen 7, gcc 11): "-O3": 350ms; "-O3 -march=native": 208ms; "-O2": 998ms; "-O2 -march=native": 1040ms. Edit 2: Interestingly, changing the C from float to double produces a 3.5x speedup, taking the time elapsed (with "-O3 -march=nati…

Seems crazy to me that double would produce that kind of speed up. Is float getting emulated somehow? Don't they end up the same size?

> Don't they end up the same size?

No. Float is half the size of double.

Re: Optimizing the Particle Life: From 400 to 4M particles

#65

Post by nickpsecurity »

Twirrim wrote: post #52
Tadpole9181 wrote: post #35

Earlier quoted context omitted.

They didn't use any optimization flags.

Yeah, I was just trying to show the difference. Doing it without optimisation flags is an utterly bewildering decision by the author.

Especially given the goal was increasing performance.

Re: Optimizing the Particle Life: From 400 to 4M particles

#66

Post by alook »

_neil wrote: post #61
bee_rider wrote: post #15

Since I’m on my phone, I can only try the 2D js versions, but the quadtree version does seem to provide some really obvious and nice frame rate improvements. It seems like good work, although I don’t know much about this field. Sidenote: I’m often too self conscious to put anything technical online with my real name on it, probably a bit of imposter syndrome or something. I think based on > For one of my programming…

Give yourself to the embarrassment. Publish for your past self. Or publish for someone smarter to come along and correct you. (Currently trying to take this advice as well)

Love this advice. I’ve always struggled with the same thing.

One friend started telling me to get over myself and publish, then he reworded it to:

“Get over being under yourself.”

For some reason that one stuck with me and gave me the strength to ship my first few pieces of writing.

Re: Optimizing the Particle Life: From 400 to 4M particles

#67

Post by suby »

jlarocco wrote: post #63
jasonjmcghee wrote: post #53

Earlier quoted context omitted.

Seems crazy to me that double would produce that kind of speed up. Is float getting emulated somehow? Don't they end up the same size?

> Don't they end up the same size? No. Float is half the size of double.

My intuition would have been that floats were faster because of this. Less memory to iterate through.

Re: Optimizing the Particle Life: From 400 to 4M particles

#68

Post by sllabres »

abainbridge wrote: post #40
anon946 wrote: post #4

IMO, not using any optimization flags with C is somewhat arbitrary, since the compiler writers could have just decided that by default we'll do thing X, Y, and Z, and then you'd need to turn them off explicitly. FWIW, without -O, with -O, and with -O4, I get 2500ms, 1500ms, and 550ms respectively. I didn't bother to look at the .S to see the code improvements. (Of course, I edited the code to output the results, othe…

One optimization for the C code is to put "f" suffixes on the floating point constants. For example convert this line: t[i] += 0.02 * (float)j; to: t[i] += 0.02f * (float)j; I believe this helps because 0.02 is a double and doing double * float and then converting the result to float can produce a different answer to just doing float * float. The compiler has to do the slow version because that's what you asked for.…

"I'm never sure what -ffast-math does exactly."

Me too when I am away from C for a while. The topic has been on HN [3]

* Enable the use of SIMD instructions

* alter the behavior regarding NaN (you can't even check for NaN afterwards with isnan(f))

* alter the associativity of expression a+(b+c) might become (a+b)+c which seems inconspicuous at first, but there are exceptions (as example see [1] under -fassociative-math)

* change subnormals to zero (even if your program isn't compiled with this option, but a library you link to your program).

A nice overview from which I summarize is in [1] which contains a link to [2] with this nice text:

"If a sufficiently advanced compiler is indistinguishable from an adversary, then giving the compiler access to -ffast-math is gifting that enemy nukes. That doesn’t mean you can’t use it! You just have to test enough to gain confidence that no bombs go off with your compiler on your system"

[1] https://simonbyrne.github.io/notes/fastmath/

[2] https://discourse.julialang.org/t/when-if-a-b-x-1-a-b-divide...

[3] https://news.ycombinator.com/item?id=29201473 (107)

Re: Optimizing the Particle Life: From 400 to 4M particles

#69

Post by Etheryte »

CyberDildonics wrote: post #38
caranea wrote: post #33

Earlier quoted context omitted.

One point needs correcting though - nowhere in the article I say that node is outperforming C, on the contrary - I stressed that I didn't use any flags so that people don't come to a conclusion that C would be always slower, and I explicitly mentioned not get fixated on such benchmarks. What it was meant to show is that V8 is *good enough* to even consider it for the job :)

You benchmarked three different programs and one was compiled to be slow. Why give times for a debug build when the other two aren't? Showing off performance metrics that are both apples to oranges while also giving times for something not made to run fast is total nonsense. Do you really not think this is a mistake? Most people would see C getting outperformed and realize there is something wrong. I'm shocked anyone…

Touch grass my man, you're putting down a CS student's cool project over what compiler flags they used.

Re: Optimizing the Particle Life: From 400 to 4M particles

#70

Post by fartsucker69 »

suby wrote: post #67
jlarocco wrote: post #63

Earlier quoted context omitted.

> Don't they end up the same size? No. Float is half the size of double.

My intuition would have been that floats were faster because of this. Less memory to iterate through.

it is faster in just about every way. less memory, even the cpu instructions (which are usually not the problem) are faster. there's something fucky going on with code gen here. or it could also simply be the measurement procedure that is doing something weird like working with not properly cold or equally warmed up data or instruction caches.
Post reply on HN