Archive for December 23, 2021

Thursday, December 23, 2021 [Tweets] [Favorites]

Roadmap for Improving Swift Performance Predictability

Joe Groff (via David Smith):

For these reasons, we think it makes sense to change the the language rules to follow what is most users’ intuition, while still giving us the flexibility to optimize in important cases. Rather than say that releases on variables can happen literally anywhere, we will say that releases are anchored to the end of the variable’s scope, and that operations such as accessing a weak reference, using pointers, or calling into external functions, act as deinitialization barriers that limit the optimizer’s ability to shorten variable lifetimes. The upcoming proposal will go into more detail about what exactly anchoring means, and what constitutes a barrier, but in our experiments, this model provides much more predictable behavior and greatly reduces the need for things like withExtendedLifetime in common usage patterns, without sacrificing much performance in optimized builds.

[…]

By making the transfer of ownership explicit with move, we can guarantee that the lifetime of the values argument is ended at the point we expect. If its lifetime can’t be ended at that point, because there are more uses of the variable later on in its scope, or because it’s not a local variable, then the compiler can raise errors explaining why. Since values is no longer active, self.values is the only reference remaining in this scope, and the sort method won’t trigger an unnecessary copy-on-write.

[…]

In practice, it follows some heuristic rules:

  • Most regular function arguments are borrowed.
  • Arguments to init are consumed, as is the newValue passed to a set operation.

The motivation for these rules is that initializers and setters are more likely to use their arguments to construct a value, or modify an existing value, so we want to allow initializers and setters to move their arguments into the result value without additional copies, retains, or releases. These rules are a good starting point, but we may want to override the default argument conventions to minimize ARC and copies. For instance, the append method on Array would also benefit from consuming its argument so that the new values can be forwarded into the data structure, and so would any other similar method that inserts a value into an existing data structure. We can add a new argument modifier to put the consuming convention in developer control[…]

[…]

A normal function stops executing once it’s returned, so normal function return values must have independent ownership from their arguments; a coroutine, on the other hand, keeps executing, and keeps its arguments alive, after yielding its result until the coroutine is resumed to completion. This allows for coroutines to provide access to their yielded values in-place without additional copies, so types can use them to implement custom logic for properties and subscripts without giving up the in-place mutation abilities of stored properties. These accessors are already implemented in the compiler under the internal names _read and _modify, and the standard library has experimented extensively with these features and found them very useful, allowing the standard collection types like Array, Dictionary, and Set to implement subscript operations that allow for efficient in-place mutation of their underlying data structures, without triggering unnecessary copy-on-write overhead when data structures are nested within one another.

[…]

When working with deep object graphs, it’s natural to want to assign a local variable to a property deeply nested within the graph[…] As above, we really want to make a local variable, that asserts exclusive access to the value being modified for the scope of the variable, allowing us to mutate it in-place without repeating the access sequence to get to it[…]

This looks great. A related improvement I’d like to see is a way to have function arguments that bypass ARC. For example, if I’m sorting a large array, it’s wasteful to have to retain and release the elements each time they’re passed to a comparator when they’re already owned by the array itself (which the comparator is not modifying). The same applies for iteration over a collection, or even a tree, that doesn’t change change its structure.

Previously:

Update (2021-12-24): Joe Groff:

Your “pass array elements to a comparator function” example should already not require any r/r traffic today, since Array implements read accessors on its subscript, and functions borrow their arguments by default

So I’m not sure why I was seeing ARC overhead before.

(mac)OStalgia

Michael Feeney (Hacker News):

To help me understand how modern applications would have looked liked in the Mac OS 9 era, I had to start analysing the OS in greater detail.

[…]

I then started creating a Library of Mac OS 9 components that I reused throughout my project. The Mac OS 9: UI Kit is available to the whole Figma community. Feel free to use it for your own personal projects as well.

[…]

Click through the slideshow to see the same applications in the macOS 11 environment followed by their Mac OS 9 treatment.

Via Rui Carmo:

I do miss the clarity and sparseness of this era of UI design, if only because windows and controls actually made efficient use of screen real estate instead of being 50% padding and cutesy spacing.

John Gruber:

There are numerous details I’d quibble with (multiple windows active at the same time, for example), but it brought me joy to explore these designs and watch his video of them in action. I miss this style of UI design very much — not the exact look, per se, but the spirit of emphasizing clarity above all else, where content fields are clearly content fields, input focus is clear, and buttons look like buttons.

Previously:

NeXTSpirit Icons

Gaël Elégoët (in 2014, via Hacker News):

Funnily enough, now that we have reached a state of almost no limit in term of CG possibilities, the trend is to « simplify », starting with IOS 7 icons, and now the more flat look of 10.10 Yosemite slowly moving away from the skeuomorphic look.

Anyway , the real NeXT icons you can find are 48×48 sized, of course it looks awful in 10.9, so wanted to have some in hires. imagine a « Retina » NeXTSTEP system :) Hence this NeXTSpirit icon set.

See also: NeXTSpirit Set 2.

Previously:

Bait-and-Switch Amazon Reviews, Continued

Timothy B. Lee (via Hacker News):

When I clicked through to individual product pages, I found that most of those hundreds of positive reviews were for products other than can openers[…]

[…]

Apparently, shady merchants gain control of Amazon pages for highly-rated items and then swap out the product descriptions. I assume their goal is to game Amazon’s search engine—and to trick customers who rely in a product’s star rating without actually reading the reviews.

[…]

When I asked Amazon about the bait-and-switch review problem last year, a spokesperson told me that “we have clear guidelines about when products should be grouped together and we have guardrails in place to prevent products from being incorrectly grouped, either due to human error or abuse.” But the guardrails against abuse still don’t seem to be working. Abuse continues to run rampant, at least for can openers.

Previously:

Bypass TCC via Privileged Helpers

Wojciech Reguła:

This vulnerability has been disclosed on @Hack in Saudi Arabia in 20+ Ways To Bypass Your Macos Privacy Mechanisms presentation. In the end, it allowed impersonating TCC entitlements of any application installed on the device.

[…]

Applications may install privileged helpers in the /Library/PrivilegedHelpers directory. When such a helper tries to access the protected resource (e.g. Address Book), TCC tries to determine which app is responsible for the helper. If the main app is determined, TCC checks whether the app has proper permissions and grants the helper access to the protected resources. The problem is that a malicious helper may trick TCC to select the wrong application as the main app and thus use its entitlements.

[…]

It’s important to understand that the SMJobBless API is not required to register a privileged helper. A malicious application can just create a plist in the /Library/LaunchDaemons directory, place the helper in the /Library/PrivilegedHelpers, load&start the helper via launchctl. So, there is no guarantee that the SMAuthorizedClients key will be pointing to the right owner.

Previously:

FBI Guide to Getting Messaging Data

Andy Kroll (via Bruce Schneier):

But in a previously unreported FBI document obtained by Rolling Stone, the bureau claims that it’s particularly easy to harvest data from Facebook’s WhatsApp and Apple’s iMessage services, as long as the FBI has a warrant or subpoena. Judging by this document, “the most popular encrypted messaging apps iMessage and WhatsApp are also the most permissive,” according to Mallory Knodel, the chief technology officer at the Center for Democracy and Technology.

[…]

There are several messaging apps listed in the FBI document for which minimal data is available to law enforcement without the actual device in hand. Signal will provide only the date and time someone signed up for the app and when the user last logged into the app. Wickr will give law enforcement data about the device using the app, when someone created their account, and basic subscriber info, but not detailed metadata, the FBI document says.

Previously:

Update (2021-12-28): See also: Hacker News.