[function] improvements/proposals
A while back, in various threads more or less related to the topic, I posted various ideas and/or code contributions to the effect of improving boost::function in terms of efficiency (concentrated on invocation speed, assignement performance/overhead and reducing template and RTTI bloat) and configurability, however there was no "official response" as to whether it was any good, or whether any of it would be accepted or what's wrong with it if not. IMHO the results { - 'Speed': the test presented here http://marc.info/?l=boost&m=118835709647084&w=2 modified to work with boost::signals2 (because it is a header only library/does not require a recompilation of boost if something in boost::function changes) with the dummy mutex/no threading support and a simple recompilation with the new boost::function<> code yielded a ~10% boost, changing the default policy to be nothrow the boost doubled to ~20% - 'Size': my real life project, that uses heavy metaprograming for generating function objects (that as a consequence have _very_ long type names, and thus RTTI records) to assign to boost::functions shrunk by ~10% simply by using the modified boost::function (with RTTI features disabled)...This post http://lists.boost.org/Archives/boost/2009/12/160202.php has more detailed and updated results when my project grew further (with an even bigger difference) } show/hint that there is room for improvement in boost::function and therefor warrant atleast some kind of response (even if along the lines of 'it's no good' or 'there is no time for this now')...which is the reason for (re)posting this (in a separate thread). The relevant threads with more detail are these: http://thread.gmane.org/gmane.comp.lib.boost.devel/196906 http://thread.gmane.org/gmane.comp.lib.boost.devel/194514/focus=195351 since then I've moved the modified code from the vault into the sandbox SVN (under the obvious name "function" :) -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley
Domagoj Saric wrote:
A while back, in various threads more or less related to the topic, I posted various ideas and/or code contributions to the effect of improving boost::function in terms of efficiency (concentrated on invocation speed, assignement performance/overhead and reducing template and RTTI bloat) and configurability, however there was no "official response" as to whether it was any good, or whether any of it would be accepted or what's wrong with it if not.
You should contact the maintainer of the library, Douglas Gregor, which I assume is the one taking those decisions.
"Mathias Gaunard" <mathias.gaunard@ens-lyon.org> wrote in message news:hj1kl5$glt$1@ger.gmane.org...
You should contact the maintainer of the library, Douglas Gregor, which I assume is the one taking those decisions.
Very well...thanks... -- "That men do not learn very much from the lessons of history is the most important of all the lessons of history." Aldous Huxley
Domagoj Saric wrote:
"Mathias Gaunard" <mathias.gaunard@ens-lyon.org> wrote in message news:hj1kl5$glt$1@ger.gmane.org...
You should contact the maintainer of the library, Douglas Gregor, which I assume is the one taking those decisions.
Very well...thanks...
Given a number of articles on the web titled "Fast Delegates for C++" or similar, and how they're supposed to be better and faster than Boost.Function, I am curious if you were able to make progress on this matter? Thanks, Cheers, Rutger
On Fri, Feb 26, 2010 at 6:34 AM, Rutger ter Borg <rutger@terborg.net> wrote:
Domagoj Saric wrote:
"Mathias Gaunard" <mathias.gaunard@ens-lyon.org> wrote in message news:hj1kl5$glt$1@ger.gmane.org...
You should contact the maintainer of the library, Douglas Gregor, which I assume is the one taking those decisions.
Very well...thanks...
Given a number of articles on the web titled "Fast Delegates for C++" or similar, and how they're supposed to be better and faster than Boost.Function, I am curious if you were able to make progress on this matter?
Actually, the only reason they outperform boost::function is because boost::function adds in extra assembly code for a comparison check (to null, if true it throws an exception). If that is removed (perhaps by a policy, I certainly know that most of my function would never be empty, would even be nice if the function defaulted to an empty function if empty instead), then boost::function becomes even faster. I have actually started to take a liking to Boost.Variant for function callbacks (if I know what they can be), it inlines it and the function pointer call disappears. :)
AMDG OvermindDL1 wrote:
Actually, the only reason they outperform boost::function is because boost::function adds in extra assembly code for a comparison check (to null, if true it throws an exception). If that is removed (perhaps by a policy, I certainly know that most of my function would never be empty, would even be nice if the function defaulted to an empty function if empty instead), then boost::function becomes even faster. I have actually started to take a liking to Boost.Variant for function callbacks (if I know what they can be), it inlines it and the function pointer call disappears. :)
The comparison could be removed even without a policy by using the null object pattern. In Christ, Steven Watanabe
Didn't someone already propsoed variosu pactehs for that ? I remember this discussion + the fact we need to support function on no-RTTI environments. -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
"joel falcou" <joel.falcou@lri.fr> wrote in message news:4B88CC38.3050706@lri.fr...
Didn't someone already propsoed variosu pactehs for that ? I remember this discussion + the fact we need to support function on no-RTTI environments.
This support was added recently by Peter Dimov but it was done in a way to emulate RTTI when it is not provided by the compiler. While this is a welcome option (as just all options are) it is not the 'complete'/proper solution because we are still left with _forced_ usage of RTTI when the majority do not use it (many users of boost.function do not even know it exists). I've been ranting about this frequently: if we only object a certain 'issue'/'option'/'implementation detail' when it produces build errors we are not 'true' to the nature of the language that we are using as the 'language moto' states >>if you do not use it you do not _pay_ for it<< not 'if you use it you will be able to compile it' (as the latter is practically a tautology for any non-broken language)... With that said, the correct solution would be to have the option to disable all the options one does not use and the compiler is not able to remove (e.g. all 'features' that 'go through' function pointers, virtual functions and the likes...)... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
"OvermindDL1" <overminddl1@gmail.com> wrote in message news:3f49a9f41002262044hd62d028x36c870906a19c058@mail.gmail.com...
Actually, the only reason they outperform boost::function is because boost::function adds in extra assembly code for a comparison check (to null, if true it throws an exception).
Actually there are more issues, that one is just one of the more serious ones...(I've gone about all of them in much greater detail previously...but not to repeat myself...)
If that is removed (perhaps by a policy, I certainly know that most of my function would never be empty, would even be nice if the function defaulted to an empty function if empty instead), then boost::function becomes even faster.
As Steven pointed out this can be done w/o policies, with a nul-object (that is the way I did it)...But I added a policy to specify the nul-object, that is to choose what it actually does (throw, nop, ....)...
I have actually started to take a liking to Boost.Variant for function callbacks (if I know what they can be), it inlines it and the function pointer call disappears. :)
lol ... 'dirty'/twisted, me likes ;-) -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
"Rutger ter Borg" <rutger@terborg.net> wrote in message news:hm8ilo$q2u$1@dough.gmane.org...
Given a number of articles on the web titled "Fast Delegates for C++" or similar, and how they're supposed to be better and faster than Boost.Function, I am curious if you were able to make progress on this matter?
Yes ;) ...as briefly outlined in the first post of this thread ( http://old.nabble.com/-function--improvements-proposals-p27207383.html ) ... there you can also find links to previous threads that discussed the issues in (much) greater detail... I have also found various 'fast delegates'-type of articles (if memory serves me right I've posted a link to one in one of my first posts on this subject) but did not yet seriously go through them as the changes I made were already so numerous that it seemed it would be better if we first discuss the changes so far before proceeding further... ...unfortunately I am still waiting for a response from Dogulas Gregor (he said he is currently swamped with his 'real job')... -- "What Huxley teaches is that in the age of advanced technology, spiritual devastation is more likely to come from an enemy with a smiling face than from one whose countenance exudes suspicion and hate." Neil Postman
participants (6)
-
Domagoj Saric -
joel falcou -
Mathias Gaunard -
OvermindDL1 -
Rutger ter Borg -
Steven Watanabe