Re: [Boost-users] [GIL] Performance warning...
Lubomir, looking at the default_channel_converter the channels already arrive as a const reference. All I did was to make sure they are still const references in the channel_converter functions. In all cases the source channels should at least be const. Which allows for more compiler optimizations. I did run the performance test in gil_test suite and the changes were marginal. Some tests were faster some were slower after the change. Christian On Fri, Nov 27, 2009 at 6:13 PM, Lubomir Bourdev <lbourdev@adobe.com> wrote:
This was done on purpose. I don't know if it still holds, but it used to be that a const reference to a simple type like an int or char is slower than passing the type by value. This is the same reason most STL algorithms take iterators by value. If you want to make this change it is important to verify that performance of simple built-in channel types is not adversely affected.
Lubomir
On 11/27/09 12:17 PM, "Christian Henning" <chhenning@gmail.com> wrote:
Hi Eloi, you're correct and I'll fix that. I can even make it const reference. Running the test shows no real difference but that might be only because no expensive channels are being used.
I'll commit the changes asap.
Lubomir, please review the changes if your time allows. Affected files are channel_algorithm.hpp and gil_concept.hpp.
Thanks, Christian
I am not an expert but I think on primitive types, there is no need to put a reference (and it may slows down the process). But the line I mentioned before concern a channel object, and I think this object stores many datas (maybe a byte array ?). 2009/11/28 Christian Henning <chhenning@gmail.com>
Lubomir, looking at the default_channel_converter the channels already arrive as a const reference. All I did was to make sure they are still const references in the channel_converter functions. In all cases the source channels should at least be const. Which allows for more compiler optimizations.
I did run the performance test in gil_test suite and the changes were marginal. Some tests were faster some were slower after the change.
Christian
This was done on purpose. I don't know if it still holds, but it used to be that a const reference to a simple type like an int or char is slower
On Fri, Nov 27, 2009 at 6:13 PM, Lubomir Bourdev <lbourdev@adobe.com> wrote: than
passing the type by value. This is the same reason most STL algorithms take iterators by value. If you want to make this change it is important to verify that performance of simple built-in channel types is not adversely affected.
Lubomir
On 11/27/09 12:17 PM, "Christian Henning" <chhenning@gmail.com> wrote:
Hi Eloi, you're correct and I'll fix that. I can even make it const reference. Running the test shows no real difference but that might be only because no expensive channels are being used.
I'll commit the changes asap.
Lubomir, please review the changes if your time allows. Affected files are channel_algorithm.hpp and gil_concept.hpp.
Thanks, Christian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
While some channel types are classes, a built-in type such as ‘unsigned char’ is a valid channel. We have to be careful so we don’t slow down operations on common 8-bit images. I think it is safe to replace “Channel” with “const Channel” but “const Channel&” has a size of a pointer and this is far bigger than unsigned char. Perhaps to do this right one needs to create a metafunction that returns the type by value or by const reference, whichever is faster. Lubomir From: Eloi Du Bois [mailto:eloi.du.bois@gmail.com] Sent: Friday, November 27, 2009 3:37 PM To: boost-users@lists.boost.org Cc: Lubomir Bourdev Subject: Re: [Boost-users] [GIL] Performance warning... I am not an expert but I think on primitive types, there is no need to put a reference (and it may slows down the process). But the line I mentioned before concern a channel object, and I think this object stores many datas (maybe a byte array ?). 2009/11/28 Christian Henning <chhenning@gmail.com<mailto:chhenning@gmail.com>> Lubomir, looking at the default_channel_converter the channels already arrive as a const reference. All I did was to make sure they are still const references in the channel_converter functions. In all cases the source channels should at least be const. Which allows for more compiler optimizations. I did run the performance test in gil_test suite and the changes were marginal. Some tests were faster some were slower after the change. Christian On Fri, Nov 27, 2009 at 6:13 PM, Lubomir Bourdev <lbourdev@adobe.com<mailto:lbourdev@adobe.com>> wrote:
This was done on purpose. I don't know if it still holds, but it used to be that a const reference to a simple type like an int or char is slower than passing the type by value. This is the same reason most STL algorithms take iterators by value. If you want to make this change it is important to verify that performance of simple built-in channel types is not adversely affected.
Lubomir
On 11/27/09 12:17 PM, "Christian Henning" <chhenning@gmail.com<mailto:chhenning@gmail.com>> wrote:
Hi Eloi, you're correct and I'll fix that. I can even make it const reference. Running the test shows no real difference but that might be only because no expensive channels are being used.
I'll commit the changes asap.
Lubomir, please review the changes if your time allows. Affected files are channel_algorithm.hpp and gil_concept.hpp.
Thanks, Christian
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org<mailto:Boost-users@lists.boost.org> http://lists.boost.org/mailman/listinfo.cgi/boost-users
Lubomir Bourdev escribió:
While some channel types are classes, a built-in type such as ‘unsigned char’ is a valid channel. We have to be careful so we don’t slow down operations on common 8-bit images. I think it is safe to replace “Channel” with “const Channel” but “const Channel&” has a size of a pointer and this is far bigger than unsigned char.
Perhaps to do this right one needs to create a metafunction that returns the type by value or by const reference, whichever is faster.
Lubomir
call_traits< T >::param_type does that. "Defines a type that represents the "best" way to pass a parameter of type T to a function." http://www.boost.org/doc/libs/1_41_0/libs/utility/call_traits.htm Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com
Hi guys, I'll look into the call_traits metafunction tomorrow. I can also write a simple test that would measure potential overhead. Thanks for the input! Christian 2009/11/27 Agustín K-ballo Bergé <kaballo86@hotmail.com>:
Lubomir Bourdev escribió:
While some channel types are classes, a built-in type such as ‘unsigned char’ is a valid channel. We have to be careful so we don’t slow down operations on common 8-bit images. I think it is safe to replace “Channel” with “const Channel” but “const Channel&” has a size of a pointer and this is far bigger than unsigned char.
Perhaps to do this right one needs to create a metafunction that returns the type by value or by const reference, whichever is faster.
Lubomir
call_traits< T >::param_type does that.
"Defines a type that represents the "best" way to pass a parameter of type T to a function." http://www.boost.org/doc/libs/1_41_0/libs/utility/call_traits.htm
Agustín K-ballo Bergé.- http://talesofcpp.blogspot.com _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
I have done some testing and on my machine ( MSVC10 in x64 ). The new code ( using const & ) is slightly faster than the old code ( using value type ). Not by much, but at least it's not slower. See below for my test. I also think that since the default_channel_converter is using const& the following channel_converter functions should do the same. Does that makes sense in your eyes? #include <iostream> #include <boost\timer.hpp> #include <boost\gil\gil_all.hpp> using namespace std; using namespace boost; using namespace gil; int _tmain(int argc, _TCHAR* argv[]) { rgba8_image_t src( 10000, 10000 ); fill_pixels( view( src ), rgba8_pixel_t( 12,12,12,12 )); rgba32_image_t dst( 10000, 10000 ); timer t; for( size_t i = 0; i < 10; i++ ) copy_and_convert_pixels( view( src ), view( dst ) ); cout << t.elapsed() << " sec" << endl; return 0; } Regards, Christian
participants (4)
-
Agustín K-ballo Bergé -
Christian Henning -
Eloi Du Bois -
Lubomir Bourdev