Sign in to follow this  

Smart Pointer use it every day or not ?

This topic is 4339 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

HI guys! i using a lot of smart pointers in my in-home 3D engine , but the cuestion is...... is that good? any one recomend NO use Smart Pointer in a real time app? why? how about performance... ? anyone use Smart Pointer and a garbage collector for a 3D engine (C++) thanks!!!

Share this post


Link to post
Share on other sites
It will almost definately save you time in the development and debugging stage. It is concievable that a poorly-implemented smart pointer might eventually cause a performance degradation. But you shouldn't worry about it until you have proven that the smart pointer is the bottleneck. In short, I wouldn't be concerned.

Share this post


Link to post
Share on other sites
You should strive to make appropriate usage of smart pointers. You shouldn't worry about it from a performance perspective. Rather worry about it from a design perspective. Fixing performance problems doesn't cause massive rewrites, but rather poor design does. Consistantly make an inappropriate choice in the smart pointer used for a task and you may well find a compelling reason to change all those to the appropriate type once you realize what you should have used instead.

That won't be due to performance, but rather simply the annoyance of seeing it constantly, it being a repeated source of bugs or a necessity to reasonable add in required functionality. Massive changes to an application are driven by design mistakes and not performance problems. That's one of the reason people put such emphasis on profiling for performance tuning. Most people are quite surprised to find how little work the vast majority of their program does and thus how irrelevant most of the code is in terms of performance. Massive rewrites to programs to fix performance problems is about like overhauling the engine in your car because the spark plugs are corroded. If somewhere in that process you change the spark plugs then then the problem is fixed when you are done, but all that was actually required was changing the spark plugs.

Share this post


Link to post
Share on other sites
It depends. If you are using a smart pointer tailored to your situation, then you aren't going to lose any performance since they're just going to do automatically everything that you would normally do manually. What could impact performance is overusing objects with shared ownership or needlessly copying smart pointers where you don't have to.

Share this post


Link to post
Share on other sites
Quote:
Original post by juglarx
HI guys! i using a lot of smart pointers in my in-home 3D engine , but the cuestion is...... is that good? any one recomend NO use Smart Pointer in a real time app? why? how about performance... ? anyone use Smart Pointer and a garbage collector for a 3D engine (C++)

Going through each:


Boost has six smart pointer types.

Use them. Prefer them over naked pointers. A well-written app will have (almost) no naked pointers in use, and (almost) never calls new or delete.

The performance penalty of 1, 2 or even 10 levels of indirection is practically nothing. If you never use them it will end up with a cache miss anyway. If you use them very often they will stay in the cache and not be an issue. Profile the code and find the horrible algorithms that take more time than you expected; that's the real performance problem.

Most games don't use GC the way you are suggesting. We use memory pools so we don't have to go through the OS (which is slow), can use the pools to track leaks, and don't do any automatic GC.

And for a clarification, games are normally not referred to as 'real time' apps. A real time app is an application where if the timing is off it is a complete failure. Games and game servers are high-performance applications where you want things to run as fast as possible, but if you have a momentary delay for some reason (such as a memory page fault or disc spinning speed changes) it isn't considered a failure, just an annoyance.

Examples include:
* a computer in a factory's high-speed conveyer belt that screws on bottle caps. If it is off by a fraction of a second, bottles will break.
* Software in pacemakers, it has to respond within critical time amounts and operate at specific regular intervals
* Software controlling anti-lock brakes, it has to respond quickly and properly alternate the pressure on the brakes at specific timings based on the constantly changing environmental conditions.
* Aircraft and missile guidance controllers. You don't want your smart-missile to start into a turn then have a cache miss, causing the turn to go too long, and the missile spinning out of control.
* Anything else where timing is absolutely critical.

In games you can always have frames that don't update on time, communications that stall, disk spin-ups and spin-downs that cause a 1-2 second stall, etc. None of these are considered a "failure" condition in the game.

Share this post


Link to post
Share on other sites
Quote:
Original post by frob
In games you can always have frames that don't update on time, communications that stall, disk spin-ups and spin-downs that cause a 1-2 second stall, etc. None of these are considered a "failure" condition in the game.


Not keen on this one, if my game is merrily running along at 120 fps and a hard drive spin-up stalls it for 2 seconds, really bad.

You should try to minimise on occasions when this sort of slow-down can happen, especially the more expensive (time wise) ones. Try to only read from the disk at program start up and when loading levels, only write to disk when saving the level, etc. Of course if you exceed available memory you will end up with hard-drive accesses from virtual memory anyway, but hopefully the OS's virtual memory system will spin-up the HD early and keep it spinning ;)
Frames that don't update on time are often a sign of lousy design, once the game is running it should be able to distribute heavy processing over several frames, and only rarely should a frame take much longer than the frame either after or before.
Network connections are unfortunately another story, they are notoriously unreliable, and may lag seemingly randomly, not a whole lot you can do about it other than fudge results to convince the player the network is still running.

Even better than a smart pointer is a debugging smart pointer, i.e. one that has a lot of debugging support that can be enabled or disabled at compile time, it saves a lot of hassle trying to find null pointers and buffer overruns.

Share this post


Link to post
Share on other sites
Quote:
Original post by swiftcoder
Quote:
Original post by frob
In games you can always have frames that don't update on time, communications that stall, disk spin-ups and spin-downs that cause a 1-2 second stall, etc. None of these are considered a "failure" condition in the game.


Not keen on this one, if my game is merrily running along at 120 fps and a hard drive spin-up stalls it for 2 seconds, really bad.

You should try to minimise on occasions when this sort of slow-down can happen, especially the more expensive (time wise) ones. Try to only read from the disk at program start up and when loading levels, only write to disk when saving the level, etc. Of course if you exceed available memory you will end up with hard-drive accesses from virtual memory anyway, but hopefully the OS's virtual memory system will spin-up the HD early and keep it spinning ;)
Frames that don't update on time are often a sign of lousy design, once the game is running it should be able to distribute heavy processing over several frames, and only rarely should a frame take much longer than the frame either after or before.
Network connections are unfortunately another story, they are notoriously unreliable, and may lag seemingly randomly, not a whole lot you can do about it other than fudge results to convince the player the network is still running.


I agree with some of that. MINIMIZE the times they happen by doing all those things.

If you have hard-drive accesses from virtual memory, it isn't a critical failure, just an annoyance that the user will probably hear as their disk chugs away. If the CD has to spin up, they can hear the disc make a whirring sound and understand it. They might not like it, but it isn't a critical falure. If the person has a huge processing load going on in another app (maybe they decided to play a game while they waited for Maya to do a 12-hour rendering), they'll understand that it's an annoyance; it isn't a critical failure.

In real time applications, those conditions are critical failures. Games are high performance, not real time.

Share this post


Link to post
Share on other sites
Quote:
Original post by frob
In real time applications, those conditions are critical failures. Games are high performance, not real time.


Agreed, I hadn't meant to dispute that, but merely to point out that it is often good to regard these as potential failures (then you think harder about minimising them).

OP: I use smart-pointers extensively in my own engine, also written in C++, and I have had very few troubles since I first designed the system. I also use dumb pointers a lot, basically just a wrapper around a C++ pointer, but they offer the extra security of checking for NULL pointers and other bad things. The neat part is that in release mode they are just a bunch of inline functions, and are optimised away.

Share this post


Link to post
Share on other sites
Guest Anonymous Poster
[quote]Original post by frob
Quote:
Original post by juglarx

And for a clarification, games are normally not referred to as 'real time' apps. A real time app is an application where if the timing is off it is a complete failure. Games and game servers are high-performance applications where you want things to run as fast as possible, but if you have a momentary delay for some reason (such as a memory page fault or disc spinning speed changes) it isn't considered a failure, just an annoyance.



thanks 4 the calrification!

Share this post


Link to post
Share on other sites

This topic is 4339 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this