"During the 4th Semester of my studies I wrote a small 3d spaceship deathmatch shooter with the D-Programming language. It was created within 3 Months time and allows multiple players to play deathmatch over local area network. All of the code was written with a garbage collector in mind and made wide usage of the D standard library phobos. After the project was finished I noticed how much time is spend every frame for garbage collection, so I decided to create a version of the game which does not use a GC, to improve performance."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2011-01-28
sakeniwefu,
"Benchmark, benchmark, and when you've established that there isn't any possible bottleneck other than memory allocation, then it still isn't the memory allocation system."
Well, GCC's allocator is not very good especially on SMP systems where it can be a bottleneck. So it might make sense to tinker with new allocators but I wouldn't want to imply that allocation is typically a bottleneck in most applications.
"So, I rewrote it with a custom memory management algorithm to the point allocation and release were barely slower on average than a void (library) function call."
I'm curious about the implementation, I've written my own too where objects were pooled in thread local storage and therefore incurred no overhead on SMP until the global allocator was hit to replenish the pools.
"Guess what? It still was the bottleneck. Some good old printf profiling revealed that the OOP client application was hitting it like crazy."
This should have been uncovered much earlier. Didn't the profiler give function counts?
"The problem I see in all of GC, RAII(for system memory) or ARC is that they encourage the everything is an object mentality. And that mentality generally turns into programs that hit the allocator way too much."
Absolutely, one of the easiest ways to improve low level performance is by reducing the number of objects we need to accomplish our tasks. If a process always allocates A+B+C, then those could be combined into one monolith object instead, reducing object overhead by a factor of 3 for both GC or non-GC languages. However many people are going to be on edge about where to draw the line between OOP purity and overhead. Even though ideally one might want to manipulate pixels as objects, the OOP paradigm just breaks down due to the inefficiency of having so many numerous objects. Some day we could have a language with virtual objects which don't exist in memory, but allow us to manipulate the pixels as if they were real objects.
So, the Xbox One disaster continues. Microsoft's policy for dealing with the used games market has reportedly leaked - and it's a clear and direct attack to destroy the used games market. Prices for used games will be set at the retail value of a new game, and retailers have to hook into Microsoft's computer systems and comply with Microsoft's terms and conditions.At an event earlier today, Microsoft unveiled the next Xbox - the third model, but confusingly named Xbox One. The big focus was TV, integrated Kinect, and all the other stuff we all expected to be forced down our throats. I think it took them 25 minutes to actually come to what should be the core of the story: gaming. Nothing groundbreaking in the gaming department, except for how Microsoft intends to handle the used games market and borrowing games from friends: pay up, buddy!
The day has finally come! Jolla has finally announced the launch device for its Sailfish operating system - and by god this is a looker. It's decidedly different from other phones out there, but it has good specifications and carries a relatively reasonably price tag - EUR 399, and it's up for pre-order today, shipping in the fourth quarter of this year.
Why does Google get so much credit in the technology industry? Why, despite the company's many obvious failings, do many geeks and enthusiasts still hold a somewhat positive view on the all-knowing technology giant? A specific talk at Google I/O this week provides the answer.
OSNews is a sponsor of this year's O'Reilly OSCON in Portland, Oregon, USA. A lucky OSNews reader will win a free three-day pass, including two tutorials days. To win the pass, post a comment on this story saying something about Open Source Software or OSCON. We'll pick a winner at random next week. If you don't have an OSNews account, you may email us your entry. Part of the conference is the 9th annual Open Source Awards, and today the 16th is the deadline for nominations. If you'd like to nominate an outstanding open source contributor, do it here. Read on for more information about OSCON. Update: The 20% discount code for OSNews readers is "OSN."
"Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
This is one of those news items that's fun to write, fun to read, fun to comment on, and where no one will be able to say anything unkind. It's all just one big ball of awesome fluffiness. TuneTracker, the BeOS radio automation software, has just released something very special: TuneTracker System 5, the first version designed entirely and specifically for Haiku. In fact, it actually includes Haiku in the software package. Better yet, TuneTracker also unveiled several system-in-a-box products - which have Haiku and TuneTracker pre-installed.
Exactly twenty years ago, a document was published that played a huge role in establishing the web as we know it today. Twenty years later, and this simple and straightforward document is proof of an irrefutable fact: while closed technologies can change markets, open technologies can change the world.Oh multitasking. That staple of computing that got thrown out the window with many modern smartphones. We got some rudimentary thing in its place - but even as multitasking on phone and tablets improves, its user-visible side remains cumbersome. Windows 8 has a neat implementation, and now it's time Android follows in it footsteps.They're here! Whether that excites you or not remains to be seen, but the Galaxy S4, which will most likely become the best selling Android smartphone of the year by a huge margin, has been reviewed by all the major sites, and there's lots of interesting conclusions in there - although I think most of you will get the gist.
Member since:
2008-02-26
"If you have a GC, you do not worry too much about short-lived objects, but worry a great deal about medium-lived objects. If you do not have a GC, then you do not worry too much about medium-lived objects, but must take care to avoid excessive overhead from constructing and destructing short-lived objects."
I still don't think it's safe to assume these generalisations are accurate without benchmarking them in an application.
Benchmark, benchmark, and when you've established that there isn't any possible bottleneck other than memory allocation, then it still isn't the memory allocation system.
Some time ago, I designed and implemented an abstraction layer for an embedded OS and when the app it was serving was reported as being too slow by the customers my system allocator wrapper was singled out as the problem by the "profiler".
This was in a world of custom prematurely optimized everything. So my decision to keep it simple was met with little sympathy.
So, I rewrote it with a custom memory management algorithm to the point allocation and release were barely slower on average than a void (library) function call.
Guess what? It still was the bottleneck.
Some good old printf profiling revealed that the OOP client application was hitting it like crazy.
Classic allocation, Reference Counting, Garbage Collection, it wouldn't have made a difference.
The problem I see in all of GC, RAII(for system memory) or ARC is that they encourage the everything is an object mentality. And that mentality generally turns into programs that hit the allocator way too much.