Paper for Lenexa mailing due April 10

[Michael Wong]

HI all, I have been negligent (due to my other papers in flight for the same mailing deadline) in identifying when the mailing deadline is for the next C++ Standard meeting in Lenexa. It is actually tomorrow, Friday April 10. In reality, they usually give us a bit of grace period such that we can still submit something Monday April 13.

As such I took upon myself to look through some of the emails and pick out (mostly from Sean's email) enough information (which I think we have) to create a paper to be submitted. If you like to add more to this paper, please respond. I will try to help guide this forward if people want to submit our findings so far as a paper. If you do not want me to submit, I am find with that too. Here is the paper, please let me know if you want to add to it. If enough people want to edit together, I will even put it on as a Google doc so everyone can work on it this weekend.

Sorry for the late notice, but you would be surprised how many last minute paper are cobbled together as everyone has a full time day job.

Thanks.

[Nicolas Guillemot]

It might also be interesting to comment on more existing proposals from the perspective of gaming/realtime programming. Here are some proposals that I think are of interest.

* Standard SIMD types (N3759).
As explained in Michael's document, making the language aware of their existence would solve lots of alignment problems.

* Static reflection (N3996).

In my experience, games tend to use a ton of enums (often auto-generated by tools) to communicate between systems. Being able to iterate over enums or automatically convert them to strings would be helpful for writing debuggers, loggers, profilers..

Furthermore, this could make it possible to automatically convert data structures between SoA (Struct of Array) and AoS (Array of Struct), which would make it a lot easier to experiment and find which layouts of memory have optimal memory access patterns. It would be way more interesting to use std algorithms if they allowed writing layout-agnostic code to use with SoA/AoS. Such a feature would be even better if possible to use for SIMD types, ie. being able to easily change your data from xyzw xyzw xyzw xyzw to xxxx yyyy zzzz wwww.

The importance of design considerations with SIMD was highlighted in a GDC talk this year (https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf), and from reading the slides you can see that one of the only viable options for these game developers is still just to use intrinsics, which could definitely use cleaning up from a language perspective.

--
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/aa7cd139-90de-4317-90de-b4eb1d1d540a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Michael Wong]

This (identifying papers that are of interest for this group) should certainly be an additional section of the paper.

On Thursday, April 9, 2015 at 9:27:45 PM UTC-4, Nicolas Guillemot wrote:

It might also be interesting to comment on more existing proposals from the perspective of gaming/realtime programming. Here are some proposals that I think are of interest.

* Standard SIMD types (N3759).
As explained in Michael's document, making the language aware of their existence would solve lots of alignment problems.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3759.html
I didn't find any record that this was discussed, most likely because the author was not there. Let me check with the author.
SIMD type has taken a slightly new direction in the last meeting. Please see this

N4237	Language Extensions for Vector loop level parallelism	R. Geva, C. Nelson	2014-10-10	2014-10		Concurrency
N4238	An Abstract Model of Vector Parallelism	Pablo Halpern	2014-10-13	2014-10		Concurrency

* Static reflection (N3996).

In my experience, games tend to use a ton of enums (often auto-generated by tools) to communicate between systems. Being able to iterate over enums or automatically convert them to strings would be helpful for writing debuggers, loggers, profilers..

https://isocpp.org/files/papers/n3996.pdf

Furthermore, this could make it possible to automatically convert data structures between SoA (Struct of Array) and AoS (Array of Struct), which would make it a lot easier to experiment and find which layouts of memory have optimal memory access patterns. It would be way more interesting to use std algorithms if they allowed writing layout-agnostic code to use with SoA/AoS. Such a feature would be even better if possible to use for SIMD types, ie. being able to easily change your data from xyzw xyzw xyzw xyzw to xxxx yyyy zzzz wwww.

The importance of design considerations with SIMD was highlighted in a GDC talk this year (https://deplinenoise.files.wordpress.com/2015/03/gdc2015_afredriksson_simd.pdf), and from reading the slides you can see that one of the only viable options for these game developers is still just to use intrinsics, which could definitely use cleaning up from a language perspective.

 I will read through this.
If you like to modify the document with words similar to this, please go ahead. I will probably not get back to this until Saturday. Thanks.

On Thu, Apr 9, 2015 at 2:58 PM, Michael Wong <fragga...@gmail.com> wrote:

HI all, I have been negligent (due to my other papers in flight for the same mailing deadline) in identifying when the mailing deadline is for the next C++ Standard meeting in Lenexa. It is actually tomorrow, Friday April 10. In reality, they usually give us a bit of grace period such that we can still submit something Monday April 13.

As such I took upon myself to look through some of the emails and pick out (mostly from Sean's email) enough information (which I think we have) to create a paper to be submitted. If you like to add more to this paper, please respond. I will try to help guide this forward if people want to submit our findings so far as a paper. If you do not want me to submit, I am find with that too. Here is the paper, please let me know if you want to add to it. If enough people want to edit together, I will even put it on as a Google doc so everyone can work on it this weekend.

Sorry for the late notice, but you would be surprised how many last minute paper are cobbled together as everyone has a full time day job.

Thanks.

--
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-time-cxx+unsub...@googlegroups.com.

[Michael Wong]

HI all, I have done another pass over the paper, added the last comment from Nicolas, and the paper number. Reformatted things a bit more. I am still missing an Abstract and a Motivation section. If someone would liek to contribute the Motivation that would help, otherwise I will put something together.

Next is if anyone also would like to be added as co-author of the paper, I am happy to add their names. Otherwise, I would add the whole group to the acknowledgement section.

[Nicolas Guillemot]

Hi Michael,

Thanks for updating the document!
Could you host it as a google doc? I started doing some work on it, but it's hard to merge changes with this workflow.

--
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/af7782e3-d644-47be-be7e-3e8675604a3a%40googlegroups.com.

[Nicolas Guillemot]

(Sorry for double post)

It might also be interesting to mention some other points that were brought up in the discussion group. Maybe this paper should be limited in scope to not overwhelm those who read it... but FWIW, I went over more e-mails in the discussion group and formed a list of discussion points I didn't notice in the current document:

* Game developers don't like global new/delete. (Point brought up by Scott Wardle)
    - No alignment, no tracking of file/function/line for debugging (especially a problem for tracking middleware allocations). Solutions exist, but unsightly.

    - Everybody wraps new/delete in unsightly macros because of the last points. The macros are unsightly because operator new has unorthodox syntax, especially new[].

    - Game developers want separate memory budgets for every subsystem, so there's no such thing as a "global" new. I guess HPC people probably also ditch global new in favor of NUMA-aware allocators.

* Can't really do thread pools right in plain C++11 because good thread pool implementations need to be able to do tricky/interesting hacks to reduce scheduling latency. (Paraphrasing Scott Wardle)

* Concerned about std::function/lambdas doing allocations (Point brought up by Scott Wardle)

    - I've heard of other game developers also cautiously doing measurements on std::function/lambdas to see how much you can do with them without them resorting to dynamic allocations.

* Concerned about variant proposals resorting to RTTI. RTTI is verboten for game developers and dynamic dispatch is not ideal, so this variant would be a write-off. Better implementations are possible. (See Sean Middleditch's post)

* Would be great to be able to get vtable pointers as global objects without requiring an existing reference to the object. (See Nicolas Fleury's post for a proposal)

    - Maybe also interesting to think of how it could be possible to customize the way virtual functions work as a library solution? (See the discussion in Nicolas Fleury's post)

[Michael Wong]

Sorry I just saw this now. We won't have time for a a google doc now as I need to submit it MOnday. I think for any follow-up document, we can use the google doc strategy.

On Sunday, April 12, 2015 at 11:00:44 AM UTC-4, Nicolas Guillemot wrote:

Hi Michael,

Thanks for updating the document!
Could you host it as a google doc? I started doing some work on it, but it's hard to merge changes with this workflow.

On Sun, Apr 12, 2015 at 7:55 AM, Michael Wong <fragga...@gmail.com> wrote:

HI all, I have done another pass over the paper, added the last comment from Nicolas, and the paper number. Reformatted things a bit more. I am still missing an Abstract and a Motivation section. If someone would liek to contribute the Motivation that would help, otherwise I will put something together.

Next is if anyone also would like to be added as co-author of the paper, I am happy to add their names. Otherwise, I would add the whole group to the acknowledgement section.

On Thursday, April 9, 2015 at 5:58:27 PM UTC-4, Michael Wong wrote:

HI all, I have been negligent (due to my other papers in flight for the same mailing deadline) in identifying when the mailing deadline is for the next C++ Standard meeting in Lenexa. It is actually tomorrow, Friday April 10. In reality, they usually give us a bit of grace period such that we can still submit something Monday April 13.

As such I took upon myself to look through some of the emails and pick out (mostly from Sean's email) enough information (which I think we have) to create a paper to be submitted. If you like to add more to this paper, please respond. I will try to help guide this forward if people want to submit our findings so far as a paper. If you do not want me to submit, I am find with that too. Here is the paper, please let me know if you want to add to it. If enough people want to edit together, I will even put it on as a Google doc so everyone can work on it this weekend.

Sorry for the late notice, but you would be surprised how many last minute paper are cobbled together as everyone has a full time day job.

Thanks.

--
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-time-cxx+unsub...@googlegroups.com.

To post to this group, send email to unofficial-r...@googlegroups.com.

[Michael Wong]

No problem. Thanks for the additional summary. I added it too. Here is the final document which I will post in a few hours if there are no objections.

To unsubscribe from this group and stop receiving emails from it, send an email to unofficial-real-time-cxx+unsub...@googlegroups.com.

To post to this group, send email to unofficial-r...@googlegroups.com.

[Michael Wong]

OK I have submitted. Sorry for a bit of a rush job, but I wanted to capture the ongoing work this group has done and use it to form a basis for further discussions.

Thanks.

[Sean Middleditch]

Thank you Michael for this work putting the document together. We are
all of course very eager to see what comes of it after Lenexa.

I still have a small stack of items I didn't have a chance to get to
for this round of papers; I did want to actually get an initial
flat_map proposal in, for instance. It might be useful to hear what
feedback the committee has on those items, if for no other reason than
to know what counter-arguments to put into such a paper.

There are - as N4456 notes - some items needing further investigation
or benchmarking. There's some folk wisdom in the industry that might
have become invalid with modern C++ implementations. Item 4 in the
paper, for instance; I've definitely seen vast measurable improvements
with some simplification of deep call hierachiries in compiler member
functions, but I don't have a nice publicly-shareable reproduceable
benchmark. Nor do I have measurements across a wide breadth of
compilers. This is not something I am likely to get around to
correcting, so there's room for a hero to step in and help out. :)

Again, thank you Michael!

-Sean


p.s. I am slightly chagrined and am hoping that a quote from me is not
the very first time the word "crap" has shown up in a paper submitted
to the committee... but that's what I get for being unavailable during
editing, I suppose. :)

>>>>> 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/af7782e3-d644-47be-be7e-3e8675604a3a%40googlegroups.com.
>>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>

> --
> 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/a6c470f7-716d-4742-bcd9-3c049d6698b1%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.

--
Sean Middleditch
http://seanmiddleditch.com

[Michael Wong]

No problem Sean, I understand deadlines and urgencies as I have a ton of them.

The way I see it, I am just serving my duties as the C++ Std Head of Delegation for Canada as many game companies are from here anyway.

I have now shared the google doc with both you and Nicolas so you can start editing or adding to it in preparation for the next mailing.

For what its worth, the next meeting will be in Kona Hawaii Oct 19-23rd.

As if you need a good reason to attend the meeting :) This means the next paper deadline is around Mid-Sept

On Wed, Apr 15, 2015 at 1:20 AM, Sean Middleditch <se...@middleditch.us> wrote:

Thank you Michael for this work putting the document together. We are
all of course very eager to see what comes of it after Lenexa.

I still have a small stack of items I didn't have a chance to get to
for this round of papers; I did want to actually get an initial
flat_map proposal in, for instance. It might be useful to hear what
feedback the committee has on those items, if for no other reason than
to know what counter-arguments to put into such a paper.

Right, it may be best to start by preparing some slides describing that (flat_map) proposal especially if I am the only at the meeting (likely as I don't think anyone of this group is coming) to get that feedback in preparation for the paper.

There are - as N4456 notes - some items needing further investigation
or benchmarking. There's some folk wisdom in the industry that might
have become invalid with modern C++ implementations. Item 4 in the
paper, for instance; I've definitely seen vast measurable improvements
with some simplification of deep call hierachiries in compiler member
functions, but I don't have a nice publicly-shareable reproduceable
benchmark. Nor do I have measurements across a wide breadth of
compilers. This is not something I am likely to get around to
correcting, so there's room for a hero to step in and help out. :)

Yes, I wanted to use the document as a basis to build additional info/investigation (after some discussion on this reflector) as they become ready.
 

Again, thank you Michael!

-Sean


p.s. I am slightly chagrined and am hoping that a quote from me is not
the very first time the word "crap" has shown up in a paper submitted
to the committee... but that's what I get for being unavailable during
editing, I suppose. :)

No worries. I have seen worst. I tried to sanitize the words, but some probably escaped my notice.

So I would say the next step is prepare a  few talk slides on google docs for the presentation to the Evolution or Embedded group depending on where you think we should go. The deadline for that is just before the meeting which is May 4th. I am travelling next week for a keynote at Parallel 2015.

I personally prefer to go before Evolution first myself and get a mandate. But things might change depending on what occurs in the paper triage meeting which happens in about 2 weeks where I will represent us.

[Michael Wong]

An update on the SIMD paper N3759

On Fri, Apr 10, 2015 at 9:41 AM, Michael Wong <fragga...@gmail.com> wrote:

This (identifying papers that are of interest for this group) should certainly be an additional section of the paper.

On Thursday, April 9, 2015 at 9:27:45 PM UTC-4, Nicolas Guillemot wrote:

It might also be interesting to comment on more existing proposals from the perspective of gaming/realtime programming. Here are some proposals that I think are of interest.

* Standard SIMD types (N3759).
As explained in Michael's document, making the language aware of their existence would solve lots of alignment problems.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3759.html
I didn't find any record that this was discussed, most likely because the author was not there. Let me check with the author.

Ok, this paper was reviewed  in Sg1 and it was positive and considered as a serious alternative or complement in addition to the simd loop proposals below.

The author has made follow up papers:
N4454, N4395,
N4185, N4184.

So this should be the latest revision:
http://open-std.org/JTC1/SC22/WG21/docs/papers/2015/n4454.pdf

[Nicolas Guillemot]

Thanks Michael, it's so awesome to have an official Nxxxx C++ paper in this group's name!
I'll put some time into the google doc in the evening this week or during the weekend.

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/CAAUWkG9CuA%2BSVOYiEZbSB5TsHGC-HHXk-n4UyB0K5car3qmMEA%40mail.gmail.com.

[Michael Wong]

It feels good to get something down in writing too. Thanks for your help and feedback this last weekend.

Folks, you can see it is posted here under 2015 04 mailing
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/

Note that we can still make minor updates to the paper and replace it with the final version at the meeting. This mailing is just a way to allow people time to prepare by pre-reading before the meeting.

When I get to the meeting, I will post an updated draft which will become a new paper post meeting based on what we do here for the next 3 weeks.

Now we will need to get some slides together.

[Sean Middleditch]

I just did a quick formatting pass, as it was difficult to tell which bits were quotes from the EASTL paper and which were quotes from us. It also looked like the import to Google Docs mucked up a bit of the formatting. I'll take another pass at it in a bit after I finish unwinding from work. :)

To view this discussion on the web visit https://groups.google.com/d/msgid/unofficial-real-time-cxx/CAAUWkG9iKkwo2Quaupqu7-uuSAiVRxYqY6_Yk%3D-0aHgfs5hsJA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Sean Middleditch
http://seanmiddleditch.com

[Billy Baker]

Even though I have been rather silent, the group will have additional representation at the committee meetings.

I am looking forward to the flat_map proposal.

Billy

>>>>> an email to unofficial-real-time-cxx+unsub...@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/af7782e3-d644-47be-be7e-3e8675604a3a%40googlegroups.com.
>>>>>
>>>>> For more options, visit https://groups.google.com/d/optout.
>>>>
>>>>
>>>
> --
> 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-time-cxx+unsub...@googlegroups.com.

> To post to this group, send email to

[Sean Middleditch]

Nicolas pointed out the measurements at
http://tinodidriksen.com/2010/04/14/cpp-dynamic-cast-performance/ on
another site. They're on older implementations, but it may still be
worthwhile to include some of that in the slidedeck.

Michael, I don't have a clear idea in my head what kind of content the
slide deck should have, or what primary topics/points it should go
over. Any tips?

>>> >>>>> 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/af7782e3-d644-47be-be7e-3e8675604a3a%40googlegroups.com.
>>> >>>>>
>>> >>>>> For more options, visit https://groups.google.com/d/optout.
>>> >>>>
>>> >>>>
>>> >>>
>>> > --
>>> > 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/a6c470f7-716d-4742-bcd9-3c049d6698b1%40googlegroups.com.
>>> >
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>> --
>>> Sean Middleditch
>>> http://seanmiddleditch.com
>>
>>

> --
> 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/ed57f413-c04b-4306-b109-146f268c3f40%40googlegroups.com.

[Nicolas Guillemot]

Just finished an editing pass over the google doc.

[Sean Middleditch]

Lookin' good.

Still would like some ideas as to what to put in a slide deck that isn't just a rehash of the contents of the paper itself. Even just a sample slide deck from another old paper that was considered well done; I've done a lot of slide decks for talks but nothing for a standard committee.

Unless again it'd just be a big slide that said "we need control over what the compiler does" followed by a second one saying "and we need guarantees most implementation details in the stdlib."  :)

To view this discussion on the web visit https://groups.google.com/d/msgid/unofficial-real-time-cxx/CAFcDmHO64HyvkLJk_Wp%3DUq72gdp6Wv2sF73Ex3otaehpJFyVLg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Scott Wardle]

Not sure what the standard committee would want. 

But I feel that the paper is trying describe the problem of game programming to c++ community. I think if they understood the problem better then a lot of good would come from that.  

Why is it important to override allocators and how would we do it.  I wish I could talk more about the tools we use to associate names and assets with memory. Telling an artist he's out of memory doesn't really help him. You need to tell him this lamp takes up that much space this rock takes up that much space.  When you make a street with 4 lamp and 10 rocks it is this big.  How do you do that when your object are made out of of stl objects with call backs for logic and hash tables of meshes and textures. Gigabytes of memory means millions of objects.  And these object are allocated in the same way so saying i just use call stacks does not help my poor artist trying to add more lamp posts. Soon you are associating strings with each memory allocation or some other data.  Smart pointers just me now you have to track you references and your memory blocks.  Add in streaming and explosions and finding your worse memory use is hard and fragmentation a constant problem. 

I wish I could show about the cool tools we have. I don't think I could. Maybe you can. 

Looks like I wrote a small book sorry for the wall of text. 

Scott Wardle スコット・ワードル

To view this discussion on the web visit https://groups.google.com/d/msgid/unofficial-real-time-cxx/CALQmNFiyVTY5EkvpXw%2BjyJTy9p7Cn6jJj%3DkLnJStHWpWeWJ%2B-g%40mail.gmail.com.

[Michael Wong]

Hi all I can tap back in now having just finished my keynote here in Karlsruhe.

Scott is right, this approach at this time should be just to show what is wrong and nothing more. The committee might come up with some of the solutions too and we can evaluate them but that is probably reaching.

There is nothing wrong with the slides being a rehash of the paper. Afterall, the paper is essentially the slides but with longer explaination. In most cases, people are looking for your slide to give them the condensed view as not everyone will have read the paper (since there are about 40 papers totally about 2000 pages). No one can actually read all that if they have a full time job. The point of writing the paper is actually to make the slide easier because we have already well thought out words.

I would say 90% of slides presented are a rehash of the paper.

Of course, the slide can also be very different (not really preferred) , or just mildly different, with added, changed, corrected content.

For the committee, code examples are paramount.

Here is one I did to talk about transactionalizing STL at the committee to support the paper:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3862.pdf

The paper has wording but I did not put that in the slide because it was still too early.
 The slide is mostly an update of what we have done, with context as to what has passed vote (because there might be new people in the room) and what guidance I am looking for (do we want a vote or not and what kind of vote).

Honestly most of the time, I prepare the slide on the flight over due to my time constraint by just grabing code sections and key phrases from the paper . This is why writing the paper is important because if I loose the words, I just memorize the argument in the paper. The rest I just talk my way out along the way. Some people even show just the paper on the screen.Its that informal.

Finally nice job on the editing. Sorry I have not been able to help as I was in Germany this whole week.

[Michael Wong]

Some more thoughts after reading more. There should be something in the slide that tells the committe  how much C++ is used in Games.
Then we can open and close withe the "ideals" statement Sean have. Then do a few deep dive examples.

Our goal here is probably: Get as a SG or pair us with someone to address these issues.
The committee might come back with: these do not have coherence enough for an SG. Why don't you just submit your problems and solutions in pieces.

Flying out soon, so just thoughts as I have them ...

To unsubscribe from this group and stop receiving emails from it, send an email to unofficial-real-time-cxx+unsubscr...@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/aa7cd139-90de-4317-90de-b4eb1d1d540a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-time-cxx+unsub...@googlegroups.com.

To post to this group, send email to unofficial-real-time-cxx@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/unofficial-real-time-cxx/CAAUWkG9CuA%2BSVOYiEZbSB5TsHGC-HHXk-n4UyB0K5car3qmMEA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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-time-cxx+unsub...@googlegroups.com.

To post to this group, send email to unofficial-real-time-cxx@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/unofficial-real-time-cxx/CAAUWkG9iKkwo2Quaupqu7-uuSAiVRxYqY6_Yk%3D-0aHgfs5hsJA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Sean Middleditch
http://seanmiddleditch.com

--
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-time-cxx+unsub...@googlegroups.com.

To post to this group, send email to unofficial-real-time-cxx@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/unofficial-real-time-cxx/CAFcDmHO64HyvkLJk_Wp%3DUq72gdp6Wv2sF73Ex3otaehpJFyVLg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Sean Middleditch
http://seanmiddleditch.com

--
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-time-cxx+unsub...@googlegroups.com.

To post to this group, send email to unofficial-real-time-cxx@googlegroups.com.

[Paul Pedriana]

(I just joined this group so I can send this to the group proper)

    >> There should be something in the slide that tells the committee how much C++ is used in Games.

C++ is used almost universally in games on platforms which freely support C++. The vast majority of serious games written for desktop platforms (Windows, Mac OS, Linux), console platforms (PS4, XBox, Wii), and hand-held platforms (3DS, Shield) are in C++. Even C is almost unheard of in game development.

Nearly all game engines are written in C++, though some of them expose a non-C++ scripting interface to the engine user (e.g. Unity is written in C++ but exposes a .Net interface). Game engines written in C++ include all the major game engines, such as Unreal Engine, Unity, Frostbite, Source Engine, Havok, Ogre, etc.

On Android C++ is available only in native mode development, which is somewhat tedious to use. As a result, only highly performance-sensitive games tend to be developed in C++ on Android. iOS supports both Objective C and C++, but any application is effectively forced into using at least some Objective C in order to interface with the OS. iOS games tend to be written in Objective C or a mix of Objective C and C++.

Paul Pedriana

 

 

From: Michael Wong [mailto:fragga...@gmail.com]

Sent: Thursday, April 23, 2015 11:00 PM

To: unofficial-r...@googlegroups.com

Cc: Paul Pedriana; nlgui...@gmail.com; swa...@gmail.com; se...@middleditch.us

Subject: Re: Paper for Lenexa mailing due April 10

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/aa7cd139-90de-4317-90de-b4eb1d1d540a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

 

--

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/CAAUWkG9CuA%2BSVOYiEZbSB5TsHGC-HHXk-n4UyB0K5car3qmMEA%40mail.gmail.com.

 

For more options, visit https://groups.google.com/d/optout.

 

 

--

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/CAAUWkG9iKkwo2Quaupqu7-uuSAiVRxYqY6_Yk%3D-0aHgfs5hsJA%40mail.gmail.com.

 

For more options, visit https://groups.google.com/d/optout.

 

 

 

 

--

Sean Middleditch

http://seanmiddleditch.com

 

--

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/CAFcDmHO64HyvkLJk_Wp%3DUq72gdp6Wv2sF73Ex3otaehpJFyVLg%40mail.gmail.com.

 

For more options, visit https://groups.google.com/d/optout.

 

--

Sean Middleditch

http://seanmiddleditch.com

--

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/CALQmNFiyVTY5EkvpXw%2BjyJTy9p7Cn6jJj%3DkLnJStHWpWeWJ%2B-g%40mail.gmail.com.

[Sean Middleditch]

Initial slides ready for commenting and finishing:

https://docs.google.com/presentation/d/1JxXJkMUSdc6Q_NlPcEJVbAqgmNgnDi40wBr-humX2KM/edit?usp=sharing

I'm sending out edit links to Michael and Nicolas momentarily; can open it up a bit if everyone thinks that's a better idea.

[Michael Wong]

Thanks, this can be used. Is there a dollar figure? even an estimate, how about what it will be projected to  grow to in 2 years by C++17, or 5 years.
Is there any threat from any other language taking over this dominance ?

To unsubscribe from this group and stop receiving emails from it, send an email to unofficial-real-time-cxx+unsub...@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/aa7cd139-90de-4317-90de-b4eb1d1d540a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

 

 

--

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-time-cxx+unsub...@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/CAAUWkG9CuA%2BSVOYiEZbSB5TsHGC-HHXk-n4UyB0K5car3qmMEA%40mail.gmail.com.

 

For more options, visit https://groups.google.com/d/optout.

 

 

--

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-time-cxx+unsub...@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/CAAUWkG9iKkwo2Quaupqu7-uuSAiVRxYqY6_Yk%3D-0aHgfs5hsJA%40mail.gmail.com.

 

For more options, visit https://groups.google.com/d/optout.

 

 

 

 

--

Sean Middleditch

http://seanmiddleditch.com

 

--

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-time-cxx+unsub...@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/CAFcDmHO64HyvkLJk_Wp%3DUq72gdp6Wv2sF73Ex3otaehpJFyVLg%40mail.gmail.com.

 

For more options, visit https://groups.google.com/d/optout.

 

--

Sean Middleditch

http://seanmiddleditch.com

--

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-time-cxx+unsub...@googlegroups.com.

[Michael Wong]

Thanks for doing this. I looks GREAT. I just got back home and will do some work on it too.

[Michael Wong]

IT looks Great.

[Michael Wong]

Hi all, I have updated the slides with some summary items and suggestions. I am to present to Evolution  WG on Saturday around 11am CT (in Kansas city area). Thanks for all the collaborated work!

While presenting to Evolution is a good first step, I really want to present the paper  (especially the STL changes) to Library evolution. However, Library Evolution is busy this week with Executors, and all the TSs (including my Transactional Memory TS) trying to get passage so we might not be able to get on their schedule. This might mean we will have to come back to them in Kona Hawaii's meeting. Oh well, such is life.

[Michael Wong]

I just reread this post and it really made me understand why memory tracking is important. Thanks. Scott.

To unsubscribe from this group and stop receiving emails from it, send an email to unofficial-real-time-cxx+unsubscr...@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/aa7cd139-90de-4317-90de-b4eb1d1d540a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-time-cxx+unsub...@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/CAAUWkG9CuA%2BSVOYiEZbSB5TsHGC-HHXk-n4UyB0K5car3qmMEA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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-time-cxx+unsub...@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/CAAUWkG9iKkwo2Quaupqu7-uuSAiVRxYqY6_Yk%3D-0aHgfs5hsJA%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Sean Middleditch
http://seanmiddleditch.com

--
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-time-cxx+unsub...@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/CAFcDmHO64HyvkLJk_Wp%3DUq72gdp6Wv2sF73Ex3otaehpJFyVLg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Sean Middleditch
http://seanmiddleditch.com

--
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-time-cxx+unsub...@googlegroups.com.
To post to this group, send email to unofficial-r...@googlegroups.com.