2010/12/18 Lukáš Jirkovský <l.jirkov...@gmail.com>: > On 18 December 2010 16:22, Jan Martin <janmar...@diy-streetview.org> wrote: >> Bruno, >> >> care to estimate what kind of speed improvement optimizing the code would be >> good for? >> What would it need to get it done? >> Who is qualified to do it? >> >> Jan >> >> >> > > I think it would be quite difficult. I remeber I looked at the nona > code quite some time ago (bit it didn't really change since that > time). Most of the code is generated at compile time from templates so > sometimes it's a bit difficult to really understand what it does and > especially how to optimize it. But I guess that a big slowdown is > caused by vigra. Yeah, it allows to write completelly generic code > like the nona code is but for a price. > > I know it from my experiments with hugin deghosting. Vigra's types are > due to extensive polymorphism usage slow, even the simple ones like > RGBsomethingsomething (I had too much vine to remeber that) or vector > types like tinyvector. Also the reason of the slowdown is operator > overloading. > > As I said, it allows you to write generic code but at a price. For > example you can do things like a + b and it translates to a + b for > one component data (eg. grayscale image) or (a[0] + b[0], a[1] + b[1], > a[2] + b[2]) for RGB or Lab or whatever type which is a 3-component > vector. The problem is code generated by the compiler when you add > more together. For example a * b + c is, for three component data, > implemented as somethinglike > > for (i=0; i <3; i++) > tmpres[i] = a[i] + b[i] > for (i = 0; i < 3; i++) > res[i] = tmpres[i] + c[i] > > You can see that there these loops can be shrinked to one, but > compiler won't do this. But there are some possibilities how to make > compiler to make it in one loop but it's a black magic. If you > implement all this manually (ie. you implement different code for > vector types and scalar types) you can gain quite some speed but I > wouldn't like to mutilate nona - this code is just too sexy. > > ciao, > Lukas >
After looking at the vigra code I found out I was probably completely wrong. It is possible to evaluate operator chain in one loop by creating a parser tree. I thought it's not used in vigra, but I just found UnrollLoop in tinyvector.hxx to do something which at a first glance look like a tree creation. Lukas -- 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
