Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 23 Oct 2011
Offline Last Active Jun 29 2016 01:00 PM

#5238278 How much performance improvement does SSE provide?

Posted by on 03 July 2015 - 05:56 PM

 If you use SoA format and have long enough instruction chains it isn't hard to get 4x for SSE and 8x for AVX


You can also do things in AVX/SSE such as  (FMA, rcp_sqr, rcp) which will outperform standard C++ in specialized cases, and easily go over 8x


 I have a bunch of template math functions when can be invoked either with AVX types or standard C++ float. The difference is about 10x.

#5185880 I need to fill about 6MB of memory per frame, fast algor needed

Posted by on 08 October 2014 - 06:31 PM

 std::vector<bool> happens to be implemented using bits instead of bytes, so you might as well use that instead of hacking in your own implementation on top of it.

#5177661 Storing Objects With The Same Base Class In Vector

Posted by on 02 September 2014 - 09:00 AM

 The code seems pretty fishy to me, but at the very least replace this:


std::vector<std::vector<GUI_Model*>> pages




std::vector<std::vector<std::unique_ptr<GUI_Model>>> pages


If you want to store these types by value in the container, and you have a known # of them, you can use boost:variant.



#5175516 Unreal 4: c++ vs blueprints

Posted by on 22 August 2014 - 11:19 AM

 Blueprints are fine for relatively simple things. I've seen some attempts to implement complex logic in Blueprints, it looked a giant pile of spaghetti. 

But if you can do it with Blueprints, you might as well start with that.


Also Epic has a forum for discussion of UE4, you would probably get more information there.

#5174816 So... C++14 is done :O

Posted by on 19 August 2014 - 02:13 PM

 I'm pleased with the additions. I already use everything that is available in VS2013, I just wish Microsoft was quicker to support C++11/14.


Ranged for is superior to the iterator method because it is shorter & easier to read. The less code you have to read the easier it is to maintain.

It is also harder to mess it up via a typo.


And soon you will be able to shorten further to:


which the compiler will translate into 

for(auto&& a: vec)


Anyway, are there any game studios actually using C++11/14, I'm pretty tired of working at studios that stick to C++98

#4973483 Visual Studio 2012 ruined everything

Posted by on 26 August 2012 - 09:10 AM

Install vs2012 and fix the problems. D3D is now part of the windows SDK.

#4902624 Calculating Normals From Displacment

Posted by on 14 January 2012 - 05:49 AM

Does the spherical coordinates for normal mapping work? Do you have to do point sampling?

Not saying it doesn't work, cause I haven't tried it, but wouldn't bi linear interpolation cause some odd artifacts, since it would take the long route around the sphere if say you had coordinate -1 next to coordinate 1.

#4890577 C++ header only style

Posted by on 04 December 2011 - 09:58 PM

I hate the way C++ uses separate interface and implementation files, so I decided to try a little experiment to see if it might be possible to just use headers.

Testing to see if using a header only approach to C++ has any benefits, by this I mean that each project would only have 1 .cpp file, everything else goes in headers.

All tests done with Visual Studio 2010

Code includes use of many templates, STL, boost, and TBB(lots of templates).

LTGC is on for release built, along with comdat folding

/MP is also enabled for all builds, although in header only world it doesn't do much(anything?)

Using CPP files: size: release = 375,296 bytes debug = 1,856,512 bytes
Using header only: size: release = 375,296 bytes debug = 1,856,512 bytes

So using 1 CPP, instead of many, made no difference to exe size

Full Build Times Release:

CPP Header:
1)33.74 1) 18.17
2)33.79 2) 18.02
3)33.48 3) 18.44

Full Build Times Debug:
CPP Header:
1) 24.65 1) 12.47
2) 25.16 2) 12.11
3) 24.80 3) 11.76

Full rebuilds are much faster under header only, and this is with /MP(multithreaded builds) enabled(8 cores) which favors having extra .cpp to split up the work

Partial Rebuild Release:
1)16.18 <-- changed 1 line in 1 cpp
2)25.81 <-- changed 1 line in random .h
3) 13.66 <--- changed 1 line in a different cpp

Can't do partial rebuilds with header only, but full rebuilds with header only are comparable to partial rebuilds with CPP's time wise. Partial rebuilds heavily depend on exactly what was changed

Partial Rebuild Debug
1) 19.06 <-- changed random header by 1 line
2) 3.32 <-- changed a line in 1 cpp
3) 16.62 <-- changed a line in another random .h

The code was all originally written using .cpp/.h combo as traditional C++. To switch to header only I just copied the contents of each .cpp under the contents of the .h and then removed the .cpp from the project.

After I had finished this I only had one compiler error which resulted from two objects which both made use of each other. One by value and one by reference.

I fixed this by splitting the class which used the other by reference into two headers, the .h as it had already existed, and contents of its .cpp moved into a .hpp and included in a header called "circular.hpp" which is then included in the one and only .cpp(main.cpp).

+ could probably also just rename all .cpp to .hpp and add them to circular.hpp or some such which is included in main.cpp, but this keeps those extra files around...

I had expected it to decrease the size of the .exe(or at least change it) since I've heard of other people doing similar things to create more optimized builds, and of course people crying about template bloat. That didn't happen though.

Built times are better in many cases, slower in others. I could see the header only approach not working so well with a giant project as it pretty much results in constant time builds which grow linearly with the # of files.

Of course changing a header in a giant C++ project can result in a nightmare rebuild...

Perhaps the best way would be header only, but split into multiple projects, so that not everything must always be remade?

Overall Header Only:
+faster worst case build times(changing a header)
+simpler build process
+can place code right in the class itself, like in most modern languages
+less files to deal with
+less worrying about forward declaring to avoid excess header includes and PIMPL pattern
+only one translation unit so warnings/errors in headers are seen once(less spam)
+can write functions in header without being forced to "inline" them (normally this results in multiple definitions error but with only one translation unit, no such problem)
+on older compilers that don't have link time code gen, should be more optimal?

-best case build times are slower(changing cpp)
-might not scale too well? not sure here, might be easy to work around this with multiple projects

I think I am going to start doing this with all of my code, and port my existing code over to this approach..

Does anyone have any experience with this, or know of any problems I missed with this approach?

C++ needs a module system:(

#4889215 School? I would not call it that way.

Posted by on 30 November 2011 - 04:16 PM

At least your high school has CS classes ... mine had a typing class which used 15 year old computers, and that was canceled after my freshman year.

Most CS teachers suck, but then again lots of programmers suck too.

imo any good programmer learned most of what they know on their own, school is like the first 20%

#4888195 Heap Management

Posted by on 27 November 2011 - 02:28 PM

Not sure how much I believe that comment. I've downloaded and tested various so-called fast allocators(Nedmalloc etc.) claiming that they outperform microsofts, and every time I actually tested it, the MS allocator was the fastest.

The OS seemed to matter somewhat here, as MS allocator under XP didn't always win, but under Vista/Windows 7 it fairly well destroyed the others(I believe the default under Vista+ is low frag).