I don't personally think that the style of programming that optional is intended for is suitable for high performance/performance critical situations in the first place. Pass by reference and return a bool for a conditional return value. Pass the bool and the object separately for a conditional argument. Pass or return a pointer and check if it is null. Yes, my advice really is to not use optional if you want performance. Even if we did everything you can think of to make optional fast you are still better off designing your interfaces in such a way that you don't need it if your goal is performance. That copy that you are counting branches in is probably unnecessary in the first place. Safety, on the other hand, is also important. All this looking at assembly code generated by optional smacks of premature optimization. If you agree with the idea that optional is valuable because of safety considerations then write your application using optional and not worrying much about performance and get the functionality right then measure your performance and optimize the places where it matters by stripping out usage of optional or whatever else is slowing you down so you get safety most of the time (with most of the benefit) and performance where you actually need it. Life is about tradeoffs. Optional will never be perfect. I find that it is quite easy to write safe C++ interfaces without using optional, so I see no reason why you can't design code that is both safe and fast without it. I know the author of optional and you haven't convinced me that we should bother him. Regards, Luke

Le 26/01/12 00:20, Simonson, Lucanus J a écrit :

I don't personally think that the style of programming that optional is intended for is suitable for high performance/performance critical situations in the first place. Pass by reference and return a bool for a conditional return value. Pass the bool and the object separately for a conditional argument. Pass or return a pointer and check if it is null. Yes, my advice really is to not use optional if you want performance. Even if we did everything you can think of to make optional fast you are still better off designing your interfaces in such a way that you don't need it if your goal is performance. That copy that you are counting branches in is probably unnecessary in the first place. Safety, on the other hand, is also important. All this looking at assembly code generated by optional smacks of premature optimization. If you agree with the idea that optional is valuable because of safety considerations then write your application using optional and not worrying muc h about performance and get the functionality right then measure your performance and optimize the places where it matters by stripping out usage of optional or whatever else is slowing you down so you get safety most of the time (with most of the benefit) and performance where you actually need it. Life is about tradeoffs. Optional will never be perfect.

I find that it is quite easy to write safe C++ interfaces without using optional, so I see no reason why you can't design code that is both safe and fast without it.

I know the author of optional and you haven't convinced me that we should bother him.

Hi, the user can not always redesign an interface using optional<T> as he could be not the owner (use of 3pp libraries). I'm sure the author/maintainer of optional would adopt some patches if it is probed a performance improvement for some specific cases. Best, Vicente

I see no reason why we can't have safe _and_ fast _and_ optional?

I'm actually glad to see you putting effort into making that happen. The effort required is the only reason. Performance wasn't the reason I don't use optional, but for those who do use it I'm sure it will be valuable.

The rationale you gave is just typical premature pessimization apologetics that also somehow assumes that C++ is "safe and slow" and that you have to go "bare metal C" to have performance. Luckily that's just plain incorrect, to put it mildly. Sadly, that rationale nonetheless also too often gives us such bloatware as std::streams, lexical_cast or boost::filesystem...

I said safe and fast C++ without optional, which isn't the same thing as "bare metal C". Bare metal C wouldn't qualify as safe. I'm as annoyed by the "C is faster than C++, ergo I never learned C++" guys as you are. Optional was implemented to be safe and slow because it was targeting safe and slow use cases. For POD types and anything that has a default constructor a std::pair<bool, T> seems fine to me. Regards, Luke

On 27 January 2012 12:57, Simonson, Lucanus J <lucanus.j.simonson@intel.com> wrote:

 Optional was implemented to be safe and slow because it was targeting safe and slow use cases.

You are saying it is *deliberately* slow??

 For POD types and anything that has a default constructor a std::pair<bool, T> seems fine to me.

I don't want to write a different style of code depending on whether or not a type T is default constructible. I can't easily pass things like this to templates because I have to write special cases all over the place. Optional models my intent. I want to take advantage of RVO. Some things that are default constructible are still very expensive to construct (such as std::deque under gcc). When you initialize class members, do you use member intializer lists for default constructible types or do you just throw a bunch of assignments in the body of the constructor? If the former, why do you do it, given that default construction followed by assignment "seems fine" to you? --  Nevin ":-)" Liber  <mailto:nevin@eviloverlord.com>  (847) 691-1404

From: Dave Abrahams

...

I don't personally think that the style of programming that optional is intended for is suitable for high performance/performance critical situations in the first place.

Why not? It seems like a great candidate for common compiler optimizations.

To some extent it depends what style of programming optional is intended for. What I had in mind was the highly object oriented defensive programming style that emphasizes safety often at the expense of performance in vogue around the time Java came out.

...

Pass by reference and return a bool for a conditional return value. Pass the bool and the object separately for a conditional argument. Pass or return a pointer and check if it is null. Yes, my advice really is to not use optional if you want performance.

Why?

I like pass by reference and return a bool over returning an optional for performance because we allocate memory for the result of the function outside of the function call and there is no transfer of ownership of the result. Even with move semantics, you have just changed an unnecessary copy into cheaper unnecessary move.

...

Even if we did everything you can think of to make optional fast you are still better off designing your interfaces in such a way that you don't need it if your goal is performance.

Why do you say that?

I don't trust the compiler to always inline what I want it to if it is busy inlining the optional function calls. The compiler heuristics for inlining can get overloaded and confused as the number of nested inline functions grows. There are no inline function calls to check the bool return value of a function or use the reference passed to the function. I believe that getting the ownership of the data at the right place in the code for performance is preferable to transferring ownership, even with move. It also helps the compiler optimize to be given less code that looks more like what you want the compiler to produce at the end so that it has less opportunity to fail to give you what you wanted. We can imagine an arbitrarily good compiler that always does what we intend, but a compiler that generates a branch for "if(m_initialize) m_initialize = false" is clearly not the ideal compiler we imagine. I did come around to supporting optimization of optional, it might as well be as good of a trade off between safety and performance as we can make it. I don't use optional myself because I prefer alternative syntax for simplicity reasons, convenience, fewer dependencies, etc, and not even performance reasons. Regards, Luke

On Jan 30, 2012, at 3:49 PM, Simonson, Lucanus J wrote:

I like pass by reference and return a bool over returning an optional for performance because we allocate memory for the result of the function outside of the function call and there is no transfer of ownership of the result.

Personally, I like returning values rather than modifying arguments. But more importantly, the caller might not even be able to construct that object to be passed by reference, due to lack of access to an appropriate combination of constructor and initialization arguments, such as when the class has no default constructor.

Even with move semantics, you have just changed an unnecessary copy into cheaper unnecessary move.

If one cares about performance and one's compiler is not capable of doing RVO for optionals, perhaps one should be looking for a better compiler, and not just for better handling of optionals.

On 27.1.2012. 11:32, Domagoj Saric wrote:

a) the lifetime management bool was changed into a properly typed pointer (this actually takes the same amount of space while it provides a no-op get_ptr() member function as well as easier debugging as the contents of optional can now clearly be seen through the pointer, as opposed to gibberish in an opaque storage array) I'd support this only if were configurable. It takes more space for small or non-word-aligned data. It might be more expensive on some systems to calculate the address and store it.

I did think that about defaulting to int_fast8_t for the bool if its alignment>= alignment of T. On my x86 system it's still 1 byte though. On some system it might help. It would also break has_trivial_copy. If someone was naughty and memcopied them, the new version would lead to a very hard to find bug. As for the debugger the new C++ allows for a union to contain a class. So if a placeholder implemention using such a union would show the data in debug.

d) skips redundant/dead stores of marking itself as uninitialised [including but limited to, in its destructor (if it has one)] e) streamlined internal assign paths to help the compiler avoid unnecessary branching Sounds like what I'm after.

f) added direct_create() and direct_destroy() member functions that allow the user to bypass the internal lifetime management (they only assert correct usage) in situations where the user's own external logic already implicitly knows the state of the optional Sounds good. I also wanted these.

g) optional now declares and defines a destructor only if the contained type has a non-trivial destructor (this prevents the compiler from detecting false EH states and thus generating bogus EH code) Yes, that's what I want.

h) optional marks itself as uninitialised _before_ calling the contained object's destructor (this makes it a little more robust in race conditions; it is of course not a complete solution for such scenarios, those require external "help" and/or (m)-reference counting to be implemented) Seems to contradict (g). I'd support something like that only if it can be configured out. Maybe there's some case completely out of optional's scope where you use atomic ops.

If you factor out the aligned storage you can build something else that does ref-counting or a thread safe state machine or whatever.

i) extracted the "placeholder" functionality into a standalone class (basically what would be left of optional<> if the lifetime management "bool" member and logic was removed) so that it can be reused (e.g. for singleton like classes, or when more complex custom lifetime management is required) I 100% agree with this. I think there should be one placeholder implementation. I think boost::function should use it as well. I think it may be useful to users.

k) the lifetime management pointer is now stored after the actual contained object (this helps in avoiding more complex/offset addressing when accessing optionals through pointers w/o checking whether they are initialised) Seems weird. If the front of T is more likely to be used (and old char buffer), your pointer may wind up in a different cache line.

o) avoid branching in assignment and copy construction of optionals that hold PODs smaller than N * sizeof( void * ) where N is some small number Again it would be cool if the user had control over this.

I'm going to have to check out your code. So the big thing I take away from all this it would be really nice if some things were configurable. How do we do that without breaking code? Changing the signature to optional<T,Properties=optional_traits<T> >, might break code that uses boost::optional as a template template parameter. You could just refer to optional_traits inside and force the user to specialize it for his T, but that could create violations of the one definition rule. Also is it OK for optional to depend on enable_if/SFINAE and type traits? Chris

On 1.2.2012. 17:53, Hite, Christopher wrote:

...

On 27.1.2012. 11:32, Domagoj Saric wrote:

...

a) the lifetime management bool was changed into a properly typed pointer (this actually takes the same amount of space while it provides a no-op get_ptr() member function as well as easier debugging as the contents of optional can now clearly be seen through the pointer, as opposed to gibberish in an opaque storage array) I'd support this only if were configurable. It takes more space for small or non-word-aligned data.

True, I was planning on automatically deciding between bool and pointer based on sizeof( T ) after adding lifetime management policy support (m)...

It might be more expensive on some systems to calculate the address and store it.

How? You have to fetch the address either way...

It would also break has_trivial_copy. If someone was naughty and memcopied them, the new version would lead to a very hard to find bug.

True, didn't think about trivial copy until Sebastian outlined the pass-POD-in-register requirements of the AMD x64 ABI. WRT to this it boils down to whether you want a no-op get_ptr() or your platform and compiler actually support passing PODs in registers _and_ most of the types you store in optionals actually satisfy the compiler/ABI requirements for that _and_ you mostly pass and return those optionals by value...

As for the debugger the new C++ allows for a union to contain a class. So if a placeholder implemention using such a union would show the data in debug.

But the pointer approach would also work with "real world" compilers ;)

...

h) optional marks itself as uninitialised _before_ calling the contained object's destructor (this makes it a little more robust in race conditions; it is of course not a complete solution for such scenarios, those require external "help" and/or (m)-reference counting to be implemented) Seems to contradict (g). I'd support something like that only if it can be configured out. Maybe there's some case completely out of optional's scope where you use atomic ops.

It doesn't (contradict (g)), this applies only to situations where you actually have to mark the optional as empty (such as when reset() is called).

If you factor out the aligned storage you can build something else that does ref-counting or a thread safe state machine or whatever.

With (m) I'd rather (in some distant future:) add a refcounting policy to optional (or some future underlying more generic class) so that users don't have to reimplement this...

...

k) the lifetime management pointer is now stored after the actual contained object (this helps in avoiding more complex/offset addressing when accessing optionals through pointers w/o checking whether they are initialised) Seems weird. If the front of T is more likely to be used (and old char buffer), your pointer may wind up in a different cache line.

Well yes, as I said this benefits only the cases where the pointer/bool is not accessed (when an optional is accessed through a pointer/reference). IOW in 99.9% of real world cases the point is quite moot but it did make sense at a particular stage of a project I'm working on (when you have dozens of hundreds of template generated functions you can actually measure savings in code size when you do even such micromanagement). It no longer matters for me but the layout of optional2 is still like that (currently) purely because it turned out like that (in the current stage of development) so I wrote point (k) nonetheless just for the feedback ;)

So the big thing I take away from all this it would be really nice if some things were configurable. How do we do that without breaking code?

Changing the signature to optional<T,Properties=optional_traits<T> >, might break code that uses boost::optional as a template template parameter.

Judging for example from the rationale for the lack of smart_ptr configurability or from the feedback I got for my improved boost::function proposal, it would be very difficult for this type of configurability for optional to get accepted. I was rather planing on making the best of optional with automatic/self configuration based on properties of T and then later (in a galaxy far far away:) propse an underlying library ("smart resource" or something like that), that would separate the lifetime management and storage concerns in a maximally configurable manner, on top of which traditional optional smart_ptr could be built... -- "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

Sorry for not coming back quicker. I've been sick. I did some experimenting in my own codebase with a "array_vector" which acts like vector constructs things when they're added, but like boost::array uses a fixed size array. I tested the techniques I would use to improve optional. So I think I can deliver this very small set of goals cleanly: 1) ~optional doesn't set m_initialized. 2) has_trivial_destructor<T> implies has_trivial_destructor<optional<T> > 3) has_has_trivial_copy<T> and has_trivial_assign<T> implies them optional unless sizeof(T) exceeds some constant max_trivial_copy_Size, which can also be overridden. 4) I'll define a optional_traits<T> with defaults and an optional_with_traits<T,Traits=optional_traits<T> > which can be used to make optionals which override features and from which optional<T> will derive. That's the best compromise if I can't change the signature of optional (Is Robert Stewart right?). I think we should use the traits technique for any new libraries. Thanks Sebastian Redl and Domagoj Saric for pointing out that (2) and (3) will may help some compilers put cheap optionals in registers. Shall I continue? Should I make branch or do it in trunk? Chris

On 7.2.2012. 22:36, Hite, Christopher wrote:

I tested the techniques I would use to improve optional. So I think I can deliver this very small set of goals cleanly:

1) ~optional doesn't set m_initialized.

2) has_trivial_destructor<T> implies has_trivial_destructor<optional<T> >

3) has_has_trivial_copy<T> and has_trivial_assign<T> implies them optional unless sizeof(T) exceeds some constant max_trivial_copy_Size, which can also be overridden.

4) I'll define a optional_traits<T> with defaults and an optional_with_traits<T,Traits=optional_traits<T> > which can be used to make optionals which override features and from which optional<T> will derive. That's the best compromise if I can't change the signature of optional (Is Robert Stewart right?). I think we should use the traits technique for any new libraries.

Thanks Sebastian Redl and Domagoj Saric for pointing out that (2) and (3) will may help some compilers put cheap optionals in registers.

Shall I continue? Should I make branch or do it in trunk?

The optional in sandbox (that passes regression tests) already does 1 and 2 (among many other things) so doing it from scratch again would be reinventing the wheel. ad 3) I would agree to such a compromise: that a bool be used for small PODs (so that they get trivial copy and assign) and a pointer for everything else (so that these get a no-op get_ptr() and nice debugging)... [In my version PODs always/implicitly get "nice debugging" regardless of the lifetime management implementation (bool/pointer/...).] ad 4) As said before, even though my personal prima facie stance is always "the more configurability the better", it is highly unlikely (from reasons previously given) that changing optional's signature would pass. Given that, the best workaround IMO for such "ancient"/"written in stone" constructs that suffer from the "Joe Sixpack" approach, i.e. they are good enough for 90% use cases, is to: - create a separate configurable construct and use it as an implementation detail of the original construct that maximally auto-configures based on T (improving the "good enough percentage" to "98%") - provide global configuration (that overrides auto-configuration) for the original construct (improving the "good enough percentage" to "99.8%") ...and the remaining "0.2%" can use the new construct directly... So far this corresponds to your optional_with_traits approach except that I don't think that providing global configuration by overriding/specializing the default traits is the correct approach. As you noted, this can violate the ODR and AFAIK users are not used that changing a _type_ can violate the ODR and change the behaviour of another type. I'd rather use macros for that (e.g. #define BOOST_OPTIONAL_MAX_BRANCHLESS_COPY_SIZE 4 * sizeof( void * )) because programmers are already used/"trained" to be careful with macros WRT to the ODR _and_ because there already exist tools/compilers which can detect macro ODR violations at link time (e.g. MSVC10)... -- "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

"paul Fultz" je napisao u poruci interesnoj grupi:1328802527.4759.YahooMailNeo@web112602.mail.gq1.yahoo.com...

Actually, you could just take the optional_traits as the first parameter. So you define optional<T> or optional<optional_traits<my_traits<T> > >. Then optional would be specialized for optional_traits that will get the user-defined traits.

(possibly a bit of work to still get the special trivial destructor and assignment functionality in the specialization, but) Clever ;) -- "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

on Thu Feb 09 2012, paul Fultz <pfultz2-AT-yahoo.com> wrote:

Actually, you could just take the optional_traits as the first parameter. So you define optional<T> or optional<optional_traits<my_traits<T> > >. Then optional would be specialized for optional_traits that will get the user-defined traits.

Be aware that tricks like this start to break down in generic contexts, as optional_traits<T> specializations are treated differently by optional from all other types. -- Dave Abrahams BoostPro Computing http://www.boostpro.com

On Fri, Jan 27, 2012 at 5:32 PM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:

a) the lifetime management bool was changed into a properly typed pointer (this   actually takes the same amount of space while it provides a no-op

AFAIK bool and pointer aren't the same size. How can it still take the same amount of space? Olaf

On 28.1.2012. 13:34, Olaf van der Spek wrote:

On Fri, Jan 27, 2012 at 5:32 PM, Domagoj Saric <domagoj.saric@littleendian.com> wrote:

...

a) the lifetime management bool was changed into a properly typed pointer (this actually takes the same amount of space while it provides a no-op

AFAIK bool and pointer aren't the same size. How can it still take the same amount of space?

A "language lawyer" might be more precise but, for optional<T>: - if the bool member is before the T member the compiler has to add alignment_of<T>::value - sizeof( bool ) bytes of padding after the bool so that the T member would be properly aligned - if the bool member is after the T member the compiler has to add the same amount of padding after the bool member to satisfy the requirement that there are no "holes" between individual (properly aligned) instances of optional<T> in arrays of optional<T>... IOW, my statement in (a) does not for example hold for chars or shorts... -- "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

On 30.01.2012, at 19:58, Dave Abrahams wrote:

I support this work. Optional should be optimal :-)

on Fri Jan 27 2012, Domagoj Saric <domagoj.saric-AT-littleendian.com> wrote:

...

ps. AFAICT the only real obstacle in having really nice codegen with boost::optional<a_fundamental_type> is lack of proper ABI/compiler support for passing and returning small structs in registers...

Please tell me that at least *some* C++ compiler does that nowadays...?

All Linux compilers on x64 platforms follow the AMD64 ABI, possibly with minor variations/bugs. This ABI specifies that classes are passed in registers if - they are trivially copyable and destructible (optional should be specialized for types that fulfill these criteria to ensure this), - they have no virtual functions or bases, - they are smaller than 2 qwords (4 qwords if all members are float, double, or SSE types), and - they don't contain any weird stuff, like 80-bit long doubles or unaligned fields. The Mac ABI for x64 is very close, though I don't know the differences. The Win64 ABI is far less nice about registers. It passes the first four arguments in registers, and spills everything else onto the stack. It does not pack multiple values into a register. If a value is larger than 8 bytes, it is not split across registers. The ABI description says that "aggregates" can be passed in registers, but it doesn't elaborate on whether this refers to the C++ definition of aggregates (unlikely!) or whatever else the definition is. It sounds pretty useless. I'm not aware of any x86-32 calling convention that passes classes of any kind in registers. Sebastian

On 30.1.2012. 21:30, Sebastian Redl wrote:

...

All Linux compilers on x64 platforms follow the AMD64 ABI, possibly with minor variations/bugs. This ABI specifies that classes are passed in registers if - they are trivially copyable and destructible (optional should be specialized for types that fulfill these criteria to ensure this), - they have no virtual functions or bases, - they are smaller than 2 qwords (4 qwords if all members are float, double, or SSE types), and - they don't contain any weird stuff, like 80-bit long doubles or unaligned fields.

The Mac ABI for x64 is very close, though I don't know the differences.

Thanks for the summary (didn't know there was a separate OS X x64 ABI).

...

The Win64 ABI is far less nice about registers. It passes the first four arguments in registers, and spills everything else onto the stack. It does not pack multiple values into a register. If a value is larger than 8 bytes, it is not split across registers. The ABI description says that "aggregates" can be passed in registers, but it doesn't elaborate on whether this refers to the C++ definition of aggregates (unlikely!) or whatever else the definition is. It sounds pretty useless.

Right, the Windows/MSVC x64 ABI is a major !?wth!?...I just can't think of a reason why they had to invest resources into making their own ABI that is so complicated and so inferior to the AMD proposed one (e.g. you can't pass an SSE vector through an XMM register??).

Correcting myself: the Common C++ ABI for x86-32 actually specifies that trivially copyable and destructible classes are treated just like simple values for parameter passing, so they can be passed and returned in registers. Of course, the far smaller register file of x86-32 makes that still not very useful.

Unfortunately I have never seen MSVC pass or return any struct through registers even though it has interprocedural optimizations and link time code generation capabilities so it can "invent" (as the documentation claims) its own calling conventions for non exported functions. Don't know whether any other x86 compiler is able to do so... In any case, the problem is that there is no nearly portable/standard/wide-spread way (pragma, decl specifier...) to tell the compiler to return small PODs in registers, especially not just for a particular function and/or POD type. GCC has -freg-struct-return but that seems nearly useless because it applies to the whole binary and so it requires the OS to be built with that option. -- "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

On 30.1.2012. 19:58, Dave Abrahams wrote:

I support this work. Optional should be optimal :-)

Or, optimal should not be optional (everything should be optimal :D).

...

a) the lifetime management bool was changed into a properly typed pointer (this actually takes the same amount of space while it provides a no-op get_ptr() member function as well as easier debugging as the contents of optional can now clearly be seen through the pointer, as opposed to gibberish in an opaque storage array)

Seems to me this potentially makes optional<char> much bigger. No?

True (see my answer to Olaf and Christofer).

...

h) optional marks itself as uninitialised _before_ calling the contained object's destructor (this makes it a little more robust in race conditions;

I generally disagree with this sort of defensive programming. Won't it just mask bugs?

I generally disagree too but in cases where there is actual "defensive programming" i.e. handling of invalid/buggy usage. The typical example is code that asserts that a pointer is not null and then handles the case if it is. There is none of that here. Imaging writing optional from scratch, at one point you would have to decide the same thing, when to mark the optional as empty - before or after calling the destructor. Either way you choose won't make a difference (semantic or performance wise) for correct code. Incorrect code will crash less. Isn't that a good thing (considering there is no actual handling of incorrect code)? Considering that "there is no bug free software" (one wonders about laser brain surgery robots :), wouldn't it be better to "a priori crash less" and add separate sanity checks for invalid concurrent access in order to catch bugs (obviously this is more work and I don't know if any Boost component does anything like this actually)? Perhaps there is no "right" answer to this question and its more a matter of preference so consider the above as "my 2 cents"... ps. and yes, I forgot the buzz: (p) rvalue references support :) -- "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