Conversation
|
Someone (@tomaszkam perhaps) should check my work. A word about why the Also, this solution provides strong motivation for providing relational operators for ranges, which default to cc'ing @asutton and @sean-parent who have previously expressed the opinion that the "common type" as discussed in N3351 need only be notional, not manifest in a program. I may yet be convinced of this, but my gut says that if we are not checking it syntactically, the requirement will be ignored. EDIT: I'll also note that once the |
Egads no. WG21 just got done arguing that |
|
Oops, you're right about that. :-P EDIT: OK, fixed. The relational operators were unnecessary anyway. |
ericniebler
force-pushed
the
benchmark
branch
2 times, most recently
from
e88965e to
29d576f
Compare
You have proved that there is single compiler (as the code can be used with only 1 version) and single machine that is able to give the same speed for STL2 and cmcstl. While you are ware aware see your's blog post, that compiler have given very different result for such test previously. Note that due Concepts TS requirements, we cannot check more than 1 compiler, |
|
I can implement the same benchmark in range-v3 and show the same effect on any compiler (capable of compiling range-v3, that is). The only reason you were seeing any slow-down at all was because your STL1 code wasn't using pointers-to-members and your STL2 code was. That is, you were comparing apples to oranges. (Compilers do a poor job of optimizing pointers-to-members, possibly because they are not that common in end-user code.) As for that old blog post, there are some views that are difficult for some compilers to optimize; |
|
Few things regarding the request:
So, please provide a solution that actually works with current working-draft for C++20, or at least, it is proposed to be included. Any other option may (and probably won't be available) for programmers. |
|
The fact is I am unable to reproduce your result on my system. I am using g++-7: Then the program is compiled as follows (I have wrapped And I get the following result on my PC with Intel(R) Core(TM) i7-6700K CPU @ 4.00GHz: Note, that I am only required to prove that some users are not able to tap into optimization giving equal performance, to justify claim I made in paper (of course, excluding builds without optimizations enabled at all). However to prove, that the STL2 is equally efficient abstraction, we need to show that on-par performance will be available for all C++ users - including ones targeting embedded, or other devices. |
I took a shortcut. Of course a full solution would completely flesh out
They are (disguised) function objects, so my code will work as written in C++20. (We're a little circumspect in the current draft about whether the algorithms in And here is my result for gcc-7.3, again showing no difference. I use Again, the STL2 code is shorter, simpler, more readable, and faster, even with the |
|
Yes, the difference is caused by the usage of -O2 vs -O3, however, the apps I have contact with consistently use O2, for them, we are seeing performance drop caused by compiler not optimizing the code - exactly the point I made in paper.
|
|
I suggest you both test with the implementation on the EDIT: My numbers for g++-7 (Ubuntu 7.3.0-21ubuntu1~16.04) with I see no significant differences between the STL1 and STL2 benchmarks. |
|
@tomaszkam, I also suggest you compile |
|
Putting -NDEBUG with -O2 does not help: Bumping up optimization level to O3, at least give me consistent results with one from Eric: However, change in optimization level may not be an option for some of the projects. |
An implementation is in no way required to implement them as function objects: it's only required that they are not findable by ADL and inhibit ADL when found via unqualified name lookup. There's no other pure library implementation, but a front end developer could throw together a custom attribute to provide those properties for function templates in a day. Your code may or may not work as written in C++20. (I really, really want to force EWG to fix functions so we can - oddly enough - actually use them in libraries.) |
Is that with |
I used To something that is guaranteed to work with standard, i.e.: And also have |
|
@CaseyCarter wrote:
Bah, humbug! Being able to pass functions to functions is fundamental and very useful. It galls me that implementors will write them as objects (mark my words <shakes cane>), but we're not allowed to treat them as such. For the record, I see no performance impact after lifting @tomaszkam wrote:
If the argument you are bringing to San Diego is that you should be free to write worse code because it optimizes a little better at lower optimization settings, I can tell you how that argument will go over. Don't get me wrong. You have made some good points in your paper; in particular the unfortunate integer promotion rules and their interaction with the semantic constraints of |
I've made a similar change to #182 (I stored the lambda in a named variable outside the benchmark loop). I still have results that differ by at most 5ns at both |
Being able to pass function templates and overload sets to functions would be useful as well. I consider it a defect in C++'s support for the functional paradigm that we can't do this today. |
|
@tomaszkam One other suggestion for your paper: rather that simply dropping the Given such a purely semantic common type constraint on |
But please provide a justification for this requirement in case of the weak orderings, where the objects are merely equivalent. The underlying mathematical model allows building relation over different types (the domain is just union of the objects of a different type), the definition placed in the book you are basing your work (Elements of Programming) does also not mention such requirement. From that perspective, this is only the product of your proposal. Saying "it is meaningless" without pointing out any problems with it (breaking semantic models, inability to perform runtime checks, algorithm not working), is not an argument, is just opinion, that does not have support in the underlying mathematical model. This is even more evident, by the fact that you can break your semantics requirement (see your example any_view) and algorithms works without a problem - a requirement that is never used is superfluous. The is a major difference between weak (comparators) and strong orderings (<, ==), as one of the allows an equivalent object (and things are equivalent if they from equivalence relation - there are 3 axioms required for that and nothing more), and other make objects equal (in the mathematical sense same). For the later I agree, that we should be able to point of common_type, as they are meant to represent same underlying entity, so they should have common reference (very similar case to Assingability for example). |
|
I am willing to assume that actually the difference on the result for the test example, is fault on my side. I am also planning to check it on AMD low-end laptop, to see if it may be architecture related. The example was a simplification of the actual use case we have - i.e. comparing operating flights of itineraries. I have prepared an updated example, that compares departures on actual flights (there should be more fields being compared, but want to build it iteratively). I want to check if I can reimplement it with STL2 without performance loss. However, I have miserably failed to build STL2 equivalent for that code. My attempt may be found at: Also, if there is better way to express such code, I would be happy to change it. |
|
The difference from the previous example is that now instead of transforming The code to construct view looks like follows: Now, I am able to construct such view and iterate over it, but the invocation of Edit: And should be : Edit 2: |
3 participants
Thusly proving that @tomaszkam's "itinerary" example can be implemented efficiently in STL2 with very minor changes, leaving the
CommonReferencerequirement intact onStrictTotallyOrderedWith.The benchmark, compiled with gcc-8.1 on a MacBook, gives me the following results:
That is, according to the benchmark, STL2 is actually slightly faster than the STL1 code. Go figure.
This relates to ericniebler/stl2#34.