Goal and Scope of SG14 Games Dev/Low Latency

[michaelw]

Hi all, part of the discussion we need to have is define more fully our mandate. Incidentally, a paper  at a meta-level on the scope and mandate (or summarizing what is said in this thread) can indeed be one of the paper we write up for submission for discussion at the SG14 calls/meetings. Please see this thread on logistics:
https://groups.google.com/a/isocpp.org/forum/?fromgroups#!topic/sg14/SOcxeUNSzQw

We have broadly described to WG21 (henceforth ISO C++ Std committee) the pain points of Games developers, but we also included what I call Common Interests from areas relating to real-time (such as flight simulations),  graphics, and low latency. I have somewhat deliberately exluded embedded as there is already a tentative group being formed for that, although there is some overlap. Another group we may overlap with is SG1, Parallelism and Concurrency and SG5 Transactional Memory. That is not surprising and certainly at times, we will need to consult these groups to see what opinions they may have in our proposal.

I like to kick it off by looking at various areas of scope and goal.

However, our mandate is clearly towards improve support for
Games
Low Latency
Real-time applications 
Graphics
Financial Trading

Does Financial and Trading applications  fall into this through their insane need for real-time and low latency? I think so. At the Lenexa meeting when I gave the talk, several financial trading firms took immediate interest and wanted to know if we can add them to the Common Interest. These are companies from Morgan Stanley, DRW Trading, especially people involved with Quantitative (or sometimes called Black Box, or High Frequency) trading.

How do people feel about that? If we want to add financial sector, then we will need someone from the financial groups to be added to SG14. I know Bjarne is asking about it as he works for Morgan Stanley now, and he will certainly add someone to help participate. Others have too such as Nevin at DRW.

Another group are the High Performance Computing computational scientists. Hal at Argonne National Lab commented that they are also interested in intrusive containers as much as Game developers are.

Next, what about GPU and Accelerated graphics support in C++? Should we consider direct support for Accelerators in C++? There is currently very little direct support for it other then a suggestion/mention in the Parallelism TS to enable GPU support through a library call for STL (although that is just an extension) and no meaning definition of it exists.

I have spoken to Sean and know Adobe wants this.

There is as yet no direct language support for accelerators (such as Nvidia Tesla, or Intel Xeon Phi). There is already significant examples of this support in other languages such as OpenMP, OpenACC, OpenCL, and Intel's Compute and MS's C++AMP/DirectX. The recently announced Vulcan language is supposed to be another step beyond OpenGL. I have personal experience sheparding the Accelerator offload target support in the latest OpenMP 4.0 specification.  But a common problem with all these is that they do not work well with C++, templates or exception (except C++ AMP)

I wonder if people would agree that Accelerator C++ language could be one of the long poles (larger goals) of SG14 in addition to many of the additions mentioned elsewhere in this forum. If we do, then one of the thing we could do is consider initial comparison for people to get familiar with all the existing industry models. I can help with these as OpenMP has been heavily involved in pushing heterogeneous computing.

Other people's thoughts on what the goals and scope may be:

When I started discussing this with Sean, he commented and seem to agree that we make this more about the Common Interest rather then just Games-specific:
"Perhaps a coming-together sort of talk, trying to point out the common ground for both game developers and others (e.g., how much of the same performance stuff we've been doing for decades is starting to become common mantra at companies like Google and Facebook, because faster == less power usage and less latency) and why we should all just get along and work towards our common goals?

The gist is that we're introducing WG21, which really does have kind of two goals on the games side: (a) get game developers interested in interacting with a committee they've classically just ignored and (b) help guide the committee towards better support for one of the largest and most profitable industries using C++ heavily.

The real-time and embedded folks are much in a similar boat, so I don't think we should be too games specific (though it's hard for me to be otherwise, given that I makes games for a living and don't do embedded work, though I could get some input from friends who've worked in both camps)."

Finally, I think one of the reason Nicholas asked the question about current C++ Games Dev/programming books is a suggestion we had about using this group to potentially write the next C++ Games Programming book. Before we do that, we would like to know what is the current status. A possible collaboration in future with multiple authors writing one chapter of a collected work would certainly be possible.

Thanks.

Other thoughts?

[Scott Wardle]

I liked CPPCON because I got to interact with people from other domains in c++.  But I wonder what is best for this group. 

The jet brains guys posted this on reddit the link below. Finance, and banking (then games) are the biggest users of C++. So I worry about finance being included as there is not many game devs working on the standard yet we might get swamped by people that know the system better then we do. 

http://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/

If this is right then finance is much bigger in c++ than I thought. 

While I feel game people care about speed I think everyone using c++ cares about speed to some degree. I also care about the debug-ability of a very large cross platform application. I'd like to see us address debug ability issues with inline functions and STL for example. We have tied the library writers hands in knots it would be nice if the code was easy to read if we have to read it over and over as we debug. What group is taking care of these kinds of issues? 

Scott Wardle

--
You received this message because you are subscribed to the Google Groups "SG14 - Game Dev and Low Latency" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sg14+uns...@isocpp.org.
To post to this group, send email to sg...@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/sg14/.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/sg14/cfe0d1da-005b-4664-b545-cb73af968431%40isocpp.org.

[michaelw]

Indeed the main theme is efficiency and performance as Brent said. I might add latency as well. This is in some form a main theme of many things in C++, or the "Don't pay for it unless you need it" mantra. But C++ kind of broke that with exception handling. I can make inquiries whether rtti and EH are used extensively in finance and banking. I think they are also not used. This is why there is massive interest in reflection. 

To some degree SG1's Parallelism and Concurrency and SG5's Transactional Memory are also focused on efficiency and performance. But they are also interested in enabling functionality, the ability to address multiple threads (parallelism) and communicate between them (concurrency), or the ability to be race-free (transactional memory and SG1) and be composable (Transactional Memory).

The overlap is there, but we are definitely more focused on improving performance (there used to be a Performance TR 10 years ago which now has lapsed), latency, and efficiency; but it does not mean we cannot add functionality to do so in the manner of intrusive containers, or even a full offload accelerator model.

I think if Finance/Banking/Games all have a Common Interest in Performance, Efficiency and Latency, this forms a very nice coming together of interest and would seek their view out on this.

On Wednesday, August 5, 2015 at 4:31:50 AM UTC-4, Scott Wardle wrote:

I liked CPPCON because I got to interact with people from other domains in c++.  But I wonder what is best for this group. 

The jet brains guys posted this on reddit the link below. Finance, and banking (then games) are the biggest users of C++. So I worry about finance being included as there is not many game devs working on the standard yet we might get swamped by people that know the system better then we do. 

http://blog.jetbrains.com/clion/2015/07/infographics-cpp-facts-before-clion/

If this is right then finance is much bigger in c++ than I thought. 

While I feel game people care about speed I think everyone using c++ cares about speed to some degree. I also care about the debug-ability of a very large cross platform application. I'd like to see us address debug ability issues with inline functions and STL for example. We have tied the library writers hands in knots it would be nice if the code was easy to read if we have to read it over and over as we debug. What group is taking care of these kinds of issues? 

Good point. No group I know of as yet. I know STL implementations are hard to debug, but that is driven by the separation of interface and implementation. Everyone have their own helper classes and internal structures. I think that might definitely bloat our mandate but we can make inquiries.

[Sean Middleditch]

On Wed, Aug 5, 2015 at 9:29 AM, michaelw <mich...@ca.ibm.com> wrote:
> On Wednesday, August 5, 2015 at 4:31:50 AM UTC-4, Scott Wardle wrote:
>> While I feel game people care about speed I think everyone using c++ cares
>> about speed to some degree. I also care about the debug-ability of a very
>> large cross platform application. I'd like to see us address debug ability
>> issues with inline functions and STL for example. We have tied the library
>> writers hands in knots it would be nice if the code was easy to read if we
>> have to read it over and over as we debug. What group is taking care of
>> these kinds of issues?
>
>
> Good point. No group I know of as yet. I know STL implementations are hard
> to debug, but that is driven by the separation of interface and
> implementation. Everyone have their own helper classes and internal
> structures. I think that might definitely bloat our mandate but we can make
> inquiries.

Do recall that debuggability is one of the reasons that EASTL came
about. It remains /one/ of the reasons that so many game engines and
companies eschew the STL (or large parts of it) and just write their
own containers and algorithms.

Which leads to a worry of mine: that we do a bunch of work to get new
containers into the STL and then much of our target audiences don't
actually use them because home grown versions are "better" in some
(important) regards than the vendors' implementations. That is already
a problem that Boost suffers from.

There's also the abstraction penalty which C++ has and which vendors'
STL implementations tend to exasperate.

> https://groups.google.com/a/isocpp.org/d/msgid/sg14/d2e6b426-883f-4303-b023-e84448282f4e%40isocpp.org.



--
Sean Middleditch
http://seanmiddleditch.com

[Brian Ehlert]

Michael,

I'm curious what you think the scope and goals should be. Since you have experience with the committee, how do you think this study group could be use most efficiently?

If the goal is to improve areas of C++ which are pain points for game developers, wouldn't it be more effective to present those issues to the committee (similar to EASTL's paper) rather than try to come up with solutions on our own? Game developers specialize in areas of game development (surprise!), and generally speaking are not specialists in the language, compilers, or the library. While a compiler or STL writer may know off the top of their head how all the pieces fit together, for an average person (read: non-committee member) to write a proposal could be a very time-consuming task.

It seemed like the original intention was to meet at GDC and CppCon since game developers don't attend committee meetings. Now the intention seems to be to write proposals and present them in front of the committee, which I fear will end up coming full circle with everyone backing out due to the time (and travel) required for all of this.

There does not seem to be one main "feature" this SG is pushing towards, but rather just represents interests of a subset of C++ users. So I'd like to know your thoughts on how this group could be used.

- Brian

[Billy Baker]

Brian,

Without proposals, we can't change anything. Some proposals are very time consuming. You can see that in the ranges proposal and the networking proposal. There have also been very small proposals. After CppCon last year, I wrote a quick "remove auto_ptr" proposal without the knowledge that STL was writing a slightly larger proposal to remove more of the deprecated items.

First papers don't necessarily have to provide a solution. There has to be the 'what' and the 'why' first. If there is a 'how' (possibly incomplete) as well, great. The SG can provide support getting the proposals going and making sure common issues brought up by the committee are addressed before inclusion in a committee mailing. From there, proposals from this group would most likely go to the Library Evolution Working Group where more experts than just the SG will get a chance to provide input. It is also possible that a topic of concern to the participants of the SG may need to go through another SG such as numerics. Once a proposal has an initial review, an iterative process could then proceed to include the 'how' if it is not already there with continued feedback from the SG and committee. At some point, there really does need to be the 'how' as the question is often asked if there is an implementation for proposals that try to address issues that may not be well-known to a large portion of the committee.

The SG doesn't have to be a one-way path from SG participants to the committee, either. Changes to the standard that may not be known to the participants that could help them write good C++ can also flow the other direction.

While it would be nice to have the author present at a committee meeting, there is the possibility of finding a champion for a proposal that has been involved in the SG, understands the topic, and attends committee meetings regularly. At CppCon, game developers and other non-committee members will have plenty of face-to-face time with committee members other than Michael.

Billy