#8786 closed patch
better optimization settings for msvc9
| Reported by: | SF/matt_hargett | Owned by: | bluegr |
|---|---|---|---|
| Priority: | normal | Component: | Port: Win32 |
| Version: | Keywords: | ||
| Cc: | Game: |
Description
The only potential controversial thing is here is enabling SSE by default, which is probably a safe bet. To "port" to other MSVC versions: -enable Full Optimization (/Ox) -enable intrinsic functions (/Oi) -favor small code (/Os) -turn on SSE (/arch:SSE) -make sure link-time code generation (/GL) is turned on
Ticket imported from: #1877032. Ticket imported from: patches/891.
Attachments (1)
Change History (15)
by , 17 years ago
| Attachment: | msvc9-optimizations.diff added |
|---|
comment:1 by , 17 years ago
I had a look at your patch and I was wondering: why have you only made optimizations to the release version, and not the debug one as well?
Do note that I have tested this patch with MSVC8 and it works fine, I'll test it with MSVC9 in the afternoon as well
comment:2 by , 17 years ago
| Owner: | set to |
|---|
comment:3 by , 17 years ago
Another question: why would you want to favor small code (/Os) and not fast code (/Ot) ?
It seems all of these options could be used for a debug build too, apart from /GL, as it does optimization on the whole project and not on a per module basis (which makes debug building take ages...). However, it sounds good for a release build.
I am not very comfortable with turning on SSE by default, as this doesn't work under 64 bit operating systems. What happens when trying to build under a 64 bit OS with this option on by default? Does it build at all or does compilation fail?
comment:4 by , 17 years ago
Also, some references on the various compilation options: /Ox http://msdn2.microsoft.com/en-us/library/kfz8ad09.aspx /Oi http://msdn2.microsoft.com/en-us/library/f99tchzc.aspx /Os and /Ot http://msdn2.microsoft.com/en-us/library/f9534wye.aspx /arch http://msdn2.microsoft.com/en-us/library/7t5yh4fd.aspx /GL http://msdn2.microsoft.com/en-us/library/f9534wye.aspx
Also, I'm not sure if /Gm (minimal rebuild) can be useful as well: http://msdn2.microsoft.com/en-us/library/kfz8ad09.aspx
This seems good for a debug build, but I guess it would mess up any optimizations in a release build
comment:5 by , 17 years ago
SSE is guaranteed to work on all x86-64 CPUs, so I'm not sure what you mean.
You don't want to add optimizations in to the debug build, as it makes things more difficult for the debugger. Optimizations are also incompatible with the runtime checks (/RTC1) that can help find memory corruption issues.
Small code is preferred by Microsoft themselves, as it takes up less memory and disk space and it more performant with prefetches/caches/etc.
Minimal rebuild will increase the binary size and doesn't aid performance in any way.
comment:6 by , 17 years ago
I'm asking about SSE (/arch:SSE) on 64bit CPUs, cause there's a note on Microsoft's site about it: "/arch is only available when compiling for the x86 platform. This compiler option is not available when compiling for x64 or Itanium."
So, if I'm not mistaken, if this is specified and someone tries to compile under a 64bit CPU, it will ignore the flag and compile anyway, right? Or will it stop compilation with an "unsupported compiler option"? It wouldn't be nice to have compilation errors on 64-bit architectures, that's why I'm asking about this switch's behavior.
Thanks for the rest of your comments :) If the executable compiles correctly under 64-bit operating systems, then your patch can be safely committed, I'd just like some feedback on this switch before committing though.
comment:7 by , 17 years ago
Sorry, in my previous message, substitute: "So, if I'm not mistaken, if this is specified and someone tries to compile under a 64bit CPU..." with: "So, if I'm not mistaken, if this is specified and someone tries to compile under a 64bit operating system..."
comment:9 by , 16 years ago
I guess this patch is somewhat outdated by now (we have some new engines, like tinsel, which are not covered by it). But overall, without having a windows machine, it seems sensible to apply this. As long as the optimizations are restricted to the released build, for the reasons matt already explained.
Matt, can you provide an updated patch? And maybe use msvc9_to_msvc8.bat & msvc8_to_msvc7_71.bat to update the other project files, too, if it makes sense?
comment:10 by , 16 years ago
Changed MSVC settings for the release version in the trunk, for all current engines and adapted the MSVC 8 -> MSVC 7/7.1 batch file accordingly. I have NOT enabled SSE by default though, as it's not available under 64-bit platforms
Closing
comment:11 by , 16 years ago
| Status: | new → closed |
|---|
comment:12 by , 16 years ago
Hm? Now I am confused. I thought the point was that *all* 64-bit processors ships with SSE (or rather, SSE2), so I would have thought for 64-bit chips, you can't even disable the SSE optimization (as that wouldn't make sense) ?!? Whatever :)
comment:13 by , 16 years ago
I'm not sure really. Refer to this page: http://msdn.microsoft.com/en-us/library/7t5yh4fd.aspx
"/arch is only available when compiling for the x86 platform. This compiler option is not available when compiling for x64 or Itanium."
I don't know if using /arch:SSE breaks compilation under x64, so I preferred to take the safe way and not break compilation... I've been asking for a response on the SSE flag in my previous messages, got none, so unless there is some feedback on this from a Windows x64 user, I don't think it would be wise to enable this option by default
comment:14 by , 6 years ago
| Component: | → Port: Win32 |
|---|
diff of the vcproj files