[concurrency] Implement the Task allocator as bump-pointer allocator. #34880

eeckstein · 2020-11-27T19:14:41Z

The task allocator is implemented by using the new StackAllocator utility.
A StackAllocator performs fast allocation and deallocation of memory by implementing a bump-pointer allocation strategy. In contrast to a pure bump-pointer allocator, it's possible to free memory.
Allocations and deallocations must follow a strict stack discipline.
In general, slabs which become unused are not freed, but reused for subsequent allocations. The first slab is tail allocated to the StackAllocator.

TODO: we could pass an initial pre-allocated first slab to the allocator, which is allocated on the stack or with the parent task's allocator.

rdar://problem/71157018

rxwei · 2020-11-28T11:19:58Z

Cool! I was just implementing an allocator in the Swift runtime for use with automatic differentiation — I used llvm::BumpPtrAllocator and it worked fine for me. Is there a reason to implement a new allocator instead of using llvm::BumpPtrAllocator? If so, perhaps AutoDiff can adopt this implementation as well.

eeckstein · 2020-11-30T10:24:09Z

@rxwei There are several differences, most importantly that the task allocator also can free memory (in a stack discipline).
Also, the task allocator uses "inlined" memory for the first slab, which avoid malloc at all if only a small amount of memory is needed.

rxwei · 2020-11-30T18:56:14Z

@rxwei There are several differences, most importantly that the task allocator also can free memory (in a stack discipline).
Also, the task allocator uses "inlined" memory for the first slab, which avoid malloc at all if only a small amount of memory is needed.

These features would be needed for AutoDiff as well. I’m interested in using this to replace the allocator in #34886. Do you think it can be moved to a header file that we can import?

eeckstein · 2020-12-02T10:40:31Z

@swift-ci benchmark

swift-ci · 2020-12-02T11:46:10Z

Performance: -O

Regression	OLD	NEW	DELTA	RATIO
UTF8Decode_InitFromBytes_ascii_as_ascii	449	533	+18.7%	0.84x (?)

Improvement	OLD	NEW	DELTA	RATIO
UTF8Decode_InitFromData_ascii_as_ascii	800	642	-19.7%	1.25x (?)

Code size: -O

Performance: -Osize

Improvement	OLD	NEW	DELTA	RATIO
FlattenListLoop	2503	1631	-34.8%	1.53x (?)
FlattenListFlatMap	5790	4143	-28.4%	1.40x (?)

Code size: -Osize

Performance: -Onone

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

eeckstein · 2020-12-02T16:17:51Z

@swift-ci smoke test

eeckstein · 2020-12-02T16:24:47Z

@rxwei makes sense. I moved it to a separate file.

DougGregor · 2020-12-02T17:46:38Z

include/swift/ABI/Task.h

+  /// Reserved for the use of the task-local stack allocator and it's first
+  /// slab.
+  /// TODO: decide what's the optimal size, e.g. based on typical memory needs.
+  void *AllocatorPrivate[64];


Every task, including child tasks, will have these 64 words of storage. I had thought of child tasks as being fairly lightweight abstractions, but this makes them significantly larger. Is that okay?

Wouldn't every task need at least one context allocation? If so, then this inline-buffer avoids an malloc call.

The size is TBD, though. 64 is just an initial random number.

"its"

I think this initial slab buffer should not be in the main AsyncTask structure, which is ABI. If you want to have swift_task_create preallocate some space and then hand it off to the allocator during initialization, that seems fine, but you should figure out a runtime-private way of doing it. That does mean it won't be tail to the allocator, but I think you should be able to deal with that.

eeckstein · 2020-12-02T19:55:17Z

@swift-ci smoke test linux

rjmccall · 2020-12-02T21:38:52Z

include/swift/ABI/Task.h

+  /// Reserved for the use of the task-local stack allocator and it's first
+  /// slab.
+  /// TODO: decide what's the optimal size, e.g. based on typical memory needs.
+  void *AllocatorPrivate[64];


"its"

I think this initial slab buffer should not be in the main AsyncTask structure, which is ABI. If you want to have swift_task_create preallocate some space and then hand it off to the allocator during initialization, that seems fine, but you should figure out a runtime-private way of doing it. That does mean it won't be tail to the allocator, but I think you should be able to deal with that.

rjmccall · 2020-12-02T21:44:21Z

unittests/runtime/TaskAlloc.cpp

@@ -0,0 +1,76 @@
+//===--- TaskStatus.cpp - Unit tests for the task-status API --------------===//


TaskAlloc.cpp

rjmccall · 2020-12-02T21:45:16Z

stdlib/public/runtime/StackAllocator.h

+    /// A single linked list of all allocated slaps.
+    Slab *next = nullptr;
+
+    // Capacity and offset do not include this header fields.


rjmccall · 2020-12-02T21:45:24Z

stdlib/public/runtime/StackAllocator.h

+  /// This struct is actually just the slab header. The slab buffer is tail
+  /// allocated after Slab.
+  struct Slab {
+    /// A single linked list of all allocated slaps.


rjmccall · 2020-12-02T21:48:50Z

stdlib/public/runtime/StackAllocator.h

+
+      // No space in the next slab. Although it's empty, the size exceeds its
+      // capacity.
+      // As we have to allocate a new slab anyway, free all successor slaps


rjmccall · 2020-12-02T21:58:37Z

stdlib/public/runtime/StackAllocator.h

+
+  // Return a slab which is suitable to allocate \p size memory.
+  Slab *getSlabForAllocation(size_t size) {
+    Slab *slab = (lastAllocation ? lastAllocation->slab : getFirstSlab());


IIUC, the linked list of slabs starts at the pre-allocated slab, and then next points to the slab allocated after the last, right? So starting at lastAllocation->slab means you actually don't check to see if there's any space in any of the older slabs. Is that intentional? It's certainly possible that you have plenty of space for small allocations in older slabs but you needed a big new slab for the last one. But maybe not looking in them is the right trade-off.

@rjmccall Yes, this is intention. As you said, it's a trade-off.

eeckstein · 2020-12-08T14:09:51Z

I pushed a new version, which now does not use a pre-allocated first slab - to keep the task allocation small.
We can improve this in folllow-up work, e.g. by providing stack-allocated space or space allocated with the parent task's allocator.

eeckstein · 2020-12-08T14:10:01Z

@swift-ci test

swift-ci · 2020-12-08T14:58:45Z

Build failed
Swift Test OS X Platform
Git Sha - 8220224b5b854d4c0e7357ef268d67099732ac12

swift-ci · 2020-12-08T15:17:04Z

Build failed
Swift Test Linux Platform
Git Sha - 8220224b5b854d4c0e7357ef268d67099732ac12

eeckstein · 2020-12-08T19:44:44Z

@swift-ci test

swift-ci · 2020-12-08T21:03:46Z

Build failed
Swift Test Linux Platform
Git Sha - 635a89ca02067344409c76afe16c07e9181efac0

swift-ci · 2020-12-08T22:15:46Z

Build failed
Swift Test OS X Platform
Git Sha - 635a89ca02067344409c76afe16c07e9181efac0

A StackAllocator performs fast allocation and deallocation of memory by implementing a bump-pointer allocation strategy. In contrast to a pure bump-pointer allocator, it's possible to free memory. Allocations and deallocations must follow a strict stack discipline. In general, slabs which become unused are _not_ freed, but reused for subsequent allocations. The first slab can be placed into pre-allocated memory.

Use the StackAllocator as task allocator. TODO: we could pass an initial pre-allocated first slab to the allocator, which is allocated on the stack or with the parent task's allocator. rdar://problem/71157018

eeckstein · 2020-12-09T21:23:43Z

@swift-ci test

rjmccall

LGTM

eeckstein requested a review from rjmccall November 27, 2020 19:14

eeckstein force-pushed the task-allocator branch 2 times, most recently from edfb23b to 5eb6027 Compare November 30, 2020 18:06

rxwei mentioned this pull request Nov 30, 2020

[AutoDiff] Bump-pointer allocate pullback structs in loops. #34886

Merged

eeckstein force-pushed the task-allocator branch from 5eb6027 to 676cd8b Compare December 2, 2020 10:40

eeckstein force-pushed the task-allocator branch from 676cd8b to 367cc64 Compare December 2, 2020 16:15

DougGregor approved these changes Dec 2, 2020

View reviewed changes

rjmccall reviewed Dec 2, 2020

View reviewed changes

eeckstein force-pushed the task-allocator branch from 367cc64 to 8220224 Compare December 8, 2020 14:06

eeckstein force-pushed the task-allocator branch from 8220224 to 635a89c Compare December 8, 2020 19:44

eeckstein added 2 commits December 9, 2020 22:22

[concurrency] Implement the Task allocator as bump-pointer allocator.

ec1490d

Use the StackAllocator as task allocator. TODO: we could pass an initial pre-allocated first slab to the allocator, which is allocated on the stack or with the parent task's allocator. rdar://problem/71157018

eeckstein force-pushed the task-allocator branch from 635a89c to ec1490d Compare December 9, 2020 21:23

rjmccall approved these changes Dec 10, 2020

View reviewed changes

eeckstein merged commit ad58de3 into swiftlang:main Dec 10, 2020

eeckstein deleted the task-allocator branch December 10, 2020 07:37

		@@ -0,0 +1,76 @@
		//===--- TaskStatus.cpp - Unit tests for the task-status API --------------===//

[concurrency] Implement the Task allocator as bump-pointer allocator. #34880

[concurrency] Implement the Task allocator as bump-pointer allocator. #34880

Uh oh!

Conversation

eeckstein commented Nov 27, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rxwei commented Nov 28, 2020

Uh oh!

eeckstein commented Nov 30, 2020

Uh oh!

rxwei commented Nov 30, 2020

Uh oh!

eeckstein commented Dec 2, 2020

Uh oh!

swift-ci commented Dec 2, 2020

Performance: -O

Code size: -O

Performance: -Osize

Code size: -Osize

Performance: -Onone

Code size: -swiftlibs

Uh oh!

eeckstein commented Dec 2, 2020

Uh oh!

eeckstein commented Dec 2, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eeckstein commented Dec 2, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

eeckstein commented Dec 8, 2020

Uh oh!

eeckstein commented Dec 8, 2020

Uh oh!

swift-ci commented Dec 8, 2020

Uh oh!

swift-ci commented Dec 8, 2020

Uh oh!

eeckstein commented Dec 8, 2020

Uh oh!

swift-ci commented Dec 8, 2020

Uh oh!

swift-ci commented Dec 8, 2020

Uh oh!

eeckstein commented Dec 9, 2020

Uh oh!

rjmccall left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

eeckstein commented Nov 27, 2020 •

edited

Loading