Thank you, this is what I meant.
@Morgan_Hardwood I’m waiting for the next merge of master into Gtk3 branch to make new builds for Windows 64 bits. Let me know when you do it.
4 Likes
@sguyader @Morgan_Hardwood I’ve merged #3429 to master. @Hombre also fixed #3186, so this is going to be a great GTK3 build. 
2 Likes
Master merged into gtk3.
2 Likes
New Windows 64-bit builds (Release and Debug) can be downloaded from here:
- Master branch 4.2.1069 (new improvements)
- Gtk3 branch 4.2.1234 (new improvements)
4 Likes
Build is 4.2.1234… And wow is this running snappy over here! Very nice work everybody! Many thanks!
1 Like
you will find in my RT W32 drive:
master branch 4.2.1072 (release and debug)
GTK3 branch 4.2.1234 (release and debug)
1 Like
wow, new version uploaded 5 minutes after I commited a fix. That’s really fast 
It always amuses me when I download a build and upload it to VirusTotal for scanning to find that it was just scanned already 
Thank you, the builds are live.
I just saw the Win32 builds are built using -march=native.
Is that intended?
That’s me. 
Is there any difference between the downloads from ‘the file bin’ and the downloads of the same number at the Rawtherapee download page? Just wondering.
None.
@Morgan_Hardwood
Ages ago this was discussed and at this time, if I remember, -march=native seemed the safer flag and providing better performance. But at this time, Ingo did not yet drastically improved the performance and stability of code.
Furthermore, as I build on a Prescoott hardware, only very very old hardware will be unable to run the code (those missing mmx, sse and sse2).
With mtune=generic, I don’t know what is the target hw for which GCC6.1 is supposed to optimize the code. Is it still old i686 hw ?
Though it seems nobody complained for years about impossibility to run the build, if you think it worth, I can provide build with mtune=generic.
Of course, for those building on recent processor, the choice of march =native is incompatible with the distribution of build.
@gaaned92 If nobody ever complained, I would let it as it is now (never change a runninng system).
Sorry for the noise
Using -march=native is not a good idea for (at least) two reasons:
- It will not run on older CPUs (but we don’t care, Intel Pentium 4 Prescott is already very old),
- The build will be optimized for that very old CPU. If someone with a newer CPU uses it, the build won’t take advantage of the newer features and instruction sets and will run slow.
If instead of -march you use -mtune=x where “x” is a CPU better than yours which people nowadays are likely to use with Windows XP, then those builds will still run fine on your CPU and on older CPUs but will also take advantage of the newer features on the newer CPU. That’s the picture I got from reading the GCC docs anyway. Which CPU to target? I don’t know what most of our Windows XP users use. Actually the Pentium 4 is a good choice - it seems to be the latest 32-bit CPU, and anyone using a newer CPU is using a 64-bit one and should be using a 64-bit OS.
In summary, it’s probably good in this case to use “native”, but use it with -mtune not with -march.
Actually it won’t use newer features, it will only schedule instructions in a way that is executed faster on the CPU you tune for. Just my 2¢.