41–50 of 58 posts
This is not really too relevant to the article, but that random generator makes me cringe. You can replace it with a decent quality one (xorshift) with about as many lines of code: uint32_t genrand(uint32_t *seed) { uint32_t x = *seed; x ^= x > 17; x ^= x
Odd. Why is the C version so much slower than the C++ version? The only thing I notice that's odd is the unnecessary Room/Tile structs + memcpy in MakeLevs, but that can't be responsible for that level of difference. Also there is a small bug in the C version. When it goes to print out the level, it only compares the first 100, so it'll print a different level from the C++ version with a seed of say, 20.
Also appears to be a small benefit from modifying the Lev struct to have Room first.
Cool article! One thing that might be important to people if you're looking at these languages besides just speed: Go and C will tend to have radically lower memory usage (often like 10x) than most of the other languages there, such as Scala. This can be very important depending on what your application is. For me, using Go for game world servers was my choice because I can do so much more simulation per dollar of se…
What's important is the marginal memory usage. I'd rather pay 20-30MB of JVM memory tax upfront it it levels up with C/C++ for long running process and lowers the possibility of a memory leak and memory corruption.
[1] http://www-cs.canisius.edu/~hertzm/gcmalloc-oopsla-2005.pdf [2] http://sealedabstract.com/rants/why-mobile-web-apps-are-slow...
Although it's nice to see which compiler performs best, I'm really curious as to why one compiler outperforms another for the same language. What's gcc's achilles heel for example? (it seems to consistently do worse for every language it's use for)
Earlier quoted context omitted.
I'd like to test it with the new Rust-coded runtime, especially if it's faster, but I won't have time to build it for a couple of days. I actually avoided building it earlier because I thought the new scheduler was slower and needed time to mature (I think I read that it doesn't yet swap tasks between threads, or something along those lines?), but I must have misread.
Yes this was a interesting benchmark, nice work. One question though, why are you using an old version of GCC (4.7)? 4.8 has been out for quite some time, I did a quick comparison using your benchmark between gcc 4.8.1 and clang 3.3 on my system and clang still won but the difference was ~3.5% on my machine.
Earlier quoted context omitted.
Take the code here: https://github.com/logicchains/levgen-benchmarks/blob/master... and run it. Then, take the same code, change the genRooms function to contain: where noFit = genRooms (n-1) (restInts) rsDone tr = Room {rPos=(x,y), rw= w, rh= h} x = rem (U.unsafeHead randInts) levDim y = rem (U.unsafeIndex randInts 1) levDim restInts = U.unsafeDrop 4 randInts w = rem (U.unsafeIndex randInts 2) maxWid + minWid h = re…
I just changed the random number bit, not the 10000000 part, and it took ~100x longer. No idea why.
Earlier quoted context omitted.
I just changed the random number bit, not the 10000000 part, and it took ~100x longer. No idea why.
Maybe a compiler bug?
Earlier quoted context omitted.
What's important is the marginal memory usage. I'd rather pay 20-30MB of JVM memory tax upfront it it levels up with C/C++ for long running process and lowers the possibility of a memory leak and memory corruption.
If it was just the 20-30 MB JVM tax, I might be with you. But in applications that allocate and deallocate a lot of memory, the GC of every JVM implementation I've used also hoards memory from the system (well there are a few implementations that give it back, but they cause app performance to nosedive). If you're building a piece of software that needs to co-exist with other memory intensive processes, the JVM's pol…
Earlier quoted context omitted.
Maybe a compiler bug?
I'm a total noob to haskell and I'm not sure I understand the code well enough to ask an intelligent question about it, but I'd love to see you/someone ask on the haskell mailing list/stackoverflow/reddit-haskell or something.