Hi Battle and others, I mailed Battle in an off-list mail, and now repeated in < http://old.nabble.com/enblend-out-of-memory-error-td28250757.html>, that Ingemar Bergmark also made openmp enabled enblend/enfuse builds. He did this for (Snow)Leopard ppc/i386/x86_64. So no ppc64 (G5) builds.
Harry 2010/4/20 Harry van der Wolf <hvdw...@gmail.com> > Hi Battle and others, > > Threading is a long standing wish for Hugin on several areas and might > become one of the GSOC 2010 projects, that's all I can say about it. > > Yesterday evening I built the following stand-alone enblend/enfuse > versions: > - (Snow)Leopard Universal 32bit OpenMP enabled. > - (Snow)Leopard Universal 64bit OpenMP enabled. > - (Snow)Leopard Universal 64bit. > > I already had the 32bit dynamically compiled (Snow)Leopard OpenMP enabled > in the bundle and I already had the 32bit Tiger standalone build without > openmp, as Tiger doesn't support OpenMP. It doesn't make sense to make a > (Snow)Leopard non-openmp enabled version as that would be the same as the > Tiger version. > > I'm now thinking of 2 options: > - All these enblend/enfuse versions will be delivered with the future hugin > builds so that everyone can pick his/her favourite version or "hardware > bound" version. (another 25MB boost of the bundle dmg image). > - Deliver the hugin bundle with 32bit openmp enabled and tiger > enblend/enfuse versions, like 5102. And a separate enblend/enfuse package > like I did in the past. > > This week I will (try to) build a 64bit Hugin version. We could at least > see what it does in (Snow)Leopard. > I say try, as it is at least 1½ years ago that I built the last 64bit > version. > Note also that some part of it will remain 32bit as wxmac (for the gui) has > problems on 64bit, at least it had "some time ago" (something else that > needs analysis). I do not know yet whether the optimize step will be 32bit > or 64bit. I think that's one of the steps compiled into the "big"hugin > itself and would therfor be 32bit as well. Nona will be 64bit as it is a > stand-alone part of Hugin. > > > Harry > > > > 2010/4/19 Battle <battlebr...@gmail.com> > > HI Harry, >> Likewise, let me say thanks for making the OSX builds. >> >> Here is my experience on an early 2009 Mac Pro Quad xeon (Nehalem) >> 2.93 MHz intel 24GB RAM 10.6 Snow Leopard. This machine will hyper >> thread so it acts like 8 cores. I realize this puts me on the high end >> of the hugin user base in terms of hardware. None the less... >> >> I downloaded enblend-openmp and enfuse-openmp from Source Forge in 64 >> bit versions (part of enblend 4.0 download), moved the folder to my >> applications folder, and set preferences in Hugin to run the openmp >> versions as alternate enblend and enfuse versions. I'm using your 32 >> bit build svn 5102 to do this. This works great for enblend. I >> haven't tried enfuse. In fact I just built a pano resulting in a >> 3.2GB uncompressed tiff that enblend used up about 12GB real and 12GB >> virtual memory use out of the 24GB real memory on the machine >> according to Activity Monitor. So this enblend 64 bit build clearly >> resolves the enblend out of memory error that I wrote about in another >> post. Also nona takes good advantage of the multiple cores/threads >> on this machine. Nona processed just under 100 12MP jpg images to >> tiff in about 7 minutes or so. That's just under 4.5 seconds an image >> on average reading from one drive and writing to another. Not bad. >> Enblend-openmp 64 bit ran and hugin wrote the final output in about 9 >> minutes, for a total of under 17 minutes overall. Again not bad. >> >> So where are my bottle necks? The optimization process in hugin >> proper in the 32 bit build seems slow. On smaller projects of 10 to >> 20 images the optimization tab can take almost as long as actually >> stitching the project. I don't know whether a 64 bit version of the >> Hugin UI would address this or if this is an issue with another sub >> program. Since I don't know where the optimization is taking place or >> if it is multithreaded or otherwise optimized for multiple core >> machines I think its not possible for me to answer whether a 64 bit >> build of Hugin is useful. I can't find anything in activity monitor >> but a couple of threads in Hugin and an increase in the CPU time. So >> it looks like the optimization is single threaded and only uses one >> cpu. But this is the place where I'd get the most improvement at the >> moment, and it seems to me where increasing capability of the the >> hardware is taking us. Maybe someone else in the community can >> respond to how the optimization works, what the possibilities are, and >> whether 64 bit processing would actually help. >> >> I note that from your site http://panorama.dyndns.org/macoverview.php >> that over 80% of your downloads are intel core 2 or better which will >> run Leopard. My oldest machine at this point is a intel core 2 duo >> running Tiger. I'm a bit too lazy to update it Leopard just because >> its a home machine that is only used for email, internet, and >> generating light correspondence mostly by other family members. But >> if I needed to run hugin on it and could get the the productivity >> gains of 64 bit enblend I wouldn't hesitate for a moment to go to >> Leopard. >> >> Thanks again for your OSX builds. >> Battle >> >> >> On Apr 17, 5:53 am, Harry van der Wolf <hvdw...@gmail.com> wrote: >> > Hi mac users, >> > >> > (A long mail). >> > >> > I have not made up my mind what to do next with future builds, maybe you >> > have ideas for me. Please do not consider this as a wish list for your >> > special requirements. I'm trying to make up my mind and I hope you can >> help >> > me with that. >> > >> > Some remarks to what bothers me: >> > - Currently I don't want to build an integrated 4 architecture >> 32bit/64bit >> > (ppc/i386/ppc64/x86_64) Hugin bundle as it will pump up the bundle to >> 200+ >> > MB as it will mean that every library/binary has 4 architectures inside. >> > Besides it's a lot of extra work and especially the 64bit libraries >> sometime >> > require extra tweaking. Next to that the enblend/enfuse w.r.t. "openmp" >> will >> > remain a pain in these builds (next remark). Also startup times will >> > increase. >> > - I don't want to maintain a 32bit bundle for Tiger on ppc/intel >> mono-core, >> > a 32bit enblend/enfuse openmp enabled build for G4/intel monocore on >> Leopard >> > and a 64bit enblend/enfuse openmp enabled bundle for (Snow)Leopard on >> > G5/Intel duo/quad/8-core. Note that hugin is dynamically linked which >> means >> > that all binaries/libraries use the same libraries, which means that >> these >> > libraries need to be all in the same architectures with the same build >> > options, which means that I would need 3 huge separated build >> environments: >> > No way. >> > - Building 64bit for G5 (ppc64) is becoming harder compared to building >> 64 >> > bit on intel (x86_64), as G5 will slowly disappear and newer libs with >> newer >> > options no longer support it. >> > - Building a 64bit bundle brings hardly any benefits on (Snow)Leopard, >> no >> > matter what Apple "markets" about 64bit SnowLeopard(*), (1,2,3,4,5). >> > - Only enblend, enfuse and to some extent nona will profit from a 64bit >> > build w.r.t. speed and memory address space (despite my previous >> remark). >> > - I'm thinking as well of building a triple architecture build, e.g. >> > ppc/i386/x86_64, so no support for G5 64bit. >> > - I'm thinking of dropping Tiger support for svn builds and only build >> Tiger >> > versions for formal releases(**). >> > - In 5102 I built a 32bit Hugin bundle with a 32bit openmp >> enblend/enfuse >> > version. Next to that I built a 32bit non-openmp version that would >> work on >> > Tiger. I'm now thinking of building a 64bit openmp enabled standalone >> > enblend/enfuse which I will also package with the 32bit bundle. >> > >> > So as you can see, I really have mixed-up feelings about what to do. >> > Ideas are welcome as you might have great ideas to enable as much >> options as >> > possible and still keeping it flexible and compatible and on a >> > "low-profile" maintenance. Please read the links on 32bit/64bit before >> > starting arguments that "64bit is better because...". Please also google >> on >> > "apple 64bit" and alike queries to get more insight in the matter. There >> is >> > not one Apple link mentioned in my references as Apple "hides" the >> > 32bit/64bit thing on their websites. You really have to search carefully >> for >> > it to find it. I have already been reading and searching about this for >> over >> > a year now and the links below are just the quick google queries I did >> for >> > this mail. >> > Note that I'm currently tend to go for my last remark as that's the >> most >> > "compatible" and easy one for me. >> > >> > Please note that I will decide myself, despite the great ideas you might >> > have, as currently I'm the builder and I'm the one who has to do the >> work >> > (and sometimes quite a lot of work. There are still some issues to go on >> G4: >> > another dinosaur which makes me hesitate on supporting it. And I know >> > nothing about G3 (even older) at the moment). >> > All this is also one of the reasons why I started the enquiry on < >> http://panorama.dyndns.org/macoverview.php>. >> > >> > Hoi, >> > Harry >> > >> > (*): Only a 64bit library or binary can address more that 4GB (in >> theory). >> > The Leopard kernel runs in 32bit mode and the Snow Leopard kernel also >> runs >> > by default in 32bit mode but can be switched to 64bit mode. In 32bit >> mode >> > only a 4 GB address space can be used. BUT.. when running in 64bit mode, >> the >> > (Snow) Leopard kernel can use 4GB address space for it's kernel and >> kernel >> > extensions (kexts), and use another 4GB for each running program. To run >> in >> > 64bit mode however, you have to use the "magic 6-4 keys" pressed during >> > every startup to start SnowLeopard in 64bit mode (or use (3)). Only >> 64bit >> > XServe machines run in 64bit mode by default (5). >> > Even running in 64bit mode still means that the program itself (Hugin >> and or >> > enfuse/enblend in this case) can only address 4GB and not more. So if >> you >> > have a 24GB dual-core, quad-core or 8-core and run "some" program, that >> > program still only accesses up to 4GB. Off course you can run 5 programs >> and >> > the OS itself, giving each 4GB to fill the 24GB RAM. Your single 64bit >> > program can still not use the 20 GB RAM as you might expect and had >> hoped >> > for. I don't know if clever developers or dev teams know a way of making >> > parallel builds where every parallel "program/thread" can use 4GB. I >> haven't >> > read of it yet. As far as I know the openmp enabled enblend/enfusemake >> uses >> > parallel threads but in the same address space. If I'm wrong please let >> me >> > know. >> > >> > (**): Currently I'm on Leopard 10.5.8. I'm thinking of upgrading to >> > SnowLeopard 10.6 within a month (or so). I'm not sure if I can still >> build a >> > Tiger compatible build then. I've already read many articles that >> mention >> > that it can be done by some special tricks using (importing/copying) the >> > older 10.4 SDK's into the SnowLeopard XCode, but I don't know whether I >> want >> > to go that way. It depends on the amount of work. >> > >> > 1: >> http://hothardware.com/News/Apples-64Bit-Snow-Leopard-OS-Installs-32B... >> > 2: >> http://www.macobserver.com/tmo/article/checking_32_or_64-bit_kernel_b... >> > 3:http://www.ahatfullofsky.comuv.com/English/Programs/SMS/SMS.html >> > 4:http://news.cnet.com/8301-13579_3-10320314-37.html >> > 5: >> http://www.osnews.com/story/22009/Snow_Leopard_Seeds_Use_32bit_Kernel... >> > >> > -- >> > You received this message because you are subscribed to the Google >> Groups "hugin and other free panoramic software" group. >> > A list of frequently asked questions is available at: >> http://wiki.panotools.org/Hugin_FAQ >> > To post to this group, send email to hugin-ptx@googlegroups.com >> > To unsubscribe from this group, send email to >> hugin-ptx+unsubscr...@googlegroups.com<hugin-ptx%2bunsubscr...@googlegroups.com> >> > For more options, visit this group athttp:// >> groups.google.com/group/hugin-ptx >> >> -- >> You received this message because you are subscribed to the Google Groups >> "hugin and other free panoramic software" group. >> A list of frequently asked questions is available at: >> http://wiki.panotools.org/Hugin_FAQ >> To post to this group, send email to hugin-ptx@googlegroups.com >> To unsubscribe from this group, send email to >> hugin-ptx+unsubscr...@googlegroups.com<hugin-ptx%2bunsubscr...@googlegroups.com> >> For more options, visit this group at >> http://groups.google.com/group/hugin-ptx >> > > -- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ To post to this group, send email to hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx
