Nuvia: don’t hold your breath

[Cmaier]

Hey @Cmaier, didn't you once say that a semiconductor startup that includes ex-Apple employees was stalking you on LinkedIn? Looks like Apple isn't happy about it, and is taking them to court over it. (Poaching employees and stealing trade secrets, not stalking you online, although that would be awesome to see in court.)

LOL. Saw that. It was nuvia employees who kept looking me up on linkedin, though.

 

[Andropov]

I don't believe this is entirely accurate (but also not entirely wrong). Functions that access state also pick up on the isolation and become isolated themselves. However, they are also reentrant, meaning that if an isolated function suspends during execution, then yes, the actor's state can be mutated underneath it during that suspension point by another access to the actor's isolated context.

Oh, is that so? I wasn't sure if that was the case, that's why I threw in the NSLock. If an actor only executes one 'block of code' at a time (between suspension points, I mean) then my lock was unnecessary (there was no suspension point between the check and the change in value). Hmm. Makes more sense if it works that way.

Although if that's the case, then actors are not as good as preventing data contention as some articles made me think they were. If an actor method has a long running code block with no suspension points in-between, it'd block any changes to the state from other threads for a while. It's true that those other threads would be suspended themselves, since actor method calls require async, but I see a potential for trouble here that I have not seen mentioned anywhere. Interesting.

 

[Nycturne]

Oh, is that so? I wasn't sure if that was the case, that's why I threw in the NSLock. If an actor only executes one 'block of code' at a time (between suspension points, I mean) then my lock was unnecessary (there was no suspension point between the check and the change in value). Hmm. Makes more sense if it works that way.

Correct, and this behavior is outlined in the Swift evolution proposal. There's a second proposal that also outlines some ways to fine tune the isolation behaviors, such as telling the compiler when it's safe to remove isolation on a computed property that doesn't depend on any isolated state, or to pull another actor into a function's isolation context to reduce suspension points within an isolated function that's orchestrating data between two actors. Both of these are part of Swift 5.5.

Although if that's the case, then actors are not as good as preventing data contention as some articles made me think they were. If an actor method has a long running code block with no suspension points in-between, it'd block any changes to the state from other threads for a while. It's true that those other threads would be suspended themselves, since actor method calls require async, but I see a potential for trouble here that I have not seen mentioned anywhere. Interesting.

This doesn't seem any worse than async calls into a serial queue in terms of contention. You execute a long-running block on a serial queue, that queue will back up. You execute a long-running function on an actor, waiting tasks will back up. Note that I say waiting tasks, not threads. The difference is important in that waiting tasks do not need to block a thread to wait, and those threads are free to execute other tasks (i.e. no thread explosion).

Maybe I'm missing something?

 

[Andropov]

Maybe I'm missing something?

Nope, you're right. Even that worst-case-scenario (long running actor method with no suspension points) would be no worse than a serial dispatch queue. In fact, it'd be potentially much better, since it's mandatory to be async so callers are not blocked. And realistically in a lot of cases the long running part would be offloaded to an async function, or at least broken down at some points, where other calls would take over. It might even be possible to prioritise high QoS calls when the current executing task suspends, something that's impossible with a serial queue. So there are actually many ways in which the actor model is better. Thinking about it, it's a very clever solution.

My only concern (what motivated my previous post) is that it could be more error prone. It seems to me that's it's easier to mistakenly write this:

actor FooActor {
    var fooState: Int = 0
  
    func fooMethod() {
        longRunningThing()
        fooState += 1
    }
}

And forget that the method is going to run serially and block all other calls to the actor during its execution, than to mistakenly do this:

let dispatchQueueForIO = DispatchQueue(label: "Serial Queue for I/O")

dispatchQueueForIO.async {
    longRunningThing()
    fooSeriallyAccessedOnlyProperty += 1
}

And forget that it's running on the serial queue. Ideally, both cases should move the longRunningThing() outside the method/async block. But in the latter is extremely clear that the context is a serial queue, so the error is more evident. More verbose, in a way. That may be because I'm less used to working with actors, admittedly.

 

[Nycturne]

Ideally, both cases should move the longRunningThing() outside the method/async block. But in the latter is extremely clear that the context is a serial queue, so the error is more evident. More verbose, in a way. That may be because I'm less used to working with actors, admittedly.

Agreed, there's a lot more implicit in the Swift concurrency model.

 

[Cmaier]

Nope, you're right. Even that worst-case-scenario (long running actor method with no suspension points) would be no worse than a serial dispatch queue. In fact, it'd be potentially much better, since it's mandatory to be async so callers are not blocked. And realistically in a lot of cases the long running part would be offloaded to an async function, or at least broken down at some points, where other calls would take over. It might even be possible to prioritise high QoS calls when the current executing task suspends, something that's impossible with a serial queue. So there are actually many ways in which the actor model is better. Thinking about it, it's a very clever solution.

My only concern (what motivated my previous post) is that it could be more error prone. It seems to me that's it's easier to mistakenly write this:

actor FooActor {
    var fooState: Int = 0
 
    func fooMethod() {
        longRunningThing()
        fooState += 1
    }
}

And forget that the method is going to run serially and block all other calls to the actor during its execution, than to mistakenly do this:

let dispatchQueueForIO = DispatchQueue(label: "Serial Queue for I/O")

dispatchQueueForIO.async {
    longRunningThing()
    fooSeriallyAccessedOnlyProperty += 1
}

And forget that it's running on the serial queue. Ideally, both cases should move the longRunningThing() outside the method/async block. But in the latter is extremely clear that the context is a serial queue, so the error is more evident. More verbose, in a way. That may be because I'm less used to working with actors, admittedly.

I don’t get actors. I should learn actors. I get queues. I can picture the dispatcher in my mind. I am old.

Implicit stuff also hurts me.

 

[Yoused]

Ooh. That's interesting. Here's the paper, too: https://www.prefetchers.info/augury.pdf

I got partway through it (not too hard to skim) when this kind of jumped out at me

A major complication for reverse engineering is reports that the M1 DRAM controller performs frequency scaling [34]. This matches our observations that a cache miss to DRAM can return in a wide range of times. We find that increasing the pressure on DRAM can reduce the average access time more than amortizing measurement costs would anticipate. The net effect is that we observe otherwise inexplicable decreases in memory access times for longer experiments.

It amost sounds like just adding the right amount of noise to timing cycles might be enough to mitigate some/many of these arcane vunerabilities.

 

[Cmaier]

I got partway through it (not too hard to skim) when this kind of jumped out at me



It amost sounds like just adding the right amount of noise to timing cycles might be enough to mitigate some/many of these arcane vunerabilities.

Any kind of random process can be an effective countermeasure to most side channel attacks. For differential power analysis, you can inject random noise on the power rails, for example.

 

[Colstan]

I didn't think this deserved it's own topic, but Intel is allegedly farming out partial Meteor Lake production to TSMC on their 5nm process. Keep in mind this is Digitimes we are talking about, but we've heard rumblings about this before, and Intel is using 6nm for GPUs. Assuming this is correct, Apple will already be on 3nm, so even Intel can't bribe TSMC enough. It does make me wonder if this is a good idea long-term for TSMC, since Intel is gunning to be a direct competitor in the foundry business, but competitors do business all the time, such as Apple does with Samsung.

Thus far, this doesn't seem like a move of strength from Gelsinger. Sure, he was dealt a bad hand, but I don't see this inspiring a lot of confidence inside Intel. Anyone have any thoughts on his leadership, thus far? I remember back when Mike Magee would write about him in The Register. He called him "Kicking" Pat Gelsinger. Magee claimed that he met with Intel executives during the Itanium launch. Gelsinger said that every major OEM had Itanium systems lined up. When Magee pointed out that Gateway didn't have an Itanium offering, Pat Gelsinger got upset and proceeded to kick Magee, legally committing assault, hence the nickname. Maybe he should save the kicks for Intel's engineers. (Figuratively, not literally.)

 

[Cmaier]

I didn't think this deserved it's own topic, but Intel is allegedly farming out partial Meteor Lake production to TSMC on their 5nm process. Keep in mind this is Digitimes we are talking about, but we've heard rumblings about this before, and Intel is using 6nm for GPUs. Assuming this is correct, Apple will already be on 3nm, so even Intel can't bribe TSMC enough. It does make me wonder if this is a good idea long-term for TSMC, since Intel is gunning to be a direct competitor in the foundry business, but competitors do business all the time, such as Apple does with Samsung.

Thus far, this doesn't seem like a move of strength from Gelsinger. Sure, he was dealt a bad hand, but I don't see this inspiring a lot of confidence inside Intel. Anyone have any thoughts on his leadership, thus far? I remember back when Mike Magee would write about him in The Register. He called him "Kicking" Pat Gelsinger. Magee claimed that he met with Intel executives during the Itanium launch. Gelsinger said that every major OEM had Itanium systems lined up. When Magee pointed out that Gateway didn't have an Itanium offering, Pat Gelsinger got upset and proceeded to kick Magee, legally committing assault, hence the nickname. Maybe he should save the kicks for Intel's engineers. (Figuratively, not literally.)

All I know is Gelsinger was busy the last bunch of years trying to convert people in Silicon Valley to Christianity. Tells me all I need to know about him.

As for TSMC, I‘ll note that from my experience they must be being careful. Obviously they will have to provide Intel with design rules and a design kit (caliber decks, cell libraries, etc.), which would be of at least a small use to Intel if Intel wanted to leverage them to figure out how to make its own process better. But I’m sure TSMC is contractually making Intel set up a wall between its fab folks and design folks with respect to all this information, including audit rights, etc.

TSMC is very paranoid (rightfully so) - I once had to see their detailed process flows, and I had to do it in a glass room, where all I was allowed to bring in was pencil and paper, and I was observed the whole time. All I was allowed to write down was a list of things I wanted more information about, and I had to give the list to them when I left. And at the time I was indirectly working on their behalf. Of course Intel will never get to see anything so detailed.

Which brings me to the second point - practically speaking, there‘s nothing that Intel will gain access to that they wouldn’t already know. They doubtless have analyzed the heck out of apple’s chips, analyzed doping concentrations, looked at things with STEMs, etc. They can almost certainly figure out exactly what TSMC is doing, down to each process step. So the risk to TSMC is low from that respect.

And TSMC may be figuring that it can win *all* of Intel’s business in the distant future, at least for the high end stuff.

On the other hand, TSMC, by doing this, is allowing Intel to sell more product which brings it revenue it can use to eventually compete with TSMC, as well as provides Intel’s fab team with motivation to get their act together.

I’m sure TSMC is thinking very carefully about what to do here.

 

[Yoused]

I was browsing around on the subject of Power10, which seems to look substantially better than x86 for some server implementations and skimmed an old Register piece that included,

An easier-to-sell feature: so-called "transparent" memory encryption. "What is great about this is it is encrypting information transparently without any performance overhead of the system," claimed Boday. "It's done through the hardware. And so we can actually scale this encryption to very large memory databases.

"As the information is encrypted, you [can] continue to do computational workload on it and not unencrypting it, with fully homomorphic encryption. This is all achieved through our 2.5x faster [AES cryptography] performance per core."​

This is interesting. Being able to work on encrypted data without knowing what it actually is. It has a lot of appeal. I wonder if Apple could develop that.

 

[Cmaier]

I was browsing around on the subject of Power10, which seems to look substantially better than x86 for some server implementations and skimmed an old Register piece that included,

An easier-to-sell feature: so-called "transparent" memory encryption. "What is great about this is it is encrypting information transparently without any performance overhead of the system," claimed Boday. "It's done through the hardware. And so we can actually scale this encryption to very large memory databases.​

​

"As the information is encrypted, you [can] continue to do computational workload on it and not unencrypting it, with fully homomorphic encryption. This is all achieved through our 2.5x faster [AES cryptography] performance per core."​

This is interesting. Being able to work on encrypted data without knowing what it actually is. It has a lot of appeal. I wonder if Apple could develop that.

I’m not aware of any type of homomorphic encryption which allows arbitrary operations. There’s always some subset of operations that can be done. This is probably not that useful except in certain narrow use cases.

 

[Cmaier]

It gets so boring being omniscient.

Qualcomm CEO Admits Nuvia Chip OEM Sampling is Delayed (Update)

Sampling target shifts from August 2022 to sometime in 2023.

www.tomshardware.com

 

[Colstan]

It gets so boring being omniscient.

From what I've heard, assuming the leaks are accurate, Zen 4 was delayed by a year. It was supposed to be out Q4 of last year. Raptor Lake, Meteor Lake, and Arrow Lake are also behind schedule. In fact, Arrow Lake was supposed to compete with Zen 4, and instead will have to contend with Zen 5. Intel was expecting a route, but they're behind again, as is tradition. Same goes for their Arc series of graphics cards, which nobody will give a damn about by the time they are released. Looks like Qualcomm is in on the fun, too.

Please correct me if I am wrong, but Apple appears to be on schedule, regarding the M-series cadence. They've delayed some Mac releases, but those are due to shortages in commodity products, and the primary silicon involved has been delivered as expected.

 

[Cmaier]

From what I've heard, assuming the leaks are accurate, Zen 4 was delayed by a year. It was supposed to be out Q4 of last year. Raptor Lake, Meteor Lake, and Arrow Lake are also behind schedule. In fact, Arrow Lake was supposed to compete with Zen 4, and instead will have to contend with Zen 5. Intel was expecting a route, but they're behind again, as is tradition. Same goes for their Arc series of graphics cards, which nobody will give a damn about by the time they are released. Looks like Qualcomm is in on the fun, too.

Please correct me if I am wrong, but Apple appears to be on schedule, regarding the M-series cadence. They've delayed some Mac releases, but those are due to shortages in commodity products, and the primary silicon involved has been delivered as expected.

The chip cadence appears to be on track. The only question mark is the chip for the Mac Pro, which may or may not be behind.

 

[jbailey]

It gets so boring being omniscient.

Qualcomm CEO Admits Nuvia Chip OEM Sampling is Delayed (Update)

Sampling target shifts from August 2022 to sometime in 2023.

www.tomshardware.com

Now the Nuvia Snapdragon will be competitive with the M2? In 2024? Sounds great.

 

[Yoused]

Now the Nuvia Snapdragon will be competitive with the M2? In 2024? Sounds great.

The Snapdragon 888 is showing GB5 SC scores comparable to an A12X, MC somewhat lower, a 3-y/o SoC. Granted, the A12X is listed "up to 2.49 GHz" while the 888 score is listed 1.8 GHz, so there is that. If you truly believe that Nuvia will be less than a year behind AS, well, think again.

 

[Cmaier]

The Snapdragon 888 is showing GB5 SC scores comparable to an A12X, MC somewhat lower, a 3-y/o SoC. Granted, the A12X is listed "up to 2.49 GHz" while the 888 score is listed 1.8 GHz, so there is that. If you truly believe that Nuvia will be less than a year behind AS, well, think again.

The internet: Apple is doomed because the Nuvia guys all left, and therefore M2 is bad and Apple’s progress has stalled.
Qualcomm: the nuvia guys who have been here for a year need two more years to get a chip done.

 

[Colstan]

The internet: Apple is doomed because the Nuvia guys all left, and therefore M2 is bad and Apple’s progress has stalled.
Qualcomm: the nuvia guys who have been here for a year need two more years to get a chip done.

Correct me if I'm wrong, but wasn't Nuvia like three guys? How many engineers, roughly speaking, are working on Apple Silicon? From my purely amateur observations, these are large projects, where any one individual, or handful of individuals, aren't vital to a design implementation. (Except for Jim Keller, because the internet says he is chip god.)

 

[Citysnaps]

The internet: Apple is doomed because the Nuvia guys all left, and therefore M2 is bad and Apple’s progress has stalled.
Qualcomm: the nuvia guys who have been here for a year need two more years to get a chip done.

I might be wrong, but my sense is Qualcomm's glory days have long passed. They have a ton of communications-related patents having written the book on modern communications signal processing and error correction, and no doubt still snag decent licensing fees. But it has been a loooong time since Drs. Viterbi and Jacobs, the real brain trust, ran the company.