Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


Don't forget to read Tuesday's email newsletter for your chance to win a free copy of Construct 2!






Release 14 imminent...

Posted by ApochPiQ, 14 April 2013 · 489 views

Epoch
So I've been looking over my past notes and decided that I'm pretty happy with the state of affairs over in Epoch land. The garbage collector is running, tuned for reasonable performance, and successfully keeps the native-code realtime raytracer clamped at a decently small degree of RAM usage.

The only thing that really bugs me is that the GC has imposed a serious performance hit on the raytracer - to the tune of halving its old performance. I still need to do a full release build of the runtime to make sure I can't improve on that any, but I suspect the GC root spilling in LLVM is taking a toll on optimization passes. I might need to work on improving the front-end of the compiler to generate more optimal code in the first place so that I don't have to spill so many registers onto the stack all the time.

It'll take some analysis and study of the emitted machine code, but I'm optimistic about being able to reclaim at least some of the performance.

If nothing else, this is a good motivation for introducing a "manually reclaimed" semantic to object allocations in Epoch, so programs that don't want to incur GC overhead can bypass it entirely.



[As I wrote this, I kept alt-tabbing over to Visual Studio and mucking around. I managed to suppress garbage collection invocation for a large percentage of functions, which got me back to 21FPS - compared to 24FPS previously. I'm happy.]




Why do you have to spill the registers at all? Can't you keep track of which ones have references in them?

LLVM doesn't support tracing GC roots in registers at this point. It's a nasty limitation but the perf impact isn't that terrible if you're careful about emitting good code from the front-end.

November 2014 »

S M T W T F S
      1
2345678
9101112131415
16171819202122
232425 26 272829
30      

Recent Comments

PARTNERS