Hi from Michael

[Michael Wong]

Hi I am sorry I have not been in contact since the Bof at CppCon. Let's just say I have gone around the world twice since then and is now behind the great fire wall for this month where I am reposted as a visiting scientist but where google products do not work well without trickery.

Thanks for Sean for taking the initiative to start this google group. I have asked everyone who contacted me post-Bof to join this group.
I like to help the group but let's just say I am already super-split in terms of duties for the std and my company.

As Sean said, the mailing deadline has indeed past. I propose we continue discussion here and review this document posted before to the std but never got very much attention.
http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2271.html

It would be good to get an analysis update to see if many of the issues still remain or got worst or better with c++ 11/14. Add any new issues. Partition them as Sean said into low hanging fruit.

The goal is to aim for a paper and presentation in May 2015 in Lenexa Kansas. There we can present our rationale and try to push for a study group. I don't see the problem being motivations in starting a study group, but rather if there is a cohesive enough set of issues. This is because I see a diverse set of interest here which somewhat intersect between games, graphics, real time, high performance, low latency, embedded systems.

But I feel in there must be some common interest. I can help to get such a study group started, but likely won't be able to chair it as I already have too many titles. But Sean looks like he is doing a great job already. ...

Thoughts on this plan?

[Sean Middleditch]

On Mon, Oct 13, 2014 at 4:43 AM, Michael Wong <fragga...@gmail.com> wrote:
> As Sean said, the mailing deadline has indeed past. I propose we continue discussion here and review this document posted before to the std but never got very much attention.
> http://www.open-std.org/jtc1/sc22/WG21/docs/papers/2007/n2271.html

Really? Odd. It's been a frequent talking point in my (outside the
committee) experience. It would be helpful to know if there are any
notes or minutes from the meeting it was presented at.

>
> It would be good to get an analysis update to see if many of the issues still remain or got worst or better with c++ 11/14. Add any new issues. Partition them as Sean said into low hanging fruit.

It is getting a little long in the tooth. Looking at the list of
motivations again, most of them have been taken care of (some only by
very recent commonly available compiler tech improvements).

My thoughts on the document now (these all need verification!):

- std STL allocators are painful to work with and lead to code bloat
and sub-optimal performance. This topic is addressed separately within
this document.

C++11 simplified allocators and the polymorphic allocator proposal
help here a lot. I've found that a lack of proper alignment support
and for more advanced allocation flags (e.g., clear to 0) annoying but
not show stoppers.

- Useful STL extensions (e.g. slist, hash_map, shared_ptr) found in
some std STL implementations are not portable because they don't exist
in other versions of STL or are inconsistent between STL versions
(though they are present in the current C++09 draft).

All three of those extensions are in C++11. We are still missing some
handy ones, though, like flat_map.

- The STL lacks functionality that game programmers find useful (e.g.
intrusive containers) and which could be best optimized in a portable
STL environment. See Appendix item 16.

Still true.

- Existing std STL implementations use deep function calls. This
results in low performance with compilers that are weak at inlining,
as is the currently prevalent open-source C++ compiler. See Appendix
item 15 andAppendix item 10.

All the major compilers today support inlining small accessor
functions evne in debug builds. This item needs measurement, though.

- Existing STL implementations are hard to debug. For example, you
typically cannot browse the contents of a std::list container with a
debugger due to std::list's usage of void pointers. On the other hand,
EASTL allows you to view lists without incurring a performance or
memory cost. See Appendix item 2.

Mostly a tools issue. Visual Studio for instance has a powerful debug
visualizer feature and supports its own STL out of the box. GDB has an
even more powerful debug visualizer and supports libstdc++ out of the
box.

- The STL doesn't explicitly support alignment requirements of
contained objects, yet non-default alignment requirements are common
in game development. A std STL allocator has no way of knowing the
alignment requirements of the objects it is being asked to allocate,
aside from compiler extensions. Granted, this is part of the larger
problem of the C++ language providing minimal support for alignment
requirements. Alignment support is proposed for C++09.

Use issue. The C++11 alignment issue has no effect on free-store
allocations. However, I think this might be less of a "we need
explicit alignment" issue and more "the native alignment should
include the SIMD/vector types of the CPU." (which in my experience yet
is the major reason I have to work around default allocation
alignments.)

- STL containers won't let you insert an entry into a container
without supplying an entry to copy from. This can be inefficient in
the case of elements that are expensive to construct.

emplace_back and move semantics.

- The STL implementations that are provided by compiler vendors for
the most popular PC and console (box connected to TV) gaming platforms
have performance problems. EASTL generally outperforms all existing
STL implementations; it does so partly due to algorithmic improvements
but mostly due to practical improvements that take into account
compiler and hardware behavior. See Appendix item 20.

Not the standard's fault... mostly.

One could make the case that the standard could be stricer about some
of these issues and not leave them all as QoI items. One that gets me
is small-object "optimizations" in things like std::string or
std::function. I can't rely on what size of data will or will not
trigger an allocation in a portable manner. It becomes worthwhile to
rewrite them just to get a consistent cross-platform cross-vendor
known semantics here.

- Existing STL implementations are hard to debug/trace, as some STL
implementations use cryptic variable names and unusual data structures
and have no code documentation. See Appendix item 2.

Still a common issue. This has some up in some proposals for allowing
certain headers to ignore user macros, which are mostly the reason
that these cryptic issues exist.

- STL containers have private implementations that don't allow you to
work with their data structures in a portable way, yet sometimes this
is an important thing to be able to do (e.g. node pools). See Appendix
item 22.

Not quite as relevant anymore, e.g. vector::data(). Needs more investigation.

- Many current versions of std STL allocate memory in empty versions
of at least some of their containers. This is not ideal and prevents
optimizations such as container memory resets that can significantly
increase performance in some situations. An empty container should
allocate no memory.

"Many" is an overstatement, but "any" is a problem. Might be another
issue where the standard needs to be stricter. I understand that some
standard containers actually have to do this for move operations and
the like, though, in order to not invalidate iterators. This might be
one of the cases similar to unordered_map where a small oversight in
the standardese hampered the usefulness of the container significantly
but is now embedded in stone.

- All current std STL algorithm implementations fail to support the
use of predicate references, which results in inefficient hacks to
work around the problem. See Appendix item 3.

There have been proposals for this, either directly or indirectly, but
focus on reviewing those and helping them through would be good.

- The STL puts an emphasis on correctness before practicality and
performance. This is an understandable policy but in some cases
(particularly std::allocator) it gets in the way of usability and
optimized performance.

This is a hard one. I think the correctness is the right choice as the
default. There are some cases where the standard could allow more
dangerous operations; see the discussions on
vector::push_back_no_grow() for instance.

> But I feel in there must be some common interest. I can help to get such a study group started, but likely won't be able to chair it as I already have too many titles. But Sean looks like he is doing a great job already. ...

It's unlikely I'll be able to as all indications I've received are
that my company is not interested in sending me to any meetings
outside of the Seattle area, at least until after our current title
ships (not until 2016 at the earliest).

--
Sean Middleditch
http://seanmiddleditch.com

[Michael Wong]

I will check to see if this was reviewed and what the feedback, if any was,

Thanks for the analysis. This work could form an initial paper, IMHO.

Sent from my iPad

Yes game developers that I know tend to have crazy deadlines, which is a necessity of the job. So we need someone who can represent this group at the std consistently, showing up at every meeting, putting pressure on the group to respond. This is ultimately what gets features through.

[Sean Middleditch]

I'm planning a more in-depth analysis of some of the stuff, but time
of course is a problem. There's a number of items that do still seem
valid complaints but without numbers, it seems unwise to really push
the issue.

I think we have a person or two from EA on this list; it would be nice
to hear from them on the topic of what EASTL looks like today vs then,
any justifications/benchmarks for its continued existence (if it
indeed does), any legally publishable documentation on it, etc.

> --
> You received this message because you are subscribed to the Google Groups "unofficial-real-time-cxx" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to unofficial-real-ti...@googlegroups.com.
> To post to this group, send email to unofficial-r...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/unofficial-real-time-cxx/F5632C3C-A939-474D-A661-EE341046E60F%40gmail.com.
> For more options, visit https://groups.google.com/d/optout.

[Michael Wong]

I checked the Library chairs while at the Urbana C++ Standard meeting and both (Matt Austern and Howard Hinnant) recalled there was no review of this paper. I have invited Paul Pedriana and he can probably inform us whether he recall there was any review of that paper at the Standard meeting he attended. Thanks.

On Fri, Oct 24, 2014 at 11:55 AM, Michael Wong <fragga...@gmail.com> wrote:

Update on what I found from the Std minutes on the EASTL paper:

This paper was considered a late paper in the Oxford 2007 meeting and was recorded as:
EASTL.html: An article on the standard library at Electronic Arts and possible problems in the current standard

But as far as I can find, there was no notes or discussion on this, nor was there any follow-on discussion in the following meetings for all of 2007.

I will double check in 2 weeks at the Std meeting to see if anyone has any recollection of reviewing this paper. But right now, my belief is that there was no review. Also that period of time was a particular busy time for C++11 so I can see this falling through the gap, or the Library group mistook it as an opinion paper.

On Tue, Oct 21, 2014 at 3:55 PM, Sean Middleditch <se...@middleditch.us> wrote:

I'm planning a more in-depth analysis of some of the stuff, but time
of course is a problem. There's a number of items that do still seem
valid complaints but without numbers, it seems unwise to really push
the issue.

I think we have a person or two from EA on this list; it would be nice
to hear from them on the topic of what EASTL looks like today vs then,
any justifications/benchmarks for its continued existence (if it
indeed does), any legally publishable documentation on it, etc.

Agreed. It would be nice to get an update from EA.  When we are ready, I would probably put it in a different format so that it can get more attention. Thanks.

[Sean Middleditch]

As an update, the approach I'm leaning with after my last review of the paper is to push smaller more focused papers through. Enough of the EASTL work is either invalidated by language updates (e.g. move semantics), compiler updates (GCC's -Og and other vendors' related options), changes in the industry (a 'large' game is so much bigger than 2,000,000 lines of code these days, especially when you consider tools, middleware, plugins, etc.), or other library updates (modern allocators) such that a holistic "here's a new STL and our problems" approach seems a bit doomed. The biggest bits I'm seeing both from EASTL and my own experiences that are missing are the containers or small independent tweaks to the language or libraries.

Additions are the easy part. Adding flat_map or the like would involve straight-forward stand alone papers.

The small changes or stricter requirements EASTL places on containers are common enough for our needs, e.g. requiring that containers never allocate memory on default construction. I know that there have been many arguments on the ISO lists recently about other simple changes (e.g. noexcept on move) that aren't acceptable because some library implementations allocate unique nodes for empty containers, which IMO should be addressed by a paper advocating why the cons outweigh the pros of such an implementation and why the standard should disallow them as the EASTL does (just like how C++11 disallowed COW strings, despite several major implementations use of them).

Many other changes can be very small, minimal items, I think. The feature of splitting <algorithm> up into some small headers can be quite valuable and made fully backwards compatible by just having an <algorithm> that includes all the other algorithm headers.

Some of the changes are obviated by compiler or tooling updates. Vectors using pointers as iterators for instance is a big issue for out-of-the-box debug builds in some implementations, but with a combination of modern debug visualizers and compilers smart enough to inline operations that have low debuggability impacts means that std::vector on most implementations is perfectly suitable once you tweak build options suitably (disabling iterator debugging, enabling inlining or the like on debug builds, etc.). The biggest problem I could see the standard addressing here is how vendor-specific all these parameters are, perhaps via some kind of _CPP_NO_DEBUG macro or the like that implementations are all recommended to interpret as "turn off all the crap you don't strictly need to be standards compliant."

The ability to safely disable exceptions is another big one, but I don't see that having much chance of acceptance just yet. I'm led to believe that Google is aware of the problems even outside of embedded/real-time and certainly Sony is as well, but the ISO committee will be a much harder nut to crack on this item IMO.

Summary: items should be addressed individually and split up into separate work items, not a global "evaluate the EASTL." Or at least that evaluation should just be identifying the individual work items. I think the split works down to broad work groups as:

(1) new containers

  (a) inline lists and trees

  (b) fixed/flat trees

  (c) whole new containers like ring_buffers

  (d) whole new algorithms like radix_sort

(2) stricter requirements on existing containers and algorithms

  (a) no allocations for default-empty construction

  (b) guaranteed cheap/trivial/noexcept move

  (c) debug builds cannot break algorithm efficiency requirements (*cough* Microsoft's std::sort *cough*)

(3) misc. issues

  (a) smaller headers, like <algorithm>

  (b) QoI on container inspection

  (c) ???  -fno-exceptions, -fno-rtti or equivalents should be guranteed to be supported by the library, possibly via feature-testing support for these features