[review] **NEXT WEEK** Review of Outcome (starts Fri-19-May)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
107 messages Options
1 ... 3456
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Although that's VS 2017, and godbolt.org doesn't have 15. :-/

-----Original Message-----
From: Peter Dimov via Boost
Sent: Friday, May 19, 2017 17:59
To: [hidden email]
Cc: Peter Dimov
Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)


> Would be nice if we could see that demonstrated on godbolt.org.

https://godbolt.org/g/QeHRpl

std::error_code f()
{
  return std::error_code( 5, std::system_category() );
}

->

___$ReturnUdt$ = 8                                  ; size = 4
f PROC
        call     std::_Immortalize<std::_System_error_category>
        mov      ecx, DWORD PTR ___$ReturnUdt$[esp-4]
        mov      DWORD PTR [ecx+4], eax
        mov      eax, ecx
        mov      DWORD PTR [ecx], 5
        ret      0
f ENDP


_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
VS 2015, -Ox -Ob2:

;    COMDAT ?f@@YA?AVerror_code@std@@XZ
_TEXT    SEGMENT
___$ReturnUdt$ = 8                    ; size = 4
?f@@YA?AVerror_code@std@@XZ PROC            ; f, COMDAT

    push    ebp
    mov    ebp, esp
    call
??$_Immortalize@V_System_error_category@std@@@std@@YAAAV_System_error_category@0@XZ
; std::_Immortalize<std::_System_error_category>

    mov    ecx, DWORD PTR ___$ReturnUdt$[ebp]
    mov    DWORD PTR [ecx+4], eax

    mov    eax, ecx

    mov    DWORD PTR [ecx], 5

    pop    ebp
    ret    0

That's update 3 though, things may have been different in u0..u2.

-----Original Message-----
From: Peter Dimov via Boost
Sent: Friday, May 19, 2017 18:01
To: [hidden email]
Cc: Peter Dimov
Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)

Although that's VS 2017, and godbolt.org doesn't have 15. :-/

-----Original Message-----
From: Peter Dimov via Boost
Sent: Friday, May 19, 2017 17:59
To: [hidden email]
Cc: Peter Dimov
Subject: Re: [boost] [review] Review of Outcome (starts Fri-19-May)


> Would be nice if we could see that demonstrated on godbolt.org.

https://godbolt.org/g/QeHRpl

std::error_code f()
{
  return std::error_code( 5, std::system_category() );
}

->

___$ReturnUdt$ = 8                                  ; size = 4
f PROC
        call     std::_Immortalize<std::_System_error_category>
        mov      ecx, DWORD PTR ___$ReturnUdt$[esp-4]
        mov      DWORD PTR [ecx+4], eax
        mov      eax, ecx
        mov      DWORD PTR [ecx], 5
        ret      0
f ENDP


_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost



_______________________________________________
Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> The hack is the above. We cache the address of the canonical singleton,
>> and the noinline seems to cause the optimiser to disregard the thread
>> fence and thus to not give up quickly. The resulting assembler generated
>> is greatly improved on MSVC, a single result<T> shrinks from ~260
>> opcodes to less than 5.
>
> As I use error categories extensively in my library, a blog post or
> article focusing on this technique would be useful (if it doesn't
> already exist).

It's a micro optimisation which only affects code bloat on one
particular compiler currently.. I didn't, and still don't, think it
worth writing up.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
>> The hack is the above. We cache the address of the canonical
>> singleton, ...
>
> Hm. I must be missing something.
>
>    BOOSTLITE_NOINLINE inline const std::error_category &_generic_category()
>    {
>        const std::error_category &c = stl11::generic_category();
>        return c;
>    }
>
> This doesn't cache anything. It just calls stl11::generic_category() and
> returns the result.

Yes, you're right. Looks like I removed the static storage at some
point. I would assume I found I didn't need it any more to achieve the
desired removal of code bloat.

>> The resulting assembler generated is greatly improved on MSVC, a
>> single result<T> shrinks from ~260 opcodes to less than 5.
>
> Would be nice if we could see that demonstrated on godbolt.org.

It's an atomic fence to the *compiler*, not to the CPU. It can't be
demonstrated online easily. You need sequences of operations to be
folded by an optimiser where the fence inhibits folding.

You can have a look at the git history of
https://github.com/ned14/boost.outcome/blob/develop/test/constexprs/msvc.csv
if you really need proof.

Niall

--
ned Productions Limited Consulting
http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
Niall Douglas wrote:

> It's an atomic fence to the *compiler*, not to the CPU. It can't be
> demonstrated online easily. You need sequences of operations to be folded
> by an optimiser where the fence inhibits folding.

Or, stated differently, your function just inhibits inlining
std::system_category() into user code.


_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list

> Obviously the games
> and finance industries take a pretty consistent and strong opinion there
> i.e. globally disable all C++ exceptions,

FWIW this statement is too strong. The amount of C++ in the finance industry is vast , too vast for there to be an consistent no-exceptions theme. Indeed in my little corner it's the other world around - the bulk of code is compiled with exceptions /en/abled.


On 19 May 2017, at 00:04, Niall Douglas via Boost <[hidden email]> wrote:

>>> Once you've been using these things in your own code for a bit, for
>>> especially low level systems libraries you'd never willingly go back.
>>> The difference is very similar (to me at least) to that feeling you have
>>> when you must go back to writing C++ 98 without Boost after you've been
>>> using C++ 14 for a quite a while.
>>
>> I trust your judgement on this. I just wish short examples in the docs
>> could convince me about that.
>
> I did have some examples culled from real world usage in an earlier
> edition of the tutorial. People found them too hard to grok. They wanted
> toy, unrealistic examples instead, which is what you have now.
>
>>> All that said, 60-70% of C++ would see no benefit to using Outcome nor
>>> Expected. Such code is always better off using only C++ exceptions.
>>>
>>
>> That leaves 30-40%, which is a huge market share.
>
> If you follow the C++ Reddit on the topic of Either and Maybe monads, in
> the very long threads of bikeshedding you'll find one fairly widely held
> opinion that choosing something like Outcome is effectively the same as
> a library implementation of pre-table EH whereby a fixed overhead is
> added to all code execution in exchange for various benefits such as
> very fast handling of failure. Some would also argue that by forcing the
> programmer to manually write out the logic for handling failure at the
> point of failure, it improves auditing and maintenance of failure
> handling. This sort of C++ code, mostly low level systems programming,
> benefits from using something like Outcome.
>
> However a majority of C++ very rarely needs to handle more than one form
> of failure in any given local use context. For this sort of C++,
> exceptions prevent cluttering the code with failure handling, and remove
> that fixed overhead from execution. They're a better choice, a better fit.
>
> There are secondary arguments about cost of debugging and bringing code
> to production quality, but those are hard to prove. Obviously the games
> and finance industries take a pretty consistent and strong opinion there
> i.e. globally disable all C++ exceptions, but other users very
> interested in low latency do make use of C++ exceptions, so if you have
> talented programmers anything is possible, even easy. I suspect that in
> games and finance that assuming top notch programmers everywhere in a
> large org is unwise, so better avoid ruinous surprise by someone messing
> with code they don't understand.
>
> Niall
>
> --
> ned Productions Limited Consulting
> http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/
>
>
> _______________________________________________
> Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: [review] Review of Outcome (starts Fri-19-May)

Boost - Dev mailing list
In reply to this post by Boost - Dev mailing list
Le 19/05/2017 à 15:48, Andrzej Krzemienski via Boost a écrit :

> 2017-05-19 15:08 GMT+02:00 Niall Douglas via Boost <[hidden email]>:
>
>>>> The constexpr variables are already there. So basically do we prefer:
>>>>
>>>> 1. .ensure_empty(), .ensure_value(), .ensure_error() and
>>>> .ensure_exception()
>>>>
>>>> 2. Or .ensure(empty), .ensure(value), .ensure(error) and
>> .ensure(exception)
>>>> I figure the latter looked nicer. It's same difference to the compiler,
>>>> simple overload matching is constant time.
>>>>
>>> Just one note. If I use namspace prefixes, the notation with "constants"
>>> becomes longer:
>>>
>>> `o.ensure_empty()` becomes `o.ensure(boost::outcome::empty)`
>>>
>>> One could respond to this "just import anything from namespace
>>> `boost::outcome` into the scope", but that is imposing on me a certain
>>> style of programming, which I not necessarily want to adapt.
>> Yes that's a good point.
>>
>> Also, after a few nights of sleeping on it, I'm not keen on .ensure_XXX().
>>
>> Would people be okay with:
>>
>> * o.check() <= (void) o.value()
>>
>> * o.check_error() <= (void) o.error()
>>
>> * o.check_exception() <= (void) o.exception()
>>
> Given that this "ensure" functionality would be used rarely, and some even
> suggest there is no use case for it, I would be satisfied with this syntax
> `(void)o.value()`.
+1 KISS
Vicente

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
1 ... 3456
Loading...