ttsiodras

Thanks! I really enjoyed building the thing :-)

> I was expecting a single string with a complex waveform, with additional pulls changing that waveform

Actually, that's exactly what you are seeing - by pulling the middle sample down to the bottom every time you click, the "spring-like" pull of the sample to the left and the sample to the right (see the Theory section) trigger additional waves that propagate, reflect on the walls, and interfere with the original one.

It's not a bug; it's a feature :-)

The code "pulls" the middle sample down, to the bottom of the window, and then the simulation runs.

As for the 2D simulation, you were right - I just pushed a version with more contrast.

Thanks for the feedback!

Thank you, didn't know this!

Code updated.

Wow - speechless :-)

The correlation with my program's results is clear (the coefficients are my last column) - any references as to why?

"This program is originally based on the driveGnuPlots.pl script from Thanassis Tsiodras. It is available from his site at http://users.softlab.ece.ntua.gr/~ttsiod/gnuplotStreaming.ht...

:-)

Thanks for this. Note that the "sleep" is not part of the plotting script - it's just an example that generates data for plotting. I updated the page with your suggestion.

Back in 2008 (when this was written) "perldoc -q flush" suggested exactly that gem :-) I admit I've more or less abandoned Perl since then (scripting in Python for everything).

I think you misinterpreted the article: the target is not Linux/x86, its a custom board with the SPARC/Leon processor running a custom embedded OS (RTEMS), launched in space :-)

The article is just an example of the notions used, and how objdump can be used to enforce them. Linux is used simply for demonstration purposes.

In your average PC with Linux/x86, it is clear that you fear neither stack nor heap error - you just restart the app :-)

MISRA-C, for starters.

Developing safety-critical code is governed by extensive guidelines (like DO178-B) which dictate lots of things, not just about code (process of development, testing, etc)

You can try convincing space companies that they are in error; good luck with that :-)

> I guess that, even with these checks, the program will still have some watchdog timer, a way to remotely reset it, and a way to upload new software, just in case it runs wild.

Indeed.

As for the reasoning: couldn't have said it better myself.

Actually, function pointers are... not allowed in space SW.

And remember, this is just a hack I did - I wanted to show people the things one can do with objdump. From the article:

"This kind of functionality is usually part of far more mature tools than... quickly-hacked Python scripts. Don't use this to send your spaceship in orbit :-)"

Apparently no-one knows how to do this for NTFS - I got no response in ServerFault.

If one moves a step further, and compares how ZFS handles bad sectors (checksums, auto-healing, etc) with how the black-box of NTFS works... Yikes.

Hmm... the scores you printed are not correct (look at the two board edges):

C++: sh -c "time ./bin.release/score4 o53 y43 -debug" Depth 7, placing on 0, score:2 Depth 7, placing on 1, score:8 Depth 7, placing on 2, score:8 Depth 7, placing on 3, score:8 Depth 7, placing on 4, score:8 Depth 7, placing on 5, score:8 Depth 7, placing on 6, score:2 5

Your Haskell code:

sh -c "time ./score4.bin o53 y43 -debug" Depth 7, placing on 0, score 0 Depth 7, placing on 1, score 8 Depth 7, placing on 2, score 8 Depth 7, placing on 3, score 8 Depth 7, placing on 4, score 8 Depth 7, placing on 5, score 8 Depth 7, placing on 6, score 0 5

I'll try to see why your code miscalculates on the two borders, but I don't speak Haskell so don't expect much :-)

I replaced the exceptions from the functional F# code with mutable flags and while loops - and its speed improved from being 6 times slower than OCaml, to being 5 times slower.

I also replaced the sort with a fold... and there was no speed improvement (the lists are so small it made no difference).

Oh well, what can you do? :-)

Excellent. And committed - I will study your code, Haskell is next on my agenda :-)

Added it, thanks.

Committed to the repository - thanks!

Added to the repos - can you please provide your prefered optimization parameters to GHC ? e.g. a Makefile?

Actually, I very much appreciate the fact that he didn't - this way the comparison is more fair - and easier to follow for people new to functional programming (like me).

Me too: It took me two failed attempts before my third version (the current incarnation of scoreBoard), could finally best me.

Agreed - on all your points. And... glad you liked it :-)

Thank you for your kind words. To your points:

- You are right about measuring the startup time of the binaries with "time"; but in this case, where the execution time for F# is measured in the order of ten seconds, the comparisons are still valid and useful, especially in the context of seeing what kind of an impact switching to imperative-style has (10->8, 1.7->1.4, etc)

- Passing the whole board as arguments has little (if any) effect on the execution time: e.g. you can see for yourself that if you pass NO arguments (i.e. clean board) the time ratios between languages remain the same. In a game like Score4, the human has to think anyway - and you can see that using C++, even the nasty cmd-line interface leads to response times of less than a second.

- About F# exceptions: in the absence of "break"... can I do anything else to abort a loop early?

Thanks for your feedback, much appreciated.

I did a very similar investigation 5 years ago, to find the optimal way to fill-up a DVD from a set of files of various sizes (more than a DVD's worth). Have a look:

http://users.softlab.ece.ntua.gr/~ttsiod/fillupDVD.html

Simple: the secondary rays don't "bunch" up together - there's no advantage to doing them in a second pass, you won't suddenly get coherence that way.

> Very nice post, though. Neatly organized and well written, I really enjoyed it.

Blushing :-) Glad you enjoyed it, hope you have a chance to look at the GPL code, too.

Rasterization works per triangle - which means that each CUDA thread is working on a triangle. Which means that by definition, each thread reads/writes to a completely different place in the Z-buffer and reads from a completely different place in the shadow buffer. Hence the abyssmal speed I experienced with my CUDA rasterizer, and why I switched to CUDA raycasting.

Well it was a weekend project, so I am not sure it is exactly... elegant. But thank you, I accept the compliment :-)

As for my negative conclusions... I wouldn't describe them as "negative", just "objective". Some algorithms are easily adapted to CUDA, and you get an easy win of 10-40x. Others need a lot more work to offer speed gains, and finally, there are some that are simply hopeless (you have to redesign them from scratch).

> If you believe this, then I recommend doing a start-up

I did (http://www.tapeditor.com)