@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¢.
@Morgan_Hardwood this is what I understand about those march and mtune flags:
The 32bit msys2 GCC6.1 was built with " --with-arch=i686" default target hw ( use GCC -v to see on your conf).
Thus, If I understand, by default (vithout using -march option), the code will be generated with -march=i686 and thus will not use SSE and SSE2 instructions. In this case it is better not to use rawtherapee.
Regarding mtune= generic, I tried to see what difference it brings in the passed options using
echo “int main {return 0;}” | gcc [OPTIONS] -x c -v -Q -
replacing [OPTIONS] successively with “-march=native” and “-march=native -mtune=generic” . Difference is not easy to identify.
Nevertheless, -mtune=generic cannot hurt and I will add it.
It seems there are still a few people with WinXP and WinVista 32.
GTK3 branch I build cannot run on WinXP and only run on WinVista and above.
André
Does anyone know where I can download latest locallab build for Win7 64?
Last one seems to be here
Page is expired 1 month ago 
@LZ1, Jacques Desmis (@jdc) who develops the Local Lab filter, recently changed the filter to allow several control points in Local Lab. This is still experimental, so I just asked him if he would be okay if I make a new build from the current code. If Jacques agrees, I’ll post the link here.
1 Like
@floessie I did not know about scheduling differences, thanks for pointing that out. I thought the more important thing was making use of all instruction sets supported by the CPU.
Someone on a forum put it like this:
@gaaned92 it looks like you are correct about GCC defaulting to the target it was built for or to a “default spec” if -march is not specified. You are also right that generic does not use SSE - I thought it did.
Since your -march=native will default to -march=i686, and since march implies mtune, then I believe the correct thing would be: -march=generic -mtune=i686
But my understanding of GCC is just scratching the tip of the iceberg, and I may be totally wrong about everything 
IFAIK there is no such thing like -march=generic. What ISA should that be? -march=native was included i.a. for the Gentoo people and lets to compiler decide to use the ISA it is compiling on (not the default ISA it was built for). So instead of guessing the ISA, @gaaned92 should probably define it to -march=i686 and give it a bit of a tuning by saying -mtune=intel or -mtune=generic.
HTH
Flössie (with ö )
@floessie @Morgan_Hardwood
-march=I686 will define a very old architecture without sse that will generate a very slow build using no Ingo improvement. It is the gcc default for 32 bit. I think RT will not be usable in those conditions.
-march=native on my PC is equivalent to march=nocona which is an architecture with sse and sse2 so using performance improvements.
Note : if you do not specify march flag, gcc will use a default one.
As i said above, I am not able to identify what tuning brings mtune =generic or intel seeing the passed options.
André
Hi André,
then I’d go for -march=nocona instead of -march=native to make your build independent of the CPU you build on. I wasn’t aware that you were not aiming for an i686 build, sorry.
I’d only expect very subtle differences. Maybe not even worth the effort.
Best
Flössie
Of course not, and I know that, so why did I write that? 
March implies mtune, so -march=i686 implies -mtune=i686 and the docs say that i686==generic, so in that case no need for mtune at all…?
[quote=docs]
‘i686’
When used with -march, the Pentium Pro instruction set is used, so the code runs on all i686 family chips. When used with -mtune, it has the same meaning as ‘generic’. [/quote]
I asked about that yesterday on #gcc
They told me stories of triplets and targets and other things I couldn’t possibly repeat.
The question was: “Hello, if one does not specify -march or -mtune, and if gcc was compiled with -march=foo, does that mean that when i compile something it will default to -march=foo?”
Here’s a copypasta of the log:
I’m not exactly sure, but what I think you certainly need is to ./configure gcc -with --target=${target-triple} as a start
gcc loves triples, and even loves to actually know what libc it’s compiling with (i.e. the triple must end with -musl and not -gnu if compiling for musl libc afaik)
the -march=foo gcc is compiled with only affects gcc itself, not the code it compiles. Configure gcc with --with-arch=foo if you want to alter the default -march for code compiled by it
for some targets the default is also set by the machine type, e.g. a gcc configured for i686-pc-linux-gnu is equivalent to one configured for i386-pc-linux-gnu using --with-arch=i686
Fun discussion
Best regards
Mörgan
Yep!
That’s clear (to me at least). Leaving out -march will compile for the default spec as given with --with-arch when building GCC.
Many thanks !!
RawTherapee is absolutely non-responsive for me on Window10. I have installed the latest 54-bit build (I have tried both ‘fast’ and ‘debug’). I don’t boot Windows often, I typically boot Linux and I build RawTherapee from source and RawTherapee works perfectly well on Linux. There are some tasks I need to do in Windows though and I find it convenient then to have Rawtherapee available, but more often than not I have to bail out on Windows.
I have removed the options file in AppData/Local/RawTherapee to no avail. I have added a ‘cluts’ directory in C:\Program Files\RawTherapee… The program can take five minutes to show the main panel.
There must be something … Surely it works for someone. I have tried many versions during the last year, but I always end up with an unresponsive RawTherapee. It looks a bit inconsistent, since sometimes I managed to process a picture. I guess I don’t use Windows often enough so there are some tricks I don’t know of yet.
Hi @rlx009
Are you on Win10 32- or 64-bit?
Anniversary edition or “the old one”?
The version I presently have installed on this partition
is RT 4.2.1234 and yes, it works just fine.
Which RT version does not behave properly on your machine?
Tell me from where you got it so can I try it here as well, if
you’d like.
Hi Claes,
I am running Win10 64-bit Pro. This is the free upgrade from Vista-Pro I have done quite early after Win10 went out. Last upgrades installed yesterday.
I am now booted in Linux but I can see that the latest download I tried earlier this morning was RawTherapee_WinVista_64_Gtk3_Release_4.2.1234.zip.
I got it from http://rawtherapee.com/downloads’
I have tried at least two other versions before (I can’t recall which ones) and always ended up with that problem.
I wait until I boot Linux to process my pictures.
Oh dear, that is exactly the same source I got my RawTherapee_WinVista_64_Gtk3_Release_4.2.1234.zip from – which means that I just ran out of ideas on how to assist you Sorry!
Let’s hope that one of the better brains will chime in…