Opened 17 years ago

Closed 16 years ago

Last modified 6 years ago

#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)

msvc9-optimizations.diff (20.3 KB ) - added by SF/matt_hargett 17 years ago.
diff of the vcproj files

Download all attachments as: .zip

Change History (15)

by SF/matt_hargett, 17 years ago

Attachment: msvc9-optimizations.diff added

diff of the vcproj files

comment:1 by bluegr, 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 bluegr, 17 years ago

Owner: set to bluegr

comment:3 by bluegr, 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 bluegr, 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 SF/matt_hargett, 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 bluegr, 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 bluegr, 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:8 by sev-, 16 years ago

What is the status of this item?

comment:9 by fingolfin, 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 bluegr, 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 bluegr, 16 years ago

Status: newclosed

comment:12 by fingolfin, 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 bluegr, 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 digitall, 6 years ago

Component: Port: Win32
Note: See TracTickets for help on using tickets.