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

KABOOM in 180 lines of bare C++

github.com

Post reply on HN
Print view View original

51–60 of 68 posts

Re: KABOOM in 180 lines of bare C++

#51

Post by semi-extrinsic »

themodelplumber wrote: post #19
GuB-42 wrote: post #18

Earlier quoted context omitted.

That's a common trick in PC 4k intros. Despite the apparent variety, most 4k intros rely on a single effect, maybe two. There isn't enough space for more. The only things that change are the parameters. Interestingly, the technique used here is signed distance field raymarching. A technique that is used by maybe 90% of all 4k intros today. So basically, write the code in GLSL instead of C, add music, play a bit with…

That's really cool, in part because it's comforting to hear. :-) Sometimes I feel a bit guilty about how much variety can be had from abusing a single distance function + various texture maps, camera angles and focal settings, environment colors, etc.

The signed distance function also finds application in real physics simulations of fluids, where it goes under the name of "level set method". Ron Fedkiw, who's worked a lot on it, is one of very computational physicists who also holds an Academy Award. His homepage is very interesting:

http://physbam.stanford.edu/~fedkiw/

Re: KABOOM in 180 lines of bare C++

#52

Post by nazri1 »

edoo wrote: post #2

Impressive effect. I didn't realize openmp was so easy to use. It isn't realtime but you could bake up some cool effects with this. AMD FX8320 3.5GHz $ time ./tinykaboom real 0m4.176s user 0m28.631 sys 0m0.012s

I saw the openmp pragma and thought to myself "neat! should be fun to watch the cores work hard at this" and went ahead and compiled and run it and smiled at the 400% cpu usage in top.

    $ time ./tinykaboom 
    ./tinykaboom  78.08s user 0.02s system 369% cpu 21.159 total
Then I wondered how it would fare if I were to port it to Go and went ahead and hastily did port to Go and thought that, "hmmm this should run a bit slower than the c++ version" but surprisingly it ran more than twice faster:

    $ go build ./tinykaboom.go
    $ time ./tinykaboom 
    ./tinykaboom  34.32s user 0.03s system 368% cpu 9.315 total
https://github.com/holygeek/tinykaboom/blob/master/tinykaboo...

Here's the corresponding perf report:

Go:

    Samples: 103K of event 'cycles:pp', Event count (approx.): 37252033995665
    Overhead  Command     Shared Object      Symbol
      32.17%  tinykaboom  tinykaboom         [.] math.sin
      28.80%  tinykaboom  tinykaboom         [.] main.hash
      11.81%  tinykaboom  tinykaboom         [.] main.rotate
       7.76%  tinykaboom  tinykaboom         [.] math.Min
       5.18%  tinykaboom  tinykaboom         [.] main.lerpFloat64
       4.25%  tinykaboom  tinykaboom         [.] main.noise
       2.59%  tinykaboom  tinykaboom         [.] runtime.mallocgc
       2.59%  tinykaboom  tinykaboom         [.] main.fractal_brownian_motion
       2.58%  tinykaboom  tinykaboom         [.] main.signed_distance
c++:

    Samples: 234K of event 'cycles:pp', Event count (approx.): 86721459552303
    Overhead  Command     Shared Object        Symbol
      67.93%  tinykaboom  libm-2.23.so         [.] __sin_avx
      30.80%  tinykaboom  tinykaboom           [.] _Z5noiseRK3vecILm3EfE
       1.27%  tinykaboom  libm-2.23.so         [.] __floorf_sse41
       0.00%  tinykaboom  tinykaboom           [.] _Z23fractal_brownian_motionRK3vecILm3EfE
       0.00%  tinykaboom  tinykaboom           [.] floorf@plt
If anyone can give suggestions on how to make the tinykaboom.cpp faster that would be neat!

Re: KABOOM in 180 lines of bare C++

#53

Post by haldean »

nazri1 wrote: post #52
edoo wrote: post #2

Impressive effect. I didn't realize openmp was so easy to use. It isn't realtime but you could bake up some cool effects with this. AMD FX8320 3.5GHz $ time ./tinykaboom real 0m4.176s user 0m28.631 sys 0m0.012s

I saw the openmp pragma and thought to myself "neat! should be fun to watch the cores work hard at this" and went ahead and compiled and run it and smiled at the 400% cpu usage in top. $ time ./tinykaboom ./tinykaboom 78.08s user 0.02s system 369% cpu 21.159 total Then I wondered how it would fare if I were to port it to Go and went ahead and hastily did port to Go and thought that, "hmmm this should run a bit slower…

What were your compilation flags?

Re: KABOOM in 180 lines of bare C++

#55

Post by mcbits »

Const-me wrote: post #49
vidarh wrote: post #47

Earlier quoted context omitted.

The algorithm is applicable to video games. As you yourself point out it'd not be a lot of effort to rewrite. I suggest you read the very next paragraph, which ends: > I do not pursue speed/optimization at all, my goal is to show the underlying principles. ... > Just target Windows and use Direct3D, 99% of PC game developers do just that. Misses the point of the series. From the introduction (linked at the top of the…

> I am deeply convinced that it is impossible to write efficient applications using 3D libraries without understanding this. What he explains is almost irrelevant for efficiency. Other things are relevant: early Z, tiled rendering, other things about architecture of GPUs: resource types, cache hierarchy, fixed-function pipeline steps, these warps, many others. > I care about the concepts. I've been programming C++ fo…

Yes, irrelevant, because the article is simply describing how to combine a sphere+bumps+noise to look like an explosion.

Your project seems to be interesting in its own way, but I don't see why you'd juxtapose it with this tutorial, other than that they both involve pixels.

Re: KABOOM in 180 lines of bare C++

#56

Post by Const-me »

mcbits wrote: post #55
Const-me wrote: post #49

Earlier quoted context omitted.

> I am deeply convinced that it is impossible to write efficient applications using 3D libraries without understanding this. What he explains is almost irrelevant for efficiency. Other things are relevant: early Z, tiled rendering, other things about architecture of GPUs: resource types, cache hierarchy, fixed-function pipeline steps, these warps, many others. > I care about the concepts. I've been programming C++ fo…

Yes, irrelevant, because the article is simply describing how to combine a sphere+bumps+noise to look like an explosion. Your project seems to be interesting in its own way, but I don't see why you'd juxtapose it with this tutorial, other than that they both involve pixels.

The project was just an example of HN bias against GPUs. At least for doing graphics on GPUs.

Try searching "GPU" on this site. 100% of the first page of results are about using GPGPU in the clouds. Do you think that matches what people buy GPUs for, or amount of code developers white for them?

Re: KABOOM in 180 lines of bare C++

#57

Post by nazri1 »

haldean wrote: post #53
nazri1 wrote: post #52

Earlier quoted context omitted.

I saw the openmp pragma and thought to myself "neat! should be fun to watch the cores work hard at this" and went ahead and compiled and run it and smiled at the 400% cpu usage in top. $ time ./tinykaboom ./tinykaboom 78.08s user 0.02s system 369% cpu 21.159 total Then I wondered how it would fare if I were to port it to Go and went ahead and hastily did port to Go and thought that, "hmmm this should run a bit slower…

What were your compilation flags?

I used the default one in CmakeLists.txt (-O3).

I ran the comparison again on another machine that I have and this time their performances are about the same:

c++:

    $ time ./tinykaboom
    ./tinykaboom  46.72s user 0.01s system 364% cpu 12.804 total
go:

    $ time ./tinykaboom     
    ./tinykaboom  42.50s user 0.07s system 350% cpu 12.161 total

Re: KABOOM in 180 lines of bare C++

#58

Post by tombert »

I suppose this shows a bit of a sickness inside me, because I have a strong aversion against reading these articles because of my pure distaste for C++, which is stupid because this article is great.

Still, it's hard for me to not want to create a series of blog posts under the title "All those cool graphics tutorials in ".

Re: KABOOM in 180 lines of bare C++

#59

Post by mcbits »

Const-me wrote: post #56
mcbits wrote: post #55

Earlier quoted context omitted.

Yes, irrelevant, because the article is simply describing how to combine a sphere+bumps+noise to look like an explosion. Your project seems to be interesting in its own way, but I don't see why you'd juxtapose it with this tutorial, other than that they both involve pixels.

The project was just an example of HN bias against GPUs. At least for doing graphics on GPUs. Try searching "GPU" on this site. 100% of the first page of results are about using GPGPU in the clouds. Do you think that matches what people buy GPUs for, or amount of code developers white for them?

I searched "GPU" and almost all of the top results were people doing weird/unusual things with the GPU: terminal emulator, Postgres query acceleration, stripped down HTML engine, APL compiler, etc. A search of "Direct3D" suggests HN doesn't have much interest in Direct3D, though.
Post reply on HN