Performance increase on Windows

[Zylann]

I just ran quick tests in GDScript to see how fast it performs, things like that:

    _time_before = OS.get_ticks_msec()

    start()

    for i in range(0,ITERATIONS):
        # Simple code

    _for_time = stop()
    print("For time: " + str(_for_time))

And I quickly realized that the version of Godot I built is 5 times faster than the official 2.0.2. I didn't modified anything in SCons or Godot, just ran a build after following this tutorial from GamesFromScratch: http://www.gamefromscratch.com/post/2015/06/18/Godot-and-Visual-Studio.aspx

As discussed on IRC, this could be caused by the use of another compiler. So I tried with prior versions, and 2.0.0 is also 5 times faster than 2.0.1 and 2.0.2. I personally used msvc12, but msvc14 could be even better.

If we can get such performance gains, would it be possible to provide builds made with these compilers on the appropriate platforms?

[akien-mga]

Are you build with tools or only the template? And release_debug or debug? Are you running your script in the editor or in an exported game?

There might be compiler-specific differences, though 5 times faster seems quite surprising. We'd need someone to do a real comparison of binaries made with MSVC, MinGW on Windows and MinGW on Linux, all built on the same machine with the same arguments, so that we can properly compare their performance.

The 2.0 binaries were also built on Linux with MinGW AFAIK, but on a different server, so potentially different version of the compiler.

[slapin]

print is a bad benchmark, Windows console is slow as hell.

On Thu, Apr 14, 2016 at 8:38 AM, Rémi Verschelde notifications@github.com wrote:

Are you build with tools or only the template? And release_debug or debug? Are you running your script in the editor or in an exported game?

There might be compiler-specific differences, though 5 times faster seems quite surprising. We'd need someone to do a real comparison of binaries made with MSVC, MinGW on Windows and MinGW on Linux, all built on the same machine with the same arguments, so that we can properly compare their performance.

The 2.0 binaries were also built on Linux with MinGW AFAIK, but on a different server, so potentially different version of the compiler.

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-209771902

[Zylann]

I compiled with Debug configuration, from Visual Studio (which runs SCons in the background anyways). I am running the script in the editor. I also tested in an exported game (official build) and performance is roughly the same.

build.bat command line:

set vc_path=%1
call %vc_path% & scons platform=windows

@slapin printing is not included in the benchmark, I run my tests inside a for loop with a lot of iterations, so Windows console has nothing to do with the speed. Despite a quite naive method, it gives a quick preview, and 5 times is a lot for a preview.

Here is the project I run: http://zylannprods.fr/dl/godot/GDScriptPerformance.zip

[volzhs]

I have this experience too. I tested similar way as this post.

I got slow performance with windows tool built on Linux, MinGW. I got better performace (about 5~7 times faster) with windows tool built on Windows, MSVC 2015 community edition. And tool binary size is much smaller, it's about 17MB.

[Glissando]

Same on my end, using MSVC14

[fracteed]

Damn, that is impressive! Sounds like the official builds for Windows should definitely be built on Windows :)

[slapin]

or optimizations should be enabled.

On Sat, Apr 16, 2016 at 3:47 AM, James Redmond notifications@github.com wrote:

Damn, that is impressive! Sounds like the official builds for Windows should definitely be built on Windows :)

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-210699151

[Zylann]

As akien-mga said, it could be more than just Windows.

@slapin I checked the compilation log, here is a sample of what it says:

cl /Focore\array.windows.tools.obj /c core\array.cpp /TP /TP /nologo /DFREETYPE_ENABLED /Z7 /DDEBUG_ENABLED /DDEBUG_MEMORY_ENABLED /DD3D_DEBUG_INFO /Od /MT /Gd /GR /nologo [...]

There is the /Od flag on, which means no optimization. https://msdn.microsoft.com/en-us/library/k1ack8f1%28v=vs.120%29.aspx Performance could then be even better in release mode :]

[techtonik]

That benchmark would be nice to have from cmdline.

Stable release binaries are compiled with gdb symbols. I don't know how it affect performance, but it makes debugging godot crashes much easier. As easy as r and bt.

[DriNeo]

This is surprising. It could be interesting to run other benchmarks.

[vnen]

Stable release binaries are compiled with gdb symbols.

Only the editor IINM, to allow in-editor debugging. The export templates have no debug symbols.

Anyway, it is interesting to have more benchmarks.

[slapin]

About debugging symbols - they don't affect performance at all. But Godot debug biaries are built without optimizations, too (that makes debugging easier because it is easier to factor-out problem code in this case).

On Mon, Apr 18, 2016 at 2:38 AM, George Marques notifications@github.com wrote:

Stable release binaries are compiled with gdb symbols.

Only the editor IINM, to allow in-editor debugging. The export templates have no debug symbols.

Anyway, it is interesting to have more benchmarks.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-211128823

[alexisgea]

I don't know how to compile Godot but I would like to confirm I noticed the same performance drop from 2.0 and 2.0.2 (I was sent here from reddit) : https://www.reddit.com/r/godot/comments/4fjlua/performance_drop_with_latest_update/

[Zylann]

I created a repository with my tests: https://github.com/Zylann/gdscript_performance

[mattiascibien]

Would it be a good idea to add appveyor as a build server to prevent cross compile?

[akien-mga]

Would it be a good idea to add appveyor as a build server to prevent cross compile?

Yes that's something that we should look into. I'd prefer having everything done in Travis CI, but if there's a real performance loss due to cross-compiling, doing native builds with AppVeyor is the way to go.

[mattiascibien]

@akien-mga I am actually investigating on an appveyor.yml for building godot with appveyor. Should build both x86 and x64 for both release and debug right? PlutoBoy seems to have a good appveyor.yml for building something with scons. I will try something in my fork

[akien-mga]

@mattiascibien It should be the tools (tools=yes) with target=release_debug, and the export templates (tools=no) with target=release and target=release_debug. And that for both bits=32 and bits=64 yeah (though the bits argument just got removed in #4274 for the master branch, but it's still in use in the 2.0 branch for now).

IIRC @Marqin also started looking into building Godot with AppVeyor, he might have a WIP config in his fork too.

[mattiascibien]

Ok... It seems that @Marqin's work is definetely almost complete i guess. I'll leave it to him then, sorry for the duplicate.

[Marqin]

Yep, but my work is not compatibile with #4274 ( I'm using my own changed detect.py there )

[techtonik]

I'd like official builds to come with gdb support regardless of performance.

[Zylann]

@techtonik on Windows? Anyways, as akien-mga said, 2.0 was built with MinGW so using the right version rather than switching to msvc could also bring better results. I'm curious :) I would prefer using Visual Studio to debug on Windows (the debugger is great and command line is crappy on Windows), even though I mostly debug with a custom built Godot.

Also, I should note that my benchmarks only concern GDScript. I'm not sure if the ratio is the same for native code, I don't have the same environment setup to test cross-compile with MinGW. Benchmarking C++ could give a clue about what is actually slower, maybe the way memory is allocated, or how well GDScript is optimized by the compiler? (because obviously, GDScript does different things than the graphics engine).

[techtonik]

@Zylann yes, on Windows. Getting into gdb and getting the right stacktrace in copy/pasteable format is so much easier than trying to find your way through all the details. I am not sure if same Linux tools can be used to profile godot binaries there.

BTW, can we collect benchmark results on https://github.com/Zylann/gdscript_performance page? Using downloadable version and custom one with and without debug. Godot still fails to run on my system without ANGLE, so I can't test it myself for the moment.

[Marqin]

@mattiascibien I've just PRed working appveyor.yml to godot-builds repo - https://github.com/GodotBuilder/godot-builds/pull/1

[akien-mga]

Could you guys try the Windows binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/master_20160512 ? There's only the 64-bit Windows editor right now, but other binaries should arrive as AppVeyor builds them with MSVC and uploads them (the other binaries are from Travis).

You could then compare with the Windows binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/2.0_20160512, which were cross-compiled on Travis CI with MinGW. Those are from the 2.0 branch while the former are from the master branch, but performance wise it shouldn't make a big difference.

[Zylann]

Just tried, here are my result times for GDScript, with the tools, 64 bits:

Binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/master_20160512 (MSVC):

Empty func (void function call cost): 82
Increment: 34
Increment x5: 173
Increment with member var: 34
Increment with local (outside loop): 32
Increment with local (inside loop): 61
Increment Vector2: 36
Increment Vector3: 36
Increment Vector3 with constant: 34
Increment Vector3 coordinate by coordinate: 933
Unused local (declaration cost): 8
Divide: 58
Increment with dictionary member: 149
Increment with array member: 60
While time (for equivalent with manual increment): 84
if(true) time: 17
if(true)else time: 19
VariantArray resize: 959
VariantArray set element: 19
IntArray resize: 342

Binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/2.0_20160512 (MinGW cross-compiled):

Empty func (void function call cost): 517
Increment: 548
Increment x5: 2765
Increment with member var: 549
Increment with local (outside loop): 546
Increment with local (inside loop): 744
Increment Vector2: 551
Increment Vector3: 539
Increment Vector3 with constant: 550
Increment Vector3 coordinate by coordinate: 6101
Unused local (declaration cost): 170
Divide: 564
Increment with dictionary member: 1484
Increment with array member: 957
While time (for equivalent with manual increment): 1032
if(true) time: 118
if(true)else time: 125
VariantArray resize: 1644
VariantArray set element: 342
IntArray resize: 2417
IntArray set element: 1509

My own custom build (quite old now, I should git pull): note: this is debug mode too, and optimizations are off

Increment: 54
Increment x5: 330
Increment with member var: 65
Increment with local (outside loop): 55
Increment with local (inside loop): 98
Increment Vector2: 88
Increment Vector3: 75
Increment Vector3 with constant: 74
Increment Vector3 coordinate by coordinate: 2983
Unused local (declaration cost): 6
Divide: 82
Increment with dictionary member: 435
Increment with array member: 105
While time (for equivalent with manual increment): 171
if(true) time: 31
if(true)else time: 16
VariantArray resize: 9808
VariantArray set element: 36
IntArray resize: 5665
IntArray set element: 615

[slapin]

Well, the results look like MinGW builds do have optimizations switched off and MSVC builds do optimize. the increment can't be 10 times slower with gcc :)

What test do you run, I'd like to test locally?

On Thu, May 12, 2016 at 7:37 PM, Marc notifications@github.com wrote:

Just tried, here are my result times for GDScript:

Binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/master_20160512 (MSVC):

Empty func (void function call cost): 82 Increment: 34 Increment x5: 173 Increment with member var: 34 Increment with local (outside loop): 32 Increment with local (inside loop): 61 Increment Vector2: 36 Increment Vector3: 36 Increment Vector3 with constant: 34 Increment Vector3 coordinate by coordinate: 933 Unused local (declaration cost): 8 Divide: 58 Increment with dictionary member: 149 Increment with array member: 60 While time (for equivalent with manual increment): 84 if(true) time: 17 if(true)else time: 19 VariantArray resize: 959 VariantArray set element: 19 IntArray resize: 342

Binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/2.0_20160512 (MinGW cross-compiled):

Empty func (void function call cost): 517 Increment: 548 Increment x5: 2765 Increment with member var: 549 Increment with local (outside loop): 546 Increment with local (inside loop): 744 Increment Vector2: 551 Increment Vector3: 539 Increment Vector3 with constant: 550 Increment Vector3 coordinate by coordinate: 6101 Unused local (declaration cost): 170 Divide: 564 Increment with dictionary member: 1484 Increment with array member: 957 While time (for equivalent with manual increment): 1032 if(true) time: 118 if(true)else time: 125 VariantArray resize: 1644 VariantArray set element: 342 IntArray resize: 2417 IntArray set element: 1509

My own custom build (quite old now, I should git pull):

Increment: 54 Increment x5: 330 Increment with member var: 65 Increment with local (outside loop): 55 Increment with local (inside loop): 98 Increment Vector2: 88 Increment Vector3: 75 Increment Vector3 with constant: 74 Increment Vector3 coordinate by coordinate: 2983 Unused local (declaration cost): 6 Divide: 82 Increment with dictionary member: 435 Increment with array member: 105 While time (for equivalent with manual increment): 171 if(true) time: 31 if(true)else time: 16 VariantArray resize: 9808 VariantArray set element: 36 IntArray resize: 5665 IntArray set element: 615

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-218813784

[reduz]

compiling godot with debug or tools also adds a large amount of runtime checks, are you testing both mingw and msvc on release?

On Thu, May 12, 2016 at 2:22 PM, Sergey Lapin notifications@github.com wrote:

Well, the results look like MinGW builds do have optimizations switched off and MSVC builds do optimize. the increment can't be 10 times slower with gcc :)

What test do you run, I'd like to test locally?

On Thu, May 12, 2016 at 7:37 PM, Marc notifications@github.com wrote:

Just tried, here are my result times for GDScript:

Binaries from

https://github.com/GodotBuilder/godot-builds/releases/tag/master_20160512 (MSVC):

Empty func (void function call cost): 82 Increment: 34 Increment x5: 173 Increment with member var: 34 Increment with local (outside loop): 32 Increment with local (inside loop): 61 Increment Vector2: 36 Increment Vector3: 36 Increment Vector3 with constant: 34 Increment Vector3 coordinate by coordinate: 933 Unused local (declaration cost): 8 Divide: 58 Increment with dictionary member: 149 Increment with array member: 60 While time (for equivalent with manual increment): 84 if(true) time: 17 if(true)else time: 19 VariantArray resize: 959 VariantArray set element: 19 IntArray resize: 342

Binaries from https://github.com/GodotBuilder/godot-builds/releases/tag/2.0_20160512 (MinGW cross-compiled):

Empty func (void function call cost): 517 Increment: 548 Increment x5: 2765 Increment with member var: 549 Increment with local (outside loop): 546 Increment with local (inside loop): 744 Increment Vector2: 551 Increment Vector3: 539 Increment Vector3 with constant: 550 Increment Vector3 coordinate by coordinate: 6101 Unused local (declaration cost): 170 Divide: 564 Increment with dictionary member: 1484 Increment with array member: 957 While time (for equivalent with manual increment): 1032 if(true) time: 118 if(true)else time: 125 VariantArray resize: 1644 VariantArray set element: 342 IntArray resize: 2417 IntArray set element: 1509

My own custom build (quite old now, I should git pull):

Increment: 54 Increment x5: 330 Increment with member var: 65 Increment with local (outside loop): 55 Increment with local (inside loop): 98 Increment Vector2: 88 Increment Vector3: 75 Increment Vector3 with constant: 74 Increment Vector3 coordinate by coordinate: 2983 Unused local (declaration cost): 6 Divide: 82 Increment with dictionary member: 435 Increment with array member: 105 While time (for equivalent with manual increment): 171 if(true) time: 31 if(true)else time: 16 VariantArray resize: 9808 VariantArray set element: 36 IntArray resize: 5665 IntArray set element: 615

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub <https://github.com/godotengine/godot/issues/4313#issuecomment-218813784

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-218826088

[Zylann]

I don't know about the exact build options for the two versions from Travis and AppVeyor, but I can say the custom version I built is in debug mode, uses SCons (I didn't touched anything) and according to the logs, optimizations are off, as shown in my previous messages.

I run these simple GDScript tests: https://github.com/Zylann/gdscript_performance

[Marqin]

Try also Bunnnymark.

W dniu czwartek, 12 maja 2016 Marc notifications@github.com napisał(a):

I don't know about the exact build options for the two versions from Travis and AppVeyor, but I can say the custom version I built is in debug mode, uses SCons (I didn't touched anything) and according to the logs, optimizations are off, as shown in my previous messages.

I run these simple GDScript tests: https://github.com/Zylann/gdscript_performance

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-218831777

[vnen]

It seems print does not work on release. But a project running only the script runs noticeably faster with the MSVC-compiled version (I built both my own at 48dc4d9). I'll try later with release_debug but without tools to check the prints.

The Bunnymark cited by @Marqin crashes when I use the Mingw 64-bit version. It can go around ~6000 bunnies in without losing FPS with MSVC-compiled, both 32- and 64-bits. With Mingw-compiled 32-bit I get slowdowns before reaching 2000 bunnies.

---

@slapin please enlighten us on how to add optimization to Mingw build, because AFAIK it's already enabled.

I wouldn't be surprised if Microsoft's compiler to its own platform is more optimized than a port of GCC for Windows. But if there's a way to optimize Mingw builds even further without breaking Godot I'm all open to it.

[slapin]

MSVC can be faster but not 10 times faster. The result is not realistic. Something is just plain broken.

On Thu, May 12, 2016 at 10:43 PM, George Marques notifications@github.com wrote:

It seems print does not work on release. But a project running only the script runs noticeably faster with the MSVC-compiled version (I built both my own at 48dc4d9 https://github.com/godotengine/godot/commit/48dc4d92a8f3c9eb42456eda2433c6fcaff0c723). I'll try later with release_debug but without tools to check the prints.

The Bunnymark https://github.com/jotson/godot-bunnymark cited by @Marqin https://github.com/Marqin crashes when I use the Mingw 64-bit version. It can go around ~6000 bunnies in without losing FPS with MSVC-compiled, both 32- and 64-bits. With Mingw-compiled 32-bit I get slowdowns before

reaching 2000 bunnies.

@slapin https://github.com/slapin please enlighten us on how to add optimization to Mingw build, because AFAIK it's already enabled https://github.com/godotengine/godot/blob/e4765c4831e8249696ac3c94ca28da2218cb236c/platform/windows/detect.py#L338-L347 .

I wouldn't be surprised if Microsoft's compiler to its own platform is more optimized than a port of GCC for Windows. But if there's a way to optimize Mingw builds even further without breaking Godot I'm all open to it.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-218864578

[slapin]

On my PC bunnymark shows 2K bunnies before slowdown, i7 2600K GTX660, Linux and mingw32 build. So it is definitely broken, as on the same PC AAA games work quite well on high settings. So to fix all Godot problems we just need to drop Linux support and move to MSVC. Any Mac testers here?

On Thu, May 12, 2016 at 10:58 PM, Sergey Lapin slapinid@gmail.com wrote:

MSVC can be faster but not 10 times faster. The result is not realistic. Something is just plain broken.

On Thu, May 12, 2016 at 10:43 PM, George Marques <notifications@github.com

wrote:

It seems print does not work on release. But a project running only the script runs noticeably faster with the MSVC-compiled version (I built both my own at 48dc4d9 https://github.com/godotengine/godot/commit/48dc4d92a8f3c9eb42456eda2433c6fcaff0c723). I'll try later with release_debug but without tools to check the prints.

The Bunnymark https://github.com/jotson/godot-bunnymark cited by @Marqin https://github.com/Marqin crashes when I use the Mingw 64-bit version. It can go around ~6000 bunnies in without losing FPS with MSVC-compiled, both 32- and 64-bits. With Mingw-compiled 32-bit I get

slowdowns before reaching 2000 bunnies.

@slapin https://github.com/slapin please enlighten us on how to add optimization to Mingw build, because AFAIK it's already enabled https://github.com/godotengine/godot/blob/e4765c4831e8249696ac3c94ca28da2218cb236c/platform/windows/detect.py#L338-L347 .

I wouldn't be surprised if Microsoft's compiler to its own platform is more optimized than a port of GCC for Windows. But if there's a way to optimize Mingw builds even further without breaking Godot I'm all open to it.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-218864578

[Marqin]

Well, also keep in mind that travis uses mingw 4.2 from 2007 :P And MSVC used here is from 2015.

we just need to drop Linux support

WTF. What does Linux support have to do with Windows builds?

[mefihl]

Bunnymark on Godot 2.0.2 official on my PC (i7 2600K GTX670, Windows 10 64bit) frame drop to 56 at 1640 object after export to exe in release mode. https://github.com/jotson/godot-bunnymark

[Marqin]

@mefihl and for 2.0.3 https://github.com/GodotBuilder/godot-builds/releases/tag/2.0.3-stable ?

[akien-mga]

@mefihl and for 2.0.3 https://github.com/GodotBuilder/godot-builds/releases/tag/2.0.3-stable ?

Try http://downloads.tuxfamily.org/godotengine/2.0.3/ instead, I just deleted this tag and recreated it to push a hotfix to 2.0.3 ;)

[slapin]

Deleting tags in public repos is very, very bad idea. When you do that a new family of kitties is put in another sack for drowning. You better create branches for all releases for hotfixing, and tag them with additional tags if necessary. This is real practice.

On Fri, May 13, 2016 at 11:05 AM, Rémi Verschelde notifications@github.com wrote:

@mefihl https://github.com/mefihl and for 2.0.3 https://github.com/GodotBuilder/godot-builds/releases/tag/2.0.3-stable ?

Try http://downloads.tuxfamily.org/godotengine/2.0.3/ instead, I just deleted this tag and recreated it to push a hotfix to 2.0.3 ;)

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-218977922

[akien-mga]

Yes and no. Deleting a tag for a release that has never been announced is not problematic, and way less clutter than having to issue a 2.0.3-1 or 2.0.4 to add a commit. If 2.0.3 had been published already, I would have done differently, but here, trust me, I know what I'm doing.

[slapin]

Well, only Linux and mingw depend on gcc, so dropping it will have problem solved. And no, that is not gcc 4.2 vs gcc-4.x or 6.x, the current Linux results show the same problems as Windows-mingw results.

On Fri, May 13, 2016 at 2:06 AM, Hubert Jarosz notifications@github.com wrote:

Well, also keep in mind that travis uses mingw 4.2 from 2007 :P And MSCV used here is from 2015.

we just need to drop Linux support

WTF. What does Linux support have to do with Windows builds?

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-218910731

[slapin]

You better create the branches. You will thank me later for advising you this. Look at existing workflows from people who know shit, like Kernel people - use stable branches for hotfixing. This makes hotfixing a normal practice, not hacky workouts. And you can use different tagging system - like tag 10.0 for release, and for fixes use tag 10.0.1, 10.0.2, but tag only hotfixes in stable branches, not master Branches are cheap and powerful, use them. It quite looks like you don't understand what tag is for and what branch is for,

On Fri, May 13, 2016 at 4:41 PM, Rémi Verschelde notifications@github.com wrote:

Yes and no. Deleting a tag for a release that has never been announced is not problematic, and way less clutter than having to issue a 2.0.3-1 or 2.0.4 to add a commit. If 2.0.3 had been published already, I would have done differently, but here, trust me, I know what I'm doing.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-219046026

[akien-mga]

We're not dropping anything. End of the discussion.

Now if we want to investigate properly why we see such performance differences, that could be helpful. And if it's established that all GCC builds are less performant, and that it's not an optimization flag issue on our side, we could ask upstream directly.

[slapin]

This is not gcc problem either, it is either optimization problem or bad code problem. MSVC does a lot of tricks, so comparison of unoptimized builds of gcc vs MSVC is useless. You can't tell MSVC to not optimize, while gcc if asked to not optimize will prevent optimizations. Otherwise comparison of tools-optimized (release_debug) adds only basic gcc optimizations. But relying only on compiler here is not really a good thing, as bad code will give random results with different compilers. There looks to be something very badly written, which probably needed to pe optimized by brain, not compiler.

On Fri, May 13, 2016 at 4:48 PM, Rémi Verschelde notifications@github.com wrote:

We're not dropping anything. End of the discussion.

Now if we want to investigate properly why we see such performance differences, that could be helpful. And if it's established that all GCC builds are less performant, and that it's not an optimization flag issue on our side, we could ask upstream directly.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-219047810

[akien-mga]

PRs welcome.

[slapin]

On Fri, May 13, 2016 at 4:48 PM, Rémi Verschelde notifications@github.com wrote:

We're not dropping anything. End of the discussion.

Also I think Godot needs to focus on engine features and publicity, so dropping a few broken platforms will mean less bad reviews. As I see no power to fix this all issues in any foreseeable future, I think dropping is not so bad option.

Now if we want to investigate properly why we see such performance differences, that could be helpful. And if it's established that all GCC builds are less performant, and that it's not an optimization flag issue on our side, we could ask upstream directly.

Well, gcc is well established power, much more powerful than tiny godot. Before blaming compiler, it is much better to run profilers on windows and Linux and think. But thinking is not an option.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-219047810

[slapin]

As it seems we're really going to be constructive here, I think we can safely close this as "GCC vs MSVC issue. Nobody knows and nobody cares". will look good, and laso can be used as "black hole bug" for other bugs like this in future.

On Fri, May 13, 2016 at 4:58 PM, Rémi Verschelde notifications@github.com wrote:

PRs welcome.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-219050471

[akien-mga]

@slapin Thanks for your valuable input, we will pass than onto our Customer Support Team and they will come back to you once your request has been assessed.

[volzhs]

I'm not sure since when. As I remember, performance was fine with gcc compile until 2.0 first release. But performance drop happened some days later.

[slapin]

Lets not turn this into flame war just out of everybody's lack of commitment. If you want to discuss this farther, feel free to ping me on IRC.

On Fri, May 13, 2016 at 5:03 PM, Rémi Verschelde notifications@github.com wrote:

@slapin https://github.com/slapin Thanks for your valuable input, we will pass than onto our Customer Support Team and they will come back to you once your request has been assessed.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/godotengine/godot/issues/4313#issuecomment-219051813

[Zylann]

@slapin: we can tell MSVC to not optimize: /Od https://msdn.microsoft.com/en-us/library/k1ack8f1%28v=vs.120%29.aspx (and optimizations are off). Comparing with optimizations on both sides sounds relevant.

@volzhs true. 2.0 and 2.1 have this difference, and both used MinGW according to @akien-mga (way up in the thread).