Re: standard variants for py26-numpy
On Mon, Feb 14, 2011 at 21:49, Dan Ports dpo...@macports.org wrote: Given that py26-gtk and py26-cairo depend on numpy, keeping build time down is quite a legitimate concern, so I too wonder whether -atlas ought to be the default. Atlas also seems to be the source of a lot of recent build issues with numpy. I've also found it to be temperamental when building on my new i5 MBP; in fact I've recently started build numpy with -atlas and scipy with +no_atlas (maybe they should be made consistent, but that's a topic for another thread). Cheers Adam ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
On Mon, Feb 14, 2011 at 11:51 PM, vincent habchi vi...@macports.org wrote: IMHO, the problem is not in numpy depending on Atlas, which is correct ; it is in other packages depending on numpy for tasks that may involve very little of it (e.g. using numpy as a convenient means to get array functions). Gimp relies ultimately on numpy for matrix convolutions in image processing, which can take quite a lot of time when the size of the image is large. Yeah, perhaps it is not so unreasonable for GIMP to pull in atlas (sorry if this is a bit tangential from the main point of this thread). Probably in an ideal world though you wouldn't need to build atlas/gcc etc. just to do some simple image cropping resizing etc though. But now that I've thought about it some more I'd probably choose to build atlas in order to get good image processing performance in GIMP. However, as you say, it would be nice to know what this is really achieving in terms of optimization. Perhaps it's huge, or perhaps it makes very little difference... I have no intuitive guess... Scott ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
On Mon, Feb 14, 2011 at 08:50:13PM +0100, Olaf Foellinger said: Hi, for quite some time I'm using macports now, main target is gnucash. Thanks for all the work and the support. Today I've noticed during an upgrade that macports tries to install atlas. That's because it's a standard dependency of py26-numpy. py26-numpy also adds gcc44 this way which is quite a lot for gnucash users. I would recommend to omit atlas from the default dependencies of p25-numpy. What do you think? Should I enter a ticket for this? Use -atlas to disable that variant, which also has the effect of disabling the need for a new gcc as well: $ sudo port install py26-numpy -atlas If you're using the new sqlite format for the registry, this will be properly recorded but you won't see in in just a 'port installed'; you need to use verbose to see it: $ port -v installed py26-numpy The following ports are currently installed: py26-numpy @1.5.1_1-atlas (active) platform='darwin 10' archs='x86_64' Bryan Gruß Olaf ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
On Mon, Feb 14, 2011 at 01:42:50PM -0700, Bryan Blackburn wrote: Use -atlas to disable that variant, which also has the effect of disabling the need for a new gcc as well: Until now, I'd managed to be completely oblivious to the fact that atlas support was a variant in numpy. What are the drawbacks of building numpy without atlas? The advantages of not having to build atlas and gcc are obvious and considerable, at least to me. Given that py26-gtk and py26-cairo depend on numpy, keeping build time down is quite a legitimate concern, so I too wonder whether -atlas ought to be the default. Dan -- Dan R. K. Ports MIT CSAILhttp://drkp.net/ ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
Hi, * Bryan Blackburn b...@macports.org [14.02.11 21:42]wrote: Use -atlas to disable that variant, which also has the effect of disabling the need for a new gcc as well: $ sudo port install py26-numpy -atlas that's clear. I've never installed it manually but using $ port install gnucash I haven't noticed that py26-numpy has installed atlas and gcc44 but recently I've tried to upgrade gnucash. Then I've noticed that atlas takes hours and hours to install. I think for the average gnucash user (and maybe for other ports that depends on py26-numpy) atlas is a heavy and not necessary dependency. atlas should be installed by users who explicitly select it. Gruß Olaf ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
Does this mean I don't really need atlas to use gimp either? On Mon, Feb 14, 2011 at 1:49 PM, Olaf Foellinger o...@foellinger.de wrote: Hi, * Bryan Blackburn b...@macports.org [14.02.11 21:42]wrote: Use -atlas to disable that variant, which also has the effect of disabling the need for a new gcc as well: $ sudo port install py26-numpy -atlas that's clear. I've never installed it manually but using $ port install gnucash I haven't noticed that py26-numpy has installed atlas and gcc44 but recently I've tried to upgrade gnucash. Then I've noticed that atlas takes hours and hours to install. I think for the average gnucash user (and maybe for other ports that depends on py26-numpy) atlas is a heavy and not necessary dependency. atlas should be installed by users who explicitly select it. Gruß Olaf ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
* Scott Webster sewebs...@gmail.com [14.02.11 22:54]wrote: Does this mean I don't really need atlas to use gimp either? I assume yes, so it is. Gruß Olaf ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
On 2011-02-14 20:50 , Olaf Foellinger wrote: Today I've noticed during an upgrade that macports tries to install atlas. That's because it's a standard dependency of py26-numpy. py26-numpy also adds gcc44 this way which is quite a lot for gnucash users. I would recommend to omit atlas from the default dependencies of p25-numpy. What do you think? Should I enter a ticket for this? I brought up the same question some time before [1]. I am adding Marcus and James as maintainers of py26-numpy and atlas to CC in this thread. Would be good to hear their opinion on this topic. Rainer [1] http://lists.macosforge.org/pipermail/macports-dev/2010-April/011682.html ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
Re: standard variants for py26-numpy
Le 14 févr. 2011 à 20:50, Olaf Foellinger a écrit : Today I've noticed during an upgrade that macports tries to install atlas. That's because it's a standard dependency of py26-numpy. py26-numpy also adds gcc44 this way which is quite a lot for gnucash users. I would recommend to omit atlas from the default dependencies of p25-numpy. What do you think? Should I enter a ticket for this? Numpy, gewissermaßen :), is a computing package: scipy uses numpy. As such, it strives to work as fast as possible (nobody wants to wait ten hours the result of a matrix inversion knowing that it can be done in ten seconds when the algorithm is optimized). ATLAS takes hours to compile on 32-bit machines because it *really tries hard* to find the most efficient algorithm for each BLAS routine. Besides, ATLAS can use the latest GCC version, whereas the Accelerate framework embedded in MacOS is probably compiled with the same compiler as the one furnished with Xcode. It would be worth benchmarking code linked with an up to date ATLAS and the Apple Accelerate framework, and see which wins. IMHO, the problem is not in numpy depending on Atlas, which is correct ; it is in other packages depending on numpy for tasks that may involve very little of it (e.g. using numpy as a convenient means to get array functions). Gimp relies ultimately on numpy for matrix convolutions in image processing, which can take quite a lot of time when the size of the image is large. FWIW Viele Grüße auch aus Paris unter Wolken, Vincent ___ macports-users mailing list macports-users@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
