VS2015 Generates Slow Code (Again...)

The Partridge Family were neither partridges nor a family. Discuss.
Post Reply
User avatar
BurakCanik
Posts: 250
Joined: February 8th, 2014, 9:16 pm
Location: Istanbul, Turkey

VS2015 Generates Slow Code (Again...)

Post by BurakCanik » March 4th, 2017, 12:16 pm

I'm back again with another rant. There was this:
http://www.planetchili.net/forum/viewto ... lit=vs2015
Now I'm having a similar problem. I have a heightmap that has 2049 x 2049 elements. There is a simple smoothing function that is simply averaging each element's value with its closest 8 neighbors. Oh and it also does bounds checking (don't include the neighbor if it's outside the bounds, simple stuff).

Now I'm running it in Visual Studio 2015.
And you guessed it: VS2015 generates code that is SLOW AS HELL!

I'm using windows 10, Visual Studio 2015. I also have VS2013, VS2012 and VS2010 (and their respective compilers) installed so I can build a project with different compilers ("platform toolsets") in Visual Studio 2015.

My test results (All taken in VS2015 but with different compilers):
DEBUG BUILD
VS2010 Compiler (v100):
Loading heightmap... time elapsed = 0.50 seconds!
Smoothing... time elapsed = 3.37 seconds!

VS2012 Compiler (v110):
Loading heightmap... time elapsed = 0.47 seconds!
Smoothing... time elapsed = 3.40 seconds!

VS2013 Compiler (v120):
Loading heightmap... time elapsed = 0.52 seconds!
Smoothing... time elapsed = 3.41 seconds!

VS2015 Compiler (v140):
Loading heightmap... time elapsed = 3.23 seconds!
Smoothing... time elapsed = 13.12 seconds!

What. The. HELL!

2010, 2012 and 2013 results are essentially the same but 2015 result is dramatically slow.
Compiler optimizations are disabled for all debug builds by the way.

Release builds are all same and fast though:
RELEASE BUILD
Loading heightmap... time elapsed = 0.02 seconds!
Smoothing... time elapsed = 0.10 seconds!

P.S. : When I tried setting a breakpoint to debug it using compiler versions prior to 2015 (v100, v110 and v120), it said breakpoint won't be hit because symbols are not loaded for this file. Breakpoints work fine with 2015 version (v140) though. Don't think it's relevant but decided to share.

Why is there such a huge performance difference ?

I'm uploading the .cpp and the heightmap used (.raw file). Can anyone test it? Those of you that have VS2015 and other version(s) of VS I mean.
Attachments
Smooth() VS2010 vs VS2015.zip
(820.5 KiB) Downloaded 139 times
If real is what you can feel, smell, taste and see, then 'real' is simply electrical signals interpreted by your brain" - Morpheus

User avatar
BurakCanik
Posts: 250
Joined: February 8th, 2014, 9:16 pm
Location: Istanbul, Turkey

Re: VS2015 Generates Slow Code (Again...)

Post by BurakCanik » March 5th, 2017, 10:51 am

A way to dramatically increase debug build performance of visual studio:
https://randomascii.wordpress.com/2011/ ... slowdowns/

The part that immediately worked wonders for me:
Update 2, Sep 2013: the slowdown is triggered by a combination of Runtime Checks and Edit and Continuedisabling Edit and Continue can drastically improve debug performance. In particular, it avoids the allocation of 64+ bytes of stack space in empty functions. The VC++ team is aware of the problem.
And to think that I've never even used Edit and Continue before...

Below are the results, there is a nice performance boost when Edit and Continue is disabled. But there is still this difference between v140 and prior versions. Disabling Edit and Continue for prior toolsets increases their performance as well. So after all, VS2015 C++ compiler is still 4-5 times slower compared to prior compiler versions.

New results with Edit and Continue disabled:
DEBUG BUILD
VS2010 Compiler (v100):
Loading heightmap... time elapsed = 0.11 seconds!
Smoothing... time elapsed = 0.61 seconds!

VS2012 Compiler (v110):
Loading heightmap... time elapsed = 0.09 seconds!
Smoothing... time elapsed = 0.64 seconds!

VS2013 Compiler (v120):
Loading heightmap... time elapsed = 0.09 seconds!
Smoothing... time elapsed = 0.61 seconds!

VS2015 Compiler (v140):
Loading heightmap... time elapsed = 0.52 seconds!
Smoothing... time elapsed = 2.24 seconds!

So yeah, quest to find out the root cause of this discrepancy still goes on...

By the way, as is mentioned in the blog post, disabling uninitialized local variable checks and stack frame checks further speeds up debug performance. It's a tradeoff between runtime checks vs performance. You be the judge.
If real is what you can feel, smell, taste and see, then 'real' is simply electrical signals interpreted by your brain" - Morpheus

User avatar
Battlefrog
Posts: 69
Joined: March 31st, 2015, 10:10 pm
Location: Florida, United States of America

Re: VS2015 Generates Slow Code (Again...)

Post by Battlefrog » March 5th, 2017, 5:26 pm

While your fix seems to have worked, the performance is still at the level of the old compilers, which isn't OPTIMAL, however, in your case I think it'll work.

BTW, 2049 x 2049? It's not even a power of 2! :P
Broc W.

Sole Member of Sledgehog Software, trademark and LLC status pending.

MrGodin
Posts: 721
Joined: November 30th, 2013, 7:40 pm
Location: Merville, British Columbia Canada

Re: VS2015 Generates Slow Code (Again...)

Post by MrGodin » March 5th, 2017, 6:30 pm

BTW, 2049 x 2049? It's not even a power of 2!
for terrain heightmaps i believe you must add the extra value.
I use World Machine to generate heightmaps and the resulting r16.raw file is 257,257, or 513,513 ect
Curiosity killed the cat, satisfaction brought him back

User avatar
BurakCanik
Posts: 250
Joined: February 8th, 2014, 9:16 pm
Location: Istanbul, Turkey

Re: VS2015 Generates Slow Code (Again...)

Post by BurakCanik » March 5th, 2017, 8:19 pm

Battlefrog wrote:While your fix seems to have worked, the performance is still at the level of the old compilers, which isn't OPTIMAL, however, in your case I think it'll work.
Exactly. I don't have to wait 15+ seconds when I run the demo in DEBUG build, instead I wait for ~3.3 seconds so that's good. But still it's irritating that previous compilers are still faster by a factor of 4-5.
MrGodin wrote:
BTW, 2049 x 2049? It's not even a power of 2!
for terrain heightmaps i believe you must add the extra value.
I use World Machine to generate heightmaps and the resulting r16.raw file is 257,257, or 513,513 ect
Yeah it's (2 to the power of n) + 1 vertices total so it yields 2 to the power of n "patches".
If real is what you can feel, smell, taste and see, then 'real' is simply electrical signals interpreted by your brain" - Morpheus

reductor
Posts: 49
Joined: October 24th, 2016, 12:23 pm

Re: VS2015 Generates Slow Code (Again...)

Post by reductor » March 5th, 2017, 9:30 pm

It's probably less the compiler but more the standard library has more safety checks which makes it slower. You could do some profiling to find the hotspots

Post Reply