Re: [Gimp-developer] GIMP and multiple processors
Hi, Jay Cox [EMAIL PROTECTED] writes: Here are some results for you: Dual 2.5ghz g5 mac, mac os x 10.3.8 CVS gimp Changelog revision 1.10539 Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 Processor: 7.98 seconds1x 2 processors: 5.20 seconds1.5x 3 processors: 5.23 seconds1.5x Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor: 3.89 seconds1x 2 processors: 2.37 seconds1.7x 3 processors 2.40 seconds1.7x Clearly the gradient code could use some tuning. A linear blend shouldn't take much more than 1/2 a second even with dithering. The reason why the dithering case gets less of a speedup is because the threads are fighting over the GRand state. Each thread needs to have it's own GRand state. It looks like the threads are also fighting over gradient-last_visited. My guess is that fixing this will get us much closer to the ideal 2x speed up. Eeek, I didn't think about gradient-last_visited. While the use of GRand is MT-safe, accessing the gradient obviously isn't. So this is not only slowing things done, it is a race condition that can lead to broken results. We definitely need to fix this or revert back to a non-parallel version of gimp_gradient_blend(). BTW, thanks for fixing my threads code and also thanks for these benchmarks! Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP and multiple processors
On 26.02.2005, at 02:44, Jay Cox wrote : Dual 2.5ghz g5 mac, mac os x 10.3.8 CVS gimp Changelog revision 1.10539 Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 Processor: 7.98 seconds1x 2 processors: 5.20 seconds1.5x 3 processors: 5.23 seconds1.5x Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor: 3.89 seconds1x 2 processors: 2.37 seconds1.7x 3 processors 2.40 seconds1.7x Oh, I wouldn't have though that disabling dithering makes such a difference but indeed it does. Same game on Dual Opteron again with latest sources: Linear Gradient blend on a 3000x3000 pixel image (Dithering on) 1 processor:7.5 s 2 processors: 9.6 s 4 processors: 9.6 s Linear Gradient blend on a 3000x3000 pixel image (Dithering OFF) 1 processor:3.0 s 2 processors: 2.5 s 4 processors: 2.5 s Each time determined over three runs. Deviation is too small to measure. So with dithering there's a loss and without a slight win on this box with several threads. Servus, Daniel PGP.sig Description: This is a digitally signed message part
[Gimp-developer] Makefile fix for srcdir != objdir
Hija, I'm throwing the following fix for consideration. The problem is that by standard headers are looked for in various locations under the srcdir, however there're also header files which are automatically generated and (rightfully) put into objdir but are not searched for there. This breaks builds where srcdir != objdir. My simple fix is to add another include search path relative to the current directory (i.e. objdir) where needed. I realize that there might be better ways to fix that which I currently can not see so I'm posting it here with a RFC. Index: app/display/Makefile.am === RCS file: /cvs/gnome/gimp/app/display/Makefile.am,v retrieving revision 1.42 diff -u -r1.42 Makefile.am --- app/display/Makefile.am 13 Feb 2005 15:08:04 - 1.42 +++ app/display/Makefile.am 26 Feb 2005 17:10:39 - @@ -75,6 +75,7 @@ INCLUDES = \ -I$(top_srcdir) \ -I$(top_srcdir)/app \ + -I..\ $(GTK_CFLAGS) \ -I$(includedir) Index: app/tools/Makefile.am === RCS file: /cvs/gnome/gimp/app/tools/Makefile.am,v retrieving revision 1.88 diff -u -r1.88 Makefile.am --- app/tools/Makefile.am 13 Feb 2005 15:08:07 - 1.88 +++ app/tools/Makefile.am 26 Feb 2005 17:10:39 - @@ -157,6 +157,7 @@ INCLUDES = \ -I$(top_srcdir) \ -I$(top_srcdir)/app \ + -I..\ $(GTK_CFLAGS) \ -I$(includedir) Index: app/vectors/Makefile.am === RCS file: /cvs/gnome/gimp/app/vectors/Makefile.am,v retrieving revision 1.16 diff -u -r1.16 Makefile.am --- app/vectors/Makefile.am 13 Feb 2005 15:08:07 - 1.16 +++ app/vectors/Makefile.am 26 Feb 2005 17:10:40 - @@ -7,6 +7,7 @@ INCLUDES = \ -I$(top_srcdir) \ -I$(top_srcdir)/app \ + -I..\ $(GDK_PIXBUF_CFLAGS)\ $(LIBART_CFLAGS)\ -I$(includedir) Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Makefile fix for srcdir != objdir
Hi, Daniel Egger [EMAIL PROTECTED] writes: I'm throwing the following fix for consideration. The problem is that by standard headers are looked for in various locations under the srcdir, however there're also header files which are automatically generated and (rightfully) put into objdir but are not searched for there. This breaks builds where srcdir != objdir. My simple fix is to add another include search path relative to the current directory (i.e. objdir) where needed. I realize that there might be better ways to fix that which I currently can not see so I'm posting it here with a RFC. Looks like the wrong fix to me. Instead we should change the Makefiles to look for the generated files in the right spot (and .. isn't the right spot). Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] GIMP fails to compile without C++ compiler?
Hija, just curious, is it expected that configuration of a GIMP build will fail if configure cannot find a C++ compiler? ... checking for dlfcn.h... yes checking for g++... no checking for c++... no checking for gpp... no checking for aCC... no checking for CC... no checking for cxx... no checking for cc++... no checking for cl... no checking for FCC... no checking for KCC... no checking for RCC... no checking for xlC_r... no checking for xlC... no checking whether we are using the GNU C++ compiler... no checking whether g++ accepts -g... no checking dependency style of g++... none checking how to run the C++ preprocessor... /lib/cpp configure: error: C++ preprocessor /lib/cpp fails sanity check See `config.log' for more details. By supplying a C++ compiler via CXX env variable it happily passes that point: ... checking for dlfcn.h... yes checking whether we are using the GNU C++ compiler... yes checking whether g++-3.4 accepts -g... yes checking dependency style of g++-3.4... gcc3 checking how to run the C++ preprocessor... g++-3.4 -E checking for g77... no ... config.log unfortunately doesn't tell anything sensible... Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On 26.02.2005, at 20:23, Sven Neumann wrote: Looks like the wrong fix to me. Instead we should change the Makefiles to look for the generated files in the right spot (and .. isn't the right spot). Actually .. is the right spot since make is moving in and out of the objdir. However I can see why you would prefer an obsolute path, that's why I was asking this question. Anyway, libtool is using objdir for it's internal object management which is for instance some .libs directory on Linux machines, so we can pretty much forget about using this. Instead we'd need a new variable into the game and the closest I can think of is far nastier than three relative paths which at least won't require major surgery. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Makefile fix for srcdir != objdir
Hi, Daniel Egger [EMAIL PROTECTED] writes: Actually .. is the right spot since make is moving in and out of the objdir. However I can see why you would prefer an obsolute path, that's why I was asking this question. Anyway, libtool is using objdir for it's internal object management which is for instance some .libs directory on Linux machines, so we can pretty much forget about using this. Instead we'd need a new variable into the game and the closest I can think of is far nastier than three relative paths which at least won't require major surgery. What's wrong with $(top_builddir)? BTW, the problems you are seeing only apply to builds from CVS. The tarball has all the generated source files, so everything is where the Makefiles are looking for it. It appears though that we do indeed require to build a CVS checkout in the srcdir. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On 26.02.2005, at 23:44, Sven Neumann wrote: What's wrong with $(top_builddir)? Ho hum. That's a relative path as well, so instead of -I.. that would be -I$(top_builddir)/app which gets expanded to -I../../app . We could do that but I don't really see the big advantage instead of just using my originally proposed patch. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On 26.02.2005, at 23:44, Sven Neumann wrote: BTW, the problems you are seeing only apply to builds from CVS. The tarball has all the generated source files, so everything is where the Makefiles are looking for it. It appears though that we do indeed require to build a CVS checkout in the srcdir. Another thing's fishy wrt the generated C files. For some reason make will bail out on any of them because they're being generated in the wrong place, however if I restart make often enough it will eventually pick up the correct files and compile them Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On 26.02.2005, at 23:44, Sven Neumann wrote: Anyway, libtool is using objdir for it's internal object management which is for instance some .libs directory on Linux machines, so we can pretty much forget about using this. Instead we'd need a new variable into the game and the closest I can think of is far nastier than three relative paths which at least won't require major surgery. What's wrong with $(top_builddir)? Maybe nothing, except that I didn't see it before. Would a patch like the former but with absolute paths instead of the relative ones be okay for CVS after a verification build? BTW, the problems you are seeing only apply to builds from CVS. The tarball has all the generated source files, so everything is where the Makefiles are looking for it. It appears though that we do indeed require to build a CVS checkout in the srcdir. Indeed, however not having to clutter the srcdir with generated files and other cruft is a big must-have in my book especially while developing, so I'm sort of confused that this hasn't shown up earlier... How can I get the stuff pre-built so that this is supposed to work? Besides, there're some checks missing in configure for applications which are really needed to build from CVS, like intltool and xsltproc. Especially for the latter it's really annoying that I can get through configure just fine but in menus/ the Makefile will bail out because xsltproc is desperately needed, so I need to install it and rerun configure to get rid of the problem; not the finest English... Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP and multiple processors
Hi again, Jay Cox [EMAIL PROTECTED] writes: Clearly the gradient code could use some tuning. A linear blend shouldn't take much more than 1/2 a second even with dithering. Could we improve this by preparing a reasonably fine array of samples and picking from these samples instead of calling gimp_gradient_get_color_at() over and over again? The reason why the dithering case gets less of a speedup is because the threads are fighting over the GRand state. Each thread needs to have it's own GRand state. It looks like the threads are also fighting over gradient-last_visited. My guess is that fixing this will get us much closer to the ideal 2x speed up. I have eliminated last_visited from the gradient struct. Instead the caller of gimp_gradient_get_color_at() may now do the same optimization without any caching in the gradient itself. I very much doubt that this makes any difference though. Perhaps if you would benchmark a gradient blend with a lot of segments. But in the general case it's just a few of them, very often even only a single one. Now that this race condition is eliminated I might look into adding hooks to the pixel-processor to allow initialisation of per-thread data, like for example a GRand. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
Hi, Daniel Egger [EMAIL PROTECTED] writes: Would a patch like the former but with absolute paths instead of the relative ones be okay for CVS after a verification build? We would probably have to add this to all Makefile.am in the app subdirs then?! Indeed, however not having to clutter the srcdir with generated files and other cruft is a big must-have in my book especially while developing, so I'm sort of confused that this hasn't shown up earlier... There are .cvsignore files that cover these files. Building in the srcdir is common practice and I don't see anything wrong with it. Usually the srcdir != builddir only shows up when people are building packages. Besides, there're some checks missing in configure for applications which are really needed to build from CVS, like intltool and xsltproc. There are checks for these tools in autogen.sh and you are supposed to run this (and you are supposed to read HACKING even if you think you don't need autogen.sh). Especially for the latter it's really annoying that I can get through configure just fine but in menus/ the Makefile will bail out because xsltproc is desperately needed, so I need to install it and rerun configure to get rid of the problem; not the finest English... The tarball can be built w/o these tools and we don't want it to depend on them. So it would be wrong to move these checks into configure. Our english is actually rather carefully chosen... Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP fails to compile without C++ compiler?
Hi, Daniel Egger [EMAIL PROTECTED] writes: just curious, is it expected that configuration of a GIMP build will fail if configure cannot find a C++ compiler? That question would better be asked on the autoconf list. While you are on it, ask them why there are checks for a fortran compiler. I don't think we ask for any of those. Sven ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On 27.02.2005, at 01:14, Sven Neumann wrote: We would probably have to add this to all Makefile.am in the app subdirs then?! Only to those containing sources which refer to automatically generated headers, about 3 or 4. There are .cvsignore files that cover these files. Building in the srcdir is common practice and I don't see anything wrong with it. Well, noone stops you from doing this but that's not clean or even superior. Usually the srcdir != builddir only shows up when people are building packages. Err, no. For one I really don't like having to backup wasted sources and bandwidth is not plenty here to refetch from scratch or some random point in the past. Second, many people (including me) like to build for several architectures from one sourcebase. In case of GIMP it's only four for me (i386, x86_64, ppc linux, ppc OS X) but there are others where I do some more (ARM linux, mipsel linux, ppc linux uclibc, mipsel linux uclibc, ARM linux uclibc) and in case of compilers even crosscompilers and stuff. It's really hard to imagine having to clone something like the gcc sources several times to build in the source directory, leave alone keeping all of them up-to-date Building packages is one possible use for this, but since typically at least the sources and the closer environment are rebuilt per try it doesn't matter whether one builts in the source or not; what matters more there is DESTDIR capability There are checks for these tools in autogen.sh and you are supposed to run this (and you are supposed to read HACKING even if you think you don't need autogen.sh). Of course I ran autogen.sh, however I did *not* run it per target as this makes the whole point of seperating srcdir and objdir moot... Especially for the latter it's really annoying that I can get through configure just fine but in menus/ the Makefile will bail out because xsltproc is desperately needed, so I need to install it and rerun configure to get rid of the problem; not the finest English... The tarball can be built w/o these tools and we don't want it to depend on them. So it would be wrong to move these checks into configure. Our english is actually rather carefully chosen... So what do I have to do to make the sources self-contained? Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP fails to compile without C++ compiler?
On 27.02.2005, at 01:19, Sven Neumann wrote: just curious, is it expected that configuration of a GIMP build will fail if configure cannot find a C++ compiler? That question would better be asked on the autoconf list. While you are on it, ask them why there are checks for a fortran compiler. I don't think we ask for any of those. It's a difference whether useless checks take place and are ignored or the compiler bails out on something that isn't needed at all. FWIW I haven't seen any other project using autoconf as well fail on this machine because there wasn't a C++ compiler installed so I assume that the GIMP (or maybe the GNOME stuff?) is doing something different or even wrong. Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] GIMP fails to compile without C++ compiler?
On Sun, Feb 27, 2005 at 01:56:16AM +0100, Daniel Egger wrote: On 27.02.2005, at 01:19, Sven Neumann wrote: just curious, is it expected that configuration of a GIMP build will fail if configure cannot find a C++ compiler? That question would better be asked on the autoconf list. While you are on it, ask them why there are checks for a fortran compiler. I don't think we ask for any of those. It's a difference whether useless checks take place and are ignored or the compiler bails out on something that isn't needed at all. FWIW I haven't seen any other project using autoconf as well fail on this machine because there wasn't a C++ compiler installed so I assume that the GIMP (or maybe the GNOME stuff?) is doing something different or even wrong. You're making a bad assumption then. Any app which uses libtool 1.5 has this issue, as a trivial web search will reveal. There's really nothing we can do, short of updating to a post 1.5 libtool when the libtool maintainers actually release one. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On Sun, Feb 27, 2005 at 12:44:47AM +0100, Daniel Egger wrote: On 26.02.2005, at 23:44, Sven Neumann wrote: What's wrong with $(top_builddir)? Ho hum. That's a relative path as well, so instead of -I.. that would be -I$(top_builddir)/app which gets expanded to -I../../app . We could do that but I don't really see the big advantage instead of just using my originally proposed patch. We should do -I$(top_builddir)/app. This avoids needing to care about how deep the directory is, in case the directory is moved elsewhere. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On Sun, Feb 27, 2005 at 01:53:37AM +0100, Daniel Egger wrote: On 27.02.2005, at 01:14, Sven Neumann wrote: We would probably have to add this to all Makefile.am in the app subdirs then?! Only to those containing sources which refer to automatically generated headers, about 3 or 4. No, we should add it to all of them. In fact, it already *is* in some of them. The tarball can be built w/o these tools and we don't want it to depend on them. So it would be wrong to move these checks into configure. Our english is actually rather carefully chosen... So what do I have to do to make the sources self-contained? ./autogen.sh on one system, make dist it, and unpack and build from your disted tarball for the rest of your builds. Or just do your due diligence and be consistent about all your dependencies on the targets you build on. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On 27.02.2005, at 02:50, Manish Singh wrote: We should do -I$(top_builddir)/app. This avoids needing to care about how deep the directory is, in case the directory is moved elsewhere. But that's still not the cure for all possible problems that may arise by moving the header (e.g. from app to libfoo). Anyway, that's better than nothing... Servus, Daniel PGP.sig Description: This is a digitally signed message part
Re: [Gimp-developer] Makefile fix for srcdir != objdir
On Sun, Feb 27, 2005 at 03:07:01AM +0100, Daniel Egger wrote: On 27.02.2005, at 02:50, Manish Singh wrote: We should do -I$(top_builddir)/app. This avoids needing to care about how deep the directory is, in case the directory is moved elsewhere. But that's still not the cure for all possible problems that may arise by moving the header (e.g. from app to libfoo). Anyway, that's better than nothing... There's no getting around updating the Makefile.am for that. With your naive solution, it *adds* a reason. -Yosh ___ Gimp-developer mailing list Gimp-developer@lists.xcf.berkeley.edu http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
