On Sep 8, 12:49 am, Benjamin Schnieders
<[email protected]> wrote:
> Inspecting the enblend run with top I see that indeed enblend sometimes
> uses more than 100% cpu - but never more than like 200%, usually it is
> around 100% and from time to time there is a peak using somewhat more.
First of all CPU load is a silly
measure. You don't look at your car's
(clunker's?) gas consumption and say: "5 MPG,
that must have been an awfully fast ride!" For
a user only wall-clock time matters.
Second, read about Amdahl's law
http://en.wikipedia.org/wiki/Amdahl's_law
It matters.
> As I have a quadcore and I see it is perfectly used up by nona I'm a
> little disappointed about enblend - was this a malconfiguration?
The current implementation does _not_ scale
well beyond two processors. The reasons for
this are yet unknown. You are welcome to run
Enblend with your favorite profiler, identify
the bottleneck(s), and send me a bunch of
patches that rectify the congestion.
> enblend verbose version info tells me:
> enblend 4.0-b93c2aed500d
>
> Extra feature: dmalloc support: no
> Extra feature: image cache: no
> Extra feature: GPU acceleration: yes
> Extra feature: OpenMP: yes - version 2005-5
> - support for nested parallelism
> - support for dynamic adjustment of the number of
> threads
> - using 4 processors and up to 3 threads
>
> Is this the up-to date version or did I compile something wrong?
Your revision is reasonably recent.
Thanks for including the full version
information!
IMO, you did nothing wrong. My results are
similar. Let's see what I've got. The Enblend
that came with my Debian distribution is
$ enblend --version
enblend 3.2-cvs
Extra feature: image cache
Extra feature: GPU acceleration
Using it to build a medium-sized pano (62MPixel,
see details if tiffinfo(1) output below) gives
$ /usr/bin/time enblend -o a.tif image-000[0-9].tif
...
700.13user 1.22system 11:41.69elapsed 99%CPU (0avgtext+0avgdata
0maxresident)k
2696inputs+509496outputs (14major+293908minor)pagefaults 0swaps
$ tiffinfo a.tif
TIFF Directory at offset 0xf8c4ab8 (260852408)
Subfile Type: (0 = 0x0)
Image Width: 14940 Image Length: 4365
Resolution: 150, 150 pixels/inch
Position: 0, 8.3
Bits/Sample: 8
Sample Format: unsigned integer
Compression Scheme: None
Photometric Interpretation: RGB color
Extra Samples: 1<unassoc-alpha>
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 4
Rows/Strip: 17
Planar Configuration: single image plane
My 4.0pre version identifies itself as
$ ~/projects/enblend/BUILD/src/enblend -v -V
enblend 4.0-227a6153f072
Extra feature: dmalloc support: no
Extra feature: image cache: no
Extra feature: GPU acceleration: yes
Extra feature: OpenMP: yes - version 2005-5
- support for nested parallelism
- support for dynamic adjustment of the
number of threads
- using 4 processors and up to 4 threads
and (for the same panorama as above) shows the
following performance for different numbers of
threads
$ for n in 1 2 3 4; do \
echo "#th = $n"; \
OMP_NUM_THREADS=$n /usr/bin/time ~/projects/enblend/BUILD/src/
enblend image-000[0-9].tif; \
done
#th = 1
27.53user 2.76system 0:30.32elapsed 99%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+509496outputs (0major+1316119minor)pagefaults 0swaps
#th = 2
31.02user 3.14system 0:27.37elapsed 124%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+509496outputs (0major+1317014minor)pagefaults 0swaps
#th = 3
32.79user 3.23system 0:25.81elapsed 139%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+509496outputs (0major+1308513minor)pagefaults 0swaps
#th = 4
37.42user 3.74system 0:25.73elapsed 159%CPU (0avgtext+0avgdata
0maxresident)k
0inputs+509496outputs (0major+1338474minor)pagefaults 0swaps
Oh! It is faster than 3.2, isn't it?
For 2 threads, we gain some 10% in performance
for 24% more CPU load; for 3 threads we gain
15% for 40% more CPU load. 4 threads obviously
suffer from stalls, contention, etc.
HTH,
Chris
--~--~---------~--~----~------------~-------~--~----~
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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
