4 ms·

haven’t read the article, but there are no single threaded use cases on Apple platforms that Apple cares about, so I’d take any claim that Apple is optimizing f

haven’t read the article, but there are no single threaded use cases on Apple platforms that Apple cares about, so I’d take any claim that Apple is optimizing for single threaded performance with an enormous bag of salt

gumby 3y ago
I'm pretty sure I remember discussion from Srouji and others on this specific topic at the "apple silicon" WWDC introduction. But I can't find anything useful from Apple in a web search, so it seems my statement is just a "some guy on the Internet" assertion. It seems pretty clear and unsurprising that Apple optimises their design for their use case (e.g. major consideration of bandwidth to screen in handheld devices, reminiscent of one of the Alto's design criteria) but how that plays out doesn't support my claim either. But Apple's intended use cases aren't the same as the threadripper's.
MBCook 3y ago
> but there are no single threaded use cases on Apple platforms that Apple cares about I don’t see how that could be true. A huge amount of software tasks are basically single threaded. Remember since Apple does everything soup-to-nuts they have a ton of performance data from their computers to know what real user workloads look like so they can optimize the hardware + the software for them.
- gumby 3y ago
  I made this claim (single threaded performance matters) but in a parallel comment to yours noted that I was unable to find substantiating statements from apple that I believe led to my assertion. So in that spirit I will point out that Apple's support code / framworks etc do a bunch of multithreaded UI and network stuff even when and app's code is putatively single threaded. Now that stuff IMHO is pretty high latency (e.g. waiting on user action) so as a developer I still think my statement, and your impression, are correct. But I'd like to see something from Apple on the topic.
astrange 3y ago
UI latency, the entire point of a device, is a single threaded use case. Multithreaded performance is only good when you don't care about power use, but that's never true on a battery powered phone. It's actually more often the case that you optimize software by removing accidental excess concurrency than by adding it. Junior engineers love them some unstructured concurrency.

gumby 3y ago

I'm pretty sure I remember discussion from Srouji and others on this specific topic at the "apple silicon" WWDC introduction. But I can't find anything useful from Apple in a web search, so it seems my statement is just a "some guy on the Internet" assertion. It seems pretty clear and unsurprising that Apple optimises their design for their use case (e.g. major consideration of bandwidth to screen in handheld devices, reminiscent of one of the Alto's design criteria) but how that plays out doesn't support my claim either. But Apple's intended use cases aren't the same as the threadripper's.

MBCook 3y ago

> but there are no single threaded use cases on Apple platforms that Apple cares about I don’t see how that could be true. A huge amount of software tasks are basically single threaded. Remember since Apple does everything soup-to-nuts they have a ton of performance data from their computers to know what real user workloads look like so they can optimize the hardware + the software for them.

gumby 3y ago
I made this claim (single threaded performance matters) but in a parallel comment to yours noted that I was unable to find substantiating statements from apple that I believe led to my assertion. So in that spirit I will point out that Apple's support code / framworks etc do a bunch of multithreaded UI and network stuff even when and app's code is putatively single threaded. Now that stuff IMHO is pretty high latency (e.g. waiting on user action) so as a developer I still think my statement, and your impression, are correct. But I'd like to see something from Apple on the topic.

astrange 3y ago

UI latency, the entire point of a device, is a single threaded use case. Multithreaded performance is only good when you don't care about power use, but that's never true on a battery powered phone. It's actually more often the case that you optimize software by removing accidental excess concurrency than by adding it. Junior engineers love them some unstructured concurrency.