`Atomic`: The Unexpected Journey. #124

andersio · 2016-11-25T20:20:10Z

The benchmark

Source
It simulates the critical path of Signal, which is grabbing the signal state + querying the interrupted.

Compiler Settings: Both the framework and the test are compiled with -Owholemodule. Checked builds.
Test Environment: i5 4258U, macOS 10.12.1, Xcode 8.1, Swift 3.0.1

Final Speedup

4.641x 😦

The optimised Atomic now takes only 0.029 sec (5%) in the synthetic test of the lock-free disposal PR, significantly faster than it was before.

Baseline Performance

master
0.673 sec (2%)

The Journey

Mark AtomicProtocol.value and AtomicProtocol.swap as @inline(__always).
0.434 sec (2%)

Mark Atomic.modify and Atomic.swap as @inline(__always).
0.296 sec (2%)

Mark PosixThreadMutex.lock and PosixThreadMutex.unlock as @inline(__always).
0.223 sec (2%)

Drop defer statements in Atomic.modify and Atomic.swap.
0.212 sec (3%)

Drop precondition in favour of if-fatalError.
0.188 sec (2%)

Embed PosixThreadMutex into Atomic.
0.179 sec (4%)

Implement value and swap in Atomic.
0.149 sec (4%)

Use the non-copying modify instead of withValue in value.get.
0.145 sec (2%)

Misc

Inline modify into swap manually.
0.145 sec (2%)

Closure based _PosixThreadMutex.lock.
0.179 sec (3%)

-Onone
0.479 sec (3%)

sharplet

If we accept this PR, need to fix a couple issues.

sharplet · 2016-11-25T22:24:29Z

Sources/Atomic.swift

-		return try action(&_value)
+		let returnValue = try action(&_value)
+		didSetObserver?(_value)
+		lock.unlock()


Without defer, if try action(&_value) throws, the lock will never be unlocked.

sharplet · 2016-11-25T22:24:54Z

Sources/Atomic.swift

-			swap(newValue)
-		}
+		let returnValue = try action(_value)
+		lock.unlock()


I think we should bring back defer here too.

Hmm, this is an oversight. Thanks for catching this.

andersio · 2016-11-25T23:40:46Z

The hole @sharplet caught is fixed using do...catch. defer would bump the time up by ~20% due to it being closure based.

P.S. In master, RecursiveAtomic.didSetObserver is called when an error is thrown. Looks like a bug.

sharplet

Regarding didSetObserver, is it possible that the throwing closure can change the inout parameter before throwing, and have that change copied back to the caller? Or does Swift guarantee that in the throwing case the inout parameter won't be changed?

sharplet · 2016-11-26T13:45:59Z

Sources/Atomic.swift

 		precondition(result == 0, "Failed to destroy mutex with error \(result).")
+
+		UnsafeMutableRawPointer(mutex).deallocate(bytes: MemoryLayout<pthread_mutex_t>.size,


I think of using a raw pointer here it might make sense to use mutex.deinitialize(1) and mutex.deallocate(1)? I'm not super familiar with the new pointer APIs though.

Seems UnsafeMutablePointer is enough.

Instances must be aligned to MemoryLayout<Pointee>.alignment, i.e. (UnsafePointer<Int8>(self) - nil) % MemoryLayout<Pointee>.alignment == 0

sharplet · 2016-11-26T13:49:02Z

Sources/Atomic.swift

+			let value = try action(&_value)
+			lock.unlock()
+			return value
+		} catch let error {


You can omit let error here, and in the other catch blocks.

sharplet · 2016-11-26T13:51:32Z

Sources/Atomic.swift

+	@discardableResult
+	@inline(__always)
+	public func swap(_ newValue: Value) -> Value {
+		return modify { (value: inout Value) in


Is the closure type annotation necessary here?

andersio · 2016-11-26T14:31:33Z

Hmm. It won't restore automatically. But making it restoring on throw doesn't make sense in performance for the common use cases either. Maybe it should be left as is.

sharplet · 2016-11-26T15:06:30Z

Sources/Atomic.swift

 		precondition(result == 0, "Failed to destroy mutex with error \(result).")
+		mutex.deallocate(capacity: 1)


https://developer.apple.com/reference/swift/unsafemutablepointer/2295090-deallocate:

Precondition: The memory is not initialized.

This is what made me think that perhaps we should be calling mutex.deinitialize() first.

According to the memory model, it has to be first initialised before being used too. Addressed in 974663c.

mdiep · 2016-12-02T13:34:18Z

Sources/Atomic.swift

+	}
+}
+
+internal final class PosixThreadMutex: NSLocking {


It doesn't look like this is used anywhere? Let's remove it and then remove the underscore from the version we are using.

mdiep · 2016-12-02T13:37:07Z

Sources/Atomic.swift

-
-extension AtomicProtocol {	
-	/// Atomically get or set the value of the variable.
-	public var value: Value {


Should we still keep this and swap as part of AtomicProtocol?

The performance is much worse due to the need to query the protocol witness table, even with the @inline(__always) annotation. I have rerun my benchmarks and it is still the case.

I am actually thinking of removing AtomicProtocol, hmm...

Embed PosixThreadMutex into Atomic.
0.179 sec (4%)

Implement value and swap in Atomic.
0.149 sec (4%)

mdiep · 2016-12-04T01:10:05Z

Sources/Atomic.swift

@@ -8,27 +8,37 @@

 import Foundation

-final class PosixThreadMutex: NSLocking {
-	private var mutex = pthread_mutex_t()
+internal struct PosixThreadMutex {


Why is this a struct with an UnsafeMutablePointer instead of a class with a deinit?

It is usually used with an apparent owner. So defining it as a struct gives the flexibility to have it embedded in the containing type, should it be a stored property, and have one less pointer to chase.

Drop precondition in favour of if-fatalError.
0.188 sec (2%)

Embed PosixThreadMutex into Atomic.
0.179 sec (4%)

andersio · 2016-12-05T17:40:25Z

Related: https://lists.swift.org/pipermail/swift-users/Week-of-Mon-20161205/004147.html

Joe Groff jgroff at apple.com
If you apply them to memory you allocated manually with malloc/free on UnsafeMutablePointer's allocation methods, then yeah, they should work as they do in C. That's the safest way to use these functions today. Passing a Swift var inout to one of these functions does not guarantee that accesses to that var will maintain atomicity, since there may be bridging or reabstracting conversions happening under the hood.

mdiep

Good overall. Just needs a couple tweaks.

mdiep · 2017-01-23T14:45:20Z

Sources/Atomic.swift

+		} catch {
+			lock.unlock()
+			throw error
+		}


What do you think about keeping the defers?

Removing them seems to have a very minor effect on the speed but makes mistakes more likely.

How likely are we to change this again though? It ~~are~~ is one of the pieces that perhaps would never be altered otherwise.

There's no way to know. 🙃

mdiep · 2017-01-23T14:46:15Z

Sources/Atomic.swift

@@ -277,7 +378,8 @@ extension AtomicProtocol {
 	///
 	/// - returns: The old value.
 	@discardableResult
-	public func swap(_ newValue: Value) -> Value {
+	@inline(__always)
+	func swap(_ newValue: Value) -> Value {


Is this still public?

~~Atomic.swap is. RecursiveAtomic.swap isn't.~~ Fixed.

mdiep · 2017-01-23T14:47:41Z

Sources/Atomic.swift

-final class PosixThreadMutex: NSLocking {
-	private var mutex = pthread_mutex_t()
+internal struct PosixThreadMutex {
+	private let mutex: UnsafeMutablePointer<pthread_mutex_t>


Can you add a comment that explains this?

Any time we choose the non-obvious route to get a speed boost, we should document it.

andersio · 2017-01-25T13:06:08Z

Sources/Atomic.swift

@@ -131,7 +131,7 @@ internal struct UnsafeAtomicState<State: RawRepresentable>: AtomicStateProtocol
 /// The wrapper is a struct so that it can be inlined when it is contained as
 /// part of a reference type, and dodges an extra level of calling indirection
 /// that would otherwise happen if the wrapper itself is an reference type.
-internal struct PosixThreadMutex {
+internal struct PthreadMutex {


Well, it is generally called pthread anyway... So let's make it a bit shorter...

sharplet requested changes Nov 25, 2016

View reviewed changes

andersio mentioned this pull request Nov 26, 2016

Optimize Bag. #126

Merged

andersio force-pushed the atomic-perf branch from ecaf9b3 to 81c3885 Compare November 26, 2016 11:37

sharplet reviewed Nov 26, 2016

View reviewed changes

andersio force-pushed the atomic-perf branch 2 times, most recently from 0a1862a to 43cde25 Compare November 26, 2016 14:59

sharplet reviewed Nov 26, 2016

View reviewed changes

andersio force-pushed the atomic-perf branch from 43cde25 to f1128ce Compare November 26, 2016 15:08

andersio mentioned this pull request Nov 26, 2016

Lock-free disposal. #107

Merged

andersio force-pushed the atomic-perf branch from f1128ce to 54e5715 Compare November 29, 2016 20:11

mdiep added the optimization label Dec 2, 2016

mdiep requested changes Dec 2, 2016

View reviewed changes

mdiep reviewed Dec 4, 2016

View reviewed changes

andersio added 6 commits December 31, 2016 04:18

Optimized Atomic.

c0acb94

Fixed the deadlock when throwing in modify or withValue.

805ee78

Fixed the pthread mutex deadlock in 32-bit builds.

77e492f

Fixing the recursive modify + Refactoring + Improved documentation.

844180a

Removed the pthread mutex reference type wrapper.

b975884

Cleanup and undo breaking changes in the public Atomic API.

43554ee

andersio force-pushed the atomic-perf branch from 1fa9fd6 to 43554ee Compare December 31, 2016 03:21

mdiep requested changes Jan 23, 2017

View reviewed changes

andersio added 3 commits January 25, 2017 12:57

AtomicProtocol.swap should be public.

134ca93

Added notes on PosixThreadMutex.

27a8bf1

Rename PosixThreadMutex to PthreadMutex.

8eb1989

andersio commented Jan 25, 2017

View reviewed changes

mdiep approved these changes Jan 25, 2017

View reviewed changes

andersio closed this Feb 25, 2017

andersio deleted the atomic-perf branch February 25, 2017 08:22

This was referenced Feb 25, 2017

Adopt os_unfair_lock. #280

Closed

Adopt os_unfair_lock. #282

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

`Atomic`: The Unexpected Journey. #124

`Atomic`: The Unexpected Journey. #124

andersio commented Nov 25, 2016 •

edited

Loading

sharplet left a comment

sharplet Nov 25, 2016

sharplet Nov 25, 2016

andersio Nov 25, 2016

andersio commented Nov 25, 2016 •

edited

Loading

sharplet left a comment

sharplet Nov 26, 2016

andersio Nov 26, 2016 •

edited

Loading

sharplet Nov 26, 2016

andersio Nov 26, 2016

sharplet Nov 26, 2016

andersio Nov 26, 2016

andersio commented Nov 26, 2016 •

edited

Loading

sharplet Nov 26, 2016

andersio Nov 26, 2016 •

edited

Loading

mdiep Dec 2, 2016

mdiep Dec 2, 2016

andersio Dec 2, 2016

mdiep Dec 4, 2016 •

edited

Loading

andersio Dec 4, 2016 •

edited

Loading

andersio commented Dec 5, 2016

mdiep left a comment

mdiep Jan 23, 2017

andersio Jan 25, 2017 •

edited

Loading

mdiep Jan 25, 2017

mdiep Jan 23, 2017

andersio Jan 25, 2017 •

edited

Loading

mdiep Jan 23, 2017

andersio Jan 25, 2017

		precondition(result == 0, "Failed to destroy mutex with error \(result).")

		UnsafeMutableRawPointer(mutex).deallocate(bytes: MemoryLayout<pthread_mutex_t>.size,

		precondition(result == 0, "Failed to destroy mutex with error \(result).")
		mutex.deallocate(capacity: 1)

Atomic: The Unexpected Journey. #124

Atomic: The Unexpected Journey. #124

Conversation

andersio commented Nov 25, 2016 • edited Loading

The benchmark

Final Speedup

Baseline Performance

The Journey

Misc

sharplet left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio commented Nov 25, 2016 • edited Loading

sharplet left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio Nov 26, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio commented Nov 26, 2016 • edited Loading

Choose a reason for hiding this comment

andersio Nov 26, 2016 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

mdiep Dec 4, 2016 • edited Loading

Choose a reason for hiding this comment

andersio Dec 4, 2016 • edited Loading

Choose a reason for hiding this comment

andersio commented Dec 5, 2016

mdiep left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio Jan 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

andersio Jan 25, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

`Atomic`: The Unexpected Journey. #124

`Atomic`: The Unexpected Journey. #124

andersio commented Nov 25, 2016 •

edited

Loading

andersio commented Nov 25, 2016 •

edited

Loading

andersio Nov 26, 2016 •

edited

Loading

andersio commented Nov 26, 2016 •

edited

Loading

andersio Nov 26, 2016 •

edited

Loading

mdiep Dec 4, 2016 •

edited

Loading

andersio Dec 4, 2016 •

edited

Loading

andersio Jan 25, 2017 •

edited

Loading

andersio Jan 25, 2017 •

edited

Loading