Jan 29 SG5 TM Telecon

[Michael Wong]

HI all here is the agenda for today's SG5 TM call where Piotr Balcer of Intel will call in to discuss persistent memory.

Piotr, thank you for calling in as we discussed on SG14. There is a small chance this may get cancelled and moved to the next call in 2 weeks. If so, there will be a note to alert you of that. Thank you for calling in.

Start Time: Monday, Jan 29 2018, 12:00 PM US Pacific Time (07:00 PM in GMT) 
End Time: 1:00 PM US Pacific Time (duration: one  hour)

Toll-free Dial-in number: +1(866)682-4770 
Local US number: +1(408)774-4073 
Local Germany number: +49 89 1430 2323 
(Let me know if you need a local number for a different country.)

Conference code: 8918244 
Security passcode: 1234

With large numbers of participants, audio interference can be a problem. Please try to keep 
your phone muted whenever possible. If your phone does not have a mute 
button, the bridge will mute or un-mute your line if you dial *6.

The current secretary rota list is (the person who took notes at the 
last meeting is moved to the end)

    Maged,Michael Scott,Michael Spear,Jens, Victor,Michael W,
Hans,

Agenda:

1. Opening and introductions

1.1 Roll call of participants

1.2 Adopt agenda

1.3 Approve minutes from previous meeting, and approve publishing  previously approved minutes to ISOCPP.org

1.4 Review action items from previous meeting (5 min)

1.5 Call schedules (please add your away days)

Dec 4 this call, Michael in Santa Clara
Dec 18: Michael away
Jan 1: cancel
Jan 15 MLK day, Michael away
Jan 29: Michael away
Feb 12 : mailing deadline is 10 am ET today
Feb 26: Michael Scott away
March 12 C++ Meeting JAX

2. Main issues (50 min)

2.1 Persistent memory by piotr....@intel.com

2.2: Interaction with Executors and Synchonized proposal

https://groups.google.com/a/isocpp.org/forum/#!topic/tm/jG9XPJetNkc

The last discussion has us considering an alternative lambda form.

See Paper emailed out on Lambda proposal

https://docs.google.com/document/d/1ICmcrCdigq3ataoM2Jl7m19h_Sa3aE3KfU6AVkPyT-4/edit#

2.3  Future of TM Discussion with Herb

Herb, if you like to send any pre-call material or discussion, please go ahead.

2.4 future issues list:

1. llvm synrhonized blocks
2. more smart ptrs?how fast can atomics and smart ptrs be outside tx if they have to interact with tx (for world that does not care about tx), the atomic nature of smart ptrs as a way towards atomics inside atomic blocks 
3. more papers?
4. Issue 1-4 paper updates to current TM spec
5. std library

2.4 Discuss defects if any work done since last call
Issue 1: https://groups.google.com/a/isocpp.org/forum/#!topic/tm/SMVEiVLbdig
Issue 2: https://groups.google.com/a/isocpp.org/forum/#!topic/tm/Th7IFxFuIYo
Issue 3:https://groups.google.com/a/isocpp.org/forum/#!topic/tm/CXBycK3kgo0
Issue 4: https://groups.google.com/a/isocpp.org/forum/#!topic/tm/Ood8sP1jbCQ

3. Any other business

4. Review

4.1 Review and approve resolutions and issues [e.g., changes to SG's working draft] 
N4513 is the official working draft (these links may not be active yet until ISO posts these documents) 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4513.pdf

N4514 is the published PDTS: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4514.pdf

N4515 is the Editor's report: 
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4514.html

Github is where the latest repository is (I have updated for latest PDTS published draft from post-Leneaxa): 
https://github.com/cplusplus/transactional-memory-ts

Bugzilla for filing bugs against TS: 
https://issues.isocpp.org/describecomponents.cgi

4.2 Future backlog discussions:

4.2.1 Write up guidance for TM compatibility for when TM is included in C++ standard (SG5)

4.2.2 Continue Retry discussion 
https://groups.google.com/a/isocpp.org/forum/?hl=en&fromgroups#!topic/tm/qB1Ib__PFfc 
https://groups.google.com/a/isocpp.org/forum/#!topic/tm/7JsuXIH4Z_A

4.2.3 Issue 3 follow-up

Jens to follow up to see if anything needs to be done for Issue 3.

4.2.5 Future C++ Std meetings:

2018 03-12 JAX C++ Std meeting

4.3 Review action items (5 min)

5. Closing process

5.1 Establish next agenda

5.2 Future meeting 
Next call: Feb 12

[Michael Wong]

Hi Piotr, there isn't so you may have to send the slides before the call. Sorry about that.

On Mon, Jan 29, 2018 at 5:32 AM, Balcer, Piotr <piotr....@intel.com> wrote:

Hi,

Is there a webex type of a thing where I can share my desktop/show slides?

 

Piotr

[Piotr Balcer]

Hi,
Thanks for having me.

Here's the slide deck I prepared for this meeting:
https://docs.google.com/presentation/d/e/2PACX-1vTsbdYXg4Rh6HAoFHldYy-OY5RxeykN8Z5VEWc42aloKRIkOfxU0K5lDp4JfyDMvmx6mi569_s2Sjj2/pub

I'll briefly explain what is persistent memory, and then we will move on to the C++ library and the transactional memory tie-in discussion.

Piotr

[Scott, Michael]

Minutes, SG5
29 January 2018

Start Time: Monday, Jan 29 2018, 12:00 PM US Pacific Time (07:00 PM in GMT)
End Time: 1:00 PM US Pacific Time (duration: one hour)

Notes by Michael Scott.

The current secretary rota list is (the person who took notes at the
last meeting is moved to the end)

Michael Spear, Jens Mauer, Victor Luchangco, Michael Wong,
Hans Boehm, Maged Michael, Michael Scott

Agenda:

1. Opening and introductions

1.1 Roll call of participants

Victor Luchangco, Mike Spear, Hans Boehm, Michael Scott,
Piotr Balcer [Intel], Tom Kapela [Intel]

1.2 Adopt agenda

Interaction of TM w/ persistence

1.3 Approve minutes from previous meeting, and approve publishing
previously approved minutes to ISOCPP.org

1.4 Review action items from previous meeting (5 min)

NA

1.5 Call schedules (please add your away days)

Jan 29: Michael away
Feb 12 : mailing deadline is 10 am ET today
Feb 26: Michael Scott away
March 12 C++ Meeting JAX

2. Main issues (50 min)

2.1 Persistent memory by piotr....@intel.com

<< See slide deck:
https://docs.google.com/presentation/d/e/2PACX-1vTsbdYXg4Rh6HAoFHldYy-OY5RxeykN8Z5VEWc42aloKRIkOfxU0K5lDp4JfyDMvmx6mi569_s2Sjj2/pub
Ran through slides 1-18. >>

Misc. notes:
Asynchronous DRAM refresh important to semantics.
Atomicity guaranteed at 8-byte granularity only.
Writes-back to different words of the same cache line may therefore
reach memory out of order.
HW guaranteed that memory controller buffers will be flushed on power fail.
Anticipate mmap-ing files directly, w/out intervening kernel buffers.
No need for msync()
File system must leave page alone after it is mmap-ed()
May have 100s of GB on a single NVDIMM.

libpmemobj
Provides transactions and atomic updates.
Implementation is undo-log based. Uses thread-local storage.
malloc and free within file are failure atomic.
Have to deal w/ fact that malloc and adding to data structure are
separate steps; not atomic.
Scoped wrapper for transactions.
Snapshotting of basic data types
p<> property
Note that this envisions a static partitioning between
persistent and nonpersistent memory. SG5 STM envisions
operating on "ordinary" C++ data.
Position-independent persistent pointers
Implementation is a 16B quantity containing UID for file and offset.

Challenges
libstdc++ containers works w/ LLVM libc++ but not GNU libstdc++ or MSVC.
Latter 2 aren't yet C++11 compliant.
Lack of standard layouts for data structures means you can get
memory corruption if you write from code using one version and
read or write from code using another.
Probably need some sort of version tagging.
vptrs (and thus RTTI) don't work across program invocations!
Currently limited to POD objects.
code of standard library operations and algorithms doesn't know
about persistent pointers, and is compiled w/out necessary
instrumentation.
Hope to build upon HTM and Intel libitm.
Envision an interface that implements operations to begin,
commit, rollback txn; load, store word. Could then provide this
interface to a transaction, to be used inside, thereby avoiding
the need for the compiler to understand or have access to the
library.
Looking forward to future architectures that will flush _caches_
on power failure.

Discussion
What about accesses _outside_ one of these persistent-atomic blocks?
Might our newer ideas regarding executor-based transactions be a
better fit than the full technical specification.

NB: HTM provides isolation but not (failure) atomicity

Adjourned at 4pm.

Next call: Feb 12

----------------------------------------
(Didn't get to anything below here.)

2.2: Interaction with Executors and Synchronized proposal

https://groups.google.com/a/isocpp.org/forum/#!topic/tm/jG9XPJetNkc

The last discussion has us considering an alternative lambda form.

See Paper emailed out on Lambda proposal

https://docs.google.com/document/d/1ICmcrCdigq3ataoM2Jl7m19h_Sa3aE3KfU6AVkPyT-4/edit#

2.3 Future of TM Discussion with Herb

Herb, if you like to send any pre-call material or discussion, please go ahead.

2.4 future issues list:

1. llvm synchronized blocks

[Piotr Balcer]

Hi folks,
I'd like to thank everyone for attending our presentation and sharing their insight.
I have to admit it was a humbling experience, it showed us that we have a truly long
road ahead ;)
But that was the point after all, we wanted to learn what we were missing.

We now want to consider everything that was said on the call during the discussion
and come up with a better solution that attempts to address the problem of persistent
memory integration in a more thorough way. Once we have a something tangible
fleshed out, we'd love to have a follow up discussion on this forum.

Thanks again,
Piotr

[Tim Sweeney]

In my view, this is going the wrong way.  Here's a summary of reasons, and an alternative path forward.

First, let's recognize that the following topics are closely linked:

- Transactional memory (how do we track all reads and writes to all shared memory?)

- Persistence (how do we allocate, find, persist, and manage data long-term without corruption?)

- Garbage collection (how do we find out what memory is actively being used?)

- ABI (how do we provide interface and data backwards-compatibility over multiple program invocations and even across platforms?)

- Reflection (what is the format of all of our data?)

There are several different ways that SG5 could approach this topic.

The current approach is to try to expose transactional memory at the language level.  This is difficult, expensive, not fully orthogonal to the other topics above.  More generally, it seems aloof to the C++ way, which is to expose general abstractions to programmers so we can implement specific features.  Examples of abstractions include functions (1960), templates (1990), and reflection (2020?)

My view is: Give us a great reflection spec, and we'll do the other things ourselves in libraries.  Doing this in libraries would be a good thing because:

- Developers can experiment and discover what works best, as opposed to mandating a solution that's only roughly prototyped.

- Designing containers for transactional, persistent, garbage-collected, binary-forward-compatible containers leads to very different designs than std.

- New transactional, persistent, garbage-collected code will need to coexist and interoperate with existing libraries, so fine-grained control will be needed -- which is natural with a library solution to these problems, and unnatural with cross-cutting language features.

- Reflection provides the full toolset needed to build the features above. Transactions via new templated container types; persistence via anything from serialization to patching memory to upgrade versions in-place; garbage collection via metadata; and ABI compatibility by automatically creating forward-compatible wrappers and adapters.

A minimalist alternative for SG5 is to simply bless (via std extensions) the kind of accelerated-but-not-guaranteed restricted transactional memory of Intel's TSX and similar related proposals.  These are well-understood low-level features that libraries can build on to implement full transactional memory and the other things, on an opt-in basis.

-Tim

--
You received this message because you are subscribed to the Google Groups "SG5 - Transactional Memory" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tm+unsu...@isocpp.org.
To post to this group, send email to t...@isocpp.org.
Visit this group at https://groups.google.com/a/isocpp.org/group/tm/.

[Michael Wong]

Thanks Tim. Also, Piotr for the presentation. Tim, I saw your earlier posting on TM proposal and was hoping to discuss with you but was delayed due to extended business trip the last 3 weeks.  I like to invite you to come on the next call to discuss this on our next telecon call. We have been looking for feedback on current TM progress especially in the games industry. Personally I am also interested in full support of lambdas for reflections. As chair  of SG14 on low latency for games, we are also interested in seeing this discussed in greater details.

Our next SG5 call is in 2 weeks, Monday Feb 12 at 3 pm ET. Would that work for you or if not we can set an alternate time (possibly joined with SG14 and SG7) ? Thank you.