zimmie

dewme said:

mattinoz said:

dewme said:

22july2013 said:

I presume this article is talking about 32 cores being on the same die. If true, that's good to hear. But don't see why Apple couldn't put multiple physical packages with N-cores each on the same system board. Moreover, Apple should do this as an expansion card for existing Intel Mac Pros so that Intel Mac Pros can run M1-apps natively.

They could, but it would diminish some of the benefits of the M1's unified memory architecture. Yes, you'd still have more cores available for working on highly parallelizable problems, but once the parts of the work are chunked and doled out to different groups of cores in different packages you'd have to designate something, like a "master" package or CPU to reassemble (memory copy) all of the distributed work back to a central point for final processing - and it would have to fit into the memory space of the master.

Keep in mind that the multiple CPUs on traditional multiple CPU motherboards all shared the same main memory. Additionally, each CPU or CPU core had its own memory caches and all of those caches had to be maintained in a coherent state because they were all referencing shared memory locations. If one CPU/core changed the value of a cached location in shared memory all caches in all CPUs/cores that also hold a reference to that main memory location in their caches have to be updated.  With the M1 Apple can optimize its cache coherency logic much easier within its unified memory architecture than it can with shared off-package memory. If Apple brings in multiple packages each with multiple cores to work on shared problems, how many of these traditional memory management problems come back into the fray? I ask this only because a lot of the architectural benefits that Apple achieves with the M1 are due to tight-coupling between CPU cores, tight-coupling between CPU and GPU cores, and having a unified memory architecture very close to all of the cores. Moving to a multi-package model brings loose coupling back into the picture, which will most definitely limit the overall speedup that is attainable. There are alternate ways to get something in-between tight and loose coupling, as AMD has done, but you want to keep everything as close as possible.

Two things to keep in mind with all Von Neumann based architectures, which includes all current Macs and PCs, 1: copying memory around always sucks from a performance standpoint, and 2: even small amounts of non-parallelizable code has a serious negative impact on the attainable speedup that can be seen with any number of processing units/cores (Ahmdahl's Law). This doesn't mean that speedups aren't possible, it just means that unless your code is well above 90% parallelizable you're going to max out on performance very quickly regardless of the number of cores. For example for 90% case, with 8 cores you'd get a speedup of 5 over a single core, but with 32 cores you're only getting a speedup of 8 over a single core even though you've quadrupled the number of cores. To double the speedup in the 90% case you'd have to go from 8 cores to around 512 cores. 

The idea of a M1 coprocessor board for the Mac Pro is not a bad idea, and it's a strategy that's been used since the dawn of personal computers. One of DEC's first PC-compatible computers, the Rainbow 100, had a 8088 and a Z80 processor so it could run both MS-DOS and CP/M (and other) operating systems and applications. I've had PCs, Sun workstations, and industrial PLCs that had plug-in coprocessor boards for doing specialized processing semi-independently of the host CPU. The challenge is always how to integrate the coprocessor with the host system so the co-processor and the host system cooperate in a high quality and seamless manner. Looking across the tight-coupling to loose-coupling spectrum, these plug-in board solutions tend to be more on the looser side of the spectrum unless the host system (and all of its busses) were purposely designed with the coprocessor in mind, like the relationship between the old 8086/8088 general purpose CPU and the 8087 numerical coprocessor.  

  

Could the Unified Memory be used as a bridge between 2 or more chips?

Could they be planning upgraded systems as multiples of the same chip with a Memory Controller/ PCIe hub chip between them?

That could let them use 6Core bin of chips as to make 12 core clusters and have options for 14 and 16 at a premium. Mirror again to get up to a 32core beast.

Based on the descriptions Apple has published the unified memory pool is in the SoC package and is directly addressable by the CPUs and GPUs to avoid memory copying. This would seemingly make the unified memory address space local to the SoC. If a portion of this memory was shared with another SoC that has its own memory address space this would seemingly introduce cache coherency type of requirements to the architectural model. 

But there’s nothing preventing Apple from defining a range of addresses in unified memory that serve as I/O ports so to speak, possibly with a DMA semantics, to allow high speed data interchange between SoCs. This would be more like a thunderbolt bus interchange and less like CPUs on the same SoC sharing access to the same memory address space. 

If you look at the Mac in a slightly broader sense it is really a system of systems. There’s no doubt that Apple could leverage its Apple Silicon and M-series SoCs in particular as building blocks to compose an Apple SoC powered system of systems in a form factor like we’ve never seen in the markets that Macs currently target. We’re barely past the starting line on this journey. 

razorpit said:

mjtomlin said:

rob53 said:

Why stop at 32 cores. The current TOP500 supercomputer is comprised of a ton of Fujitsu A64X 48 compute core CPUs based on ARM v8.2-A. Cray is also working on changing to the ARM architecture. The current implementation is only running at 2.2 GHz using a 7nm CMOS FinFET design. This is on one chip! (ref: https://en.wikipedia.org/wiki/Fujitsu_A64FX, also https://www.fujitsu.com/downloads/SUPER/a64fx/a64fx_datasheet.pdf)

Those are designed for massive parallelism. This is not something that would be necessary for what is essentially a single user computer. You could get more perceived performance from a lower core, higher clock speed design.

Even a 12 HP core design clocked higher would basically blow past almost everything on the market right now.

I would agree with the current state of MacOS, but who's to say MacOS '11.1' wouldn't start pushing background processes to individual cores.

Instead of applications sharing processor time on a smaller number of cores, you could theoretically scale it up for theses new beast-mode™ processors. I'm guessing the average user wouldn't notice much of a difference, but once you have it figured out it would be easier to apply it to the entire product range and have everyone benefit from it.

I'm sure someone will come along and happily point out how wrong I am, but I'm just floating an idea out there. Remember there was a time when a large part of the "tech elites" also thought 64-bit processors on an iPhone was ludicrous.

22july2013 said:

fastasleep said:

22july2013 said:

melgross said:

...an updated Mac Pro. I didn’t buy one last year, because I wanted the new PCIe 4 bus, which is now becoming common enough for Apple to move to. 

In an Apple Silicon Mac a PCIe bus may not do everything that we might want. For example, a PCIe video card may not work since MacOS Big Sur may not support any video cards even including Metal-based AMD video cards.

I agree that Apple will probably support PCIe v4 in an Apple Silicon Mac with expansion ports, but if it's not for video cards, maybe Apple should just re-think the whole purpose of the expansion card idea entirely. Could Thunderbolt be enough? How about Thunderbolt 4 which is due any day now from Intel (and probably from Apple too, since Apple now supports Thunderbolt without any Intel chips)? What type of cards do people want to install in a Mac that can't be done through a Thunderbolt port in some other way? Thunderbolt 4 is 26% faster than even a 16-lane PCIe v4 connector, and it's almost as fast as 16-lane PCEe v5 which won't be out for a couple of years. Why would anyone want a slow connection like a 16-lane PCIe v4 when Thunderbolt 4 is so much faster? I'll answer that - because you don't have to buy a Thunderbolt cable. So to save $50 people want to settle for a lower bus speed?

This is food for thought; I'm not sure Apple will do what I'm suggesting. I expect the usual claims from people here questioning my sanity. 

Maybe not your sanity, but I think you messed up your units here.

Thunderbolt 4: PCIe data at 32 Gb/s (GigaBITS)
PCIe v4 x 16: 32 GB/s (GigaBYTES) = 256 GigaBITS

"The PCIe 4.0 specification will also bring the OCuLink-2 connector, an alternative to Thunderbolt 3, that provides 8GB/s of bandwidth via four PCIe 4.0 lanes" — That's 64 Gb/s.

Someone correct me if I screwed up here, but PCIe v4 x16 is quite a bit faster than Thunderbolt 4.

Uhoh, that's embarrassing. I will believe you. I think part of the reason I was confused is that some websites talk about GT/s (gigatransfers/sec) and I was probably not discrerning between "gigatransfers of bytes" and "gigatransfers of bits."

But I won't give up so easily. Please note that Thunderbolt is currently using copper cabling. When Thunderbolt was first introduced as "Light Peak" it used fibre optic instead. Corning has bragged about having fibre-optic Thunderbolt (see the video below). I'm sure that fiber-optic is faster than copper, and it's potentially a way forward for Apple without using PCIe. Corning has been silent about this product for years, which could mean they've given up, or could mean they have an NDA with Apple for a future product.

xsmi said:

Apple said at their keynote that the Mac chips would be designed from the ground up with the Mac in mind. Wouldn’t that preclude them using a variant of iPhone/iPad chips? 

indieshack said:

“The iPhone 12 Pro Max also has a slightly narrower telephoto aperture of f/2.2,“

are you sure this is correct? I thought the light gathering was also a function of the focal length, which is different for the Max