It's coming. My prediction is Apple will start doing server chips not too long from now, at least for internal use. This is going to be especially important as they emphasize their services more and more over their hardware.
Well, no shit. I was pointing out that they're placing more and more importance on being a services company rather than a hardware/product company. As that emphasis on services grows they'll probably switch to their own silicon for their cloud stuff which their services will run on.
lol what makes you say that? I'd consider apple TV, apple music, apple maps, etc all as services. What is your definition of "services" and do the ones I listed fall into your definition.
I don't know about that. Sure, the F-150 is a nice option but what is Ford doing in terms of self driving. Tesla is tackling multiple issues at the same time, most car companies playing catch up usually just care about the EV part but not the self driving aspect. In 5 years Tesla will still be the dominant EV imo because feature wise their cars will be so far ahead of everyone else.
> Sure, the F-150 is a nice option but what is Ford doing in terms of self driving.
In 5 years time, Tesla won't have solved self-driving, there'll be few distinguishing features between Tesla's self driving and whatever Ford will call its advanced driver-assist tech. If self-driving is completely solved by then, Ford will have the option of licensing Waymo's Driver platform (I predict that Waymo will not venture into large-scale vehicle manufacturing)
I think the main goal of EV's is to be more environmentally friendly. Self driving doesn't contribute to that goal and i don't think it's a thing that will make or break these other manufacturer's efforts.
The trailing manufacturers aren’t building EVs primarily to be environmentally friendly. They are trying to compete for revenue of the growing market.
And also self driving does allow for resource efficiency, which is environmentally friendly. Self driving cars have the potential to drive closer, making better use of limited road surface area and reducing traffic (which reduces emissions of other cars in the same jam). It also allows for fewer cars to serve more passengers.
I think it will be a big factor. Yes, they are two separate things in the car industry. But if I have a choice between two EVs, one with self driving and another with no self driving you bet I'm going to pick the one with self driving. And I'm willing to bet a lot of others will too.
Closed charging networks with proprietary plugs don't help you as a driver. It's just dumb, incompatible infrastructure.
Imagine if you had different electrical sockets for every different brand of appliance in your house. Imagine if you had to used branded fuel for your particular brand of ICE vehicle. It'd be stupid.
Tesla already uses CCS type 2 combo in Europe. They've released a CCS type 1 combo adapter in Korea, but the adapter will not charge as fast as having a CCS inlet on the car.
With the addition of CCS plugs on their chargers in North America and with the eventual availability of the CCS adapter to support legacy vehicles, hopefully Tesla will join the rest of the industry and start putting CCS type 1 combo inlets on the cars in North America soon.
They already offer it to a lot of manufacturers but they mostly refuse. Prime example of this was Porsche. I still can't believe they turned down that offer.
Do you have a source that they don't already support some sort of SVE? I don't think they would make this public information if they don't have to. As far as I can tell they wouldn't need to recompile any previous ARM binaries so this could remain under the hood and they would never need to tell you whether or not they're doing it. So I'd be interested if you have any source on this.
I don't think anyone has found any SVE being used by Apple's binaries. Sure, it could be there, hidden, but that would in practice mean that applications can't use it regardless.
Who says they don't already support SVE; is it publicly known they support it or not? Especially if the binary doesn't have to be recompiled you'd never know whether they implemented it or not right?
I would guess the processor would just cause an exception/interrupt and it would just call an OS level exception/interrupt handler which would probably tell the user what the exception/interrupt was that occured; in this case an unsupported instruction.
"RISC CPUs have a choice. So e.g. smaller ARM CPUs don’t use micro-ops at all. But that also means they cannot do things such as OoO."
I don't agree with this. What do uops have anything to do with ooo execution. I can easily make a CPU with no uops doing ooo execution. Unless I'm misunderstanding and the article is just saying smaller cores don't do ooo since they are trying to stay within a certain area/power footprint.
I didn't really understand the TSO explanation given in this article and found it to be a bit hand-wavy. The article says to emulate the x86 TSO consistency model on an ARM machine which is weakly ordered you have to add a bunch of instructions which would make the emulation slow. I followed that much but then after that it doesn't really explain how they would get around these extra instructions needed to guarantee the ordering. It just says "oh, it's a hardware toggle"; toggle of what exactly?
I could see them just saying no to following TSO for single core stuff and when running emulated code for single core performance benchmarks since technically you don't care about ordering for single core operation/correctness. That would speed up their single core stuff but then what about the multi-core.
so you're saying somehow Rosetta2 is looking at an x86 binary and figuring out exactly which portions of the program rely on the TSO ordering for correctness and then dynamically switches to weak ordering for parts that might be able to do without?
I don't really know much about the internals of macOS but figuring out when there are applications for example running on two different cores (since TSO is only really needed for multi-core use cases) that need to access the same memory and then applying TSO on the fly like that seems difficult. If that is what Rosetta2 is actually doing, that is impressive.
AFAIK: Apple Silicon features an MSR you can toggle which swaps the memory model for a core between ARM's relaxed model and x86's TSO model, all at once. When Rosetta2 launches an app, and translates it, it simply tells the kernel that the process, when given an active slice of CPU time, should use the TSO memory model, not the relaxed one. Only Rosetta2 can request this feature. That's about all there is to it, and it does this whether the app is multicore or not (yes TSO is only needed in multicore, but enabling it unilaterally is simpler and has no downsides for emulating single-core x86 apps.)
There's also a similar MSR for 4k vs 16k page sizes I think, another x86 vs Apple Silicon discrepancy, but I'm not sure if Rosetta2 uses that, too.
I think I understand now. Rosetta is just doing translation from x86 to ARM; however, native ARM doesn't have a notion of TSO which means they're still putting in the logic to maintain TSO just to assist with the better emulation performance. On a purely ARM machine I guess that logic wouldn't be needed.
Yeah, I think that's key to understanding this. They are supporting a version of ARM ISA running that maintains TSO even though official ARM doesn't need to support TSO. I guess this is all to get better emulation performance and avoid those extra synchronization instructions that would have to be added by Rosetta if the silicon did not have TSO support.
Just to be clear, the RAM/memory and cache are not on the same chip/die/silicon. They are part of the same packaging though.
> which keeps the memory between caches and the system memory/RAM coherent
Isn't this already true of every multi-core chip ever designed; the whole point of coherency is to keep the RAM/memory coherent between all the cores and their caches.
> Isn't this already true of every multi-core chip ever designed;
Yes, I just added the explanation of what coherency is in this context as I'm not sure how common the knowledge about it is.
The thing is there are many ways how you can implement this (and related things) with a number of parameters involved which probably can be tuned to optimize for typical RC's usage of atomic operations. (Edit: Just to be clear there are constraints on the implementation imposed by it being ARM compatible.)
A related example (Not directly atomic fetch add/sub and not directly coherency either) would be the way LL/SC operations are implemented. Mainly on ARM you have a parameter of how large the memory region "marked for exclusive access" (by an LL-load operation) is. This can have mayor performance implications as it directly affects how likely a conditional store fails because of accidental inference.
I use the RMT (Remote Control) devices of the ESP32 from FreeRTOS for this. They were intended for generating on-off-keying of carrier modulated wave forms to blink an IR LED for a remote control.
If you leave off the carrier modulation you end up just specifying a list of on and off times and get absolutely rock solid waveforms in hardware.
There's a bunch of them, I forget, maybe 8? So you can drive a bunch of chains at once.
You can also use these for rock solid reading of input signals too. Say you have a weather station that sends some god awful protocol up a wire at you… you just collect a list of the high and low times and get notified when it stops wiggling the signal. Then you sort out the data from the transmission. The timing might be way off because it's cold and the sender's electronics are really cheap, but you can analyze the signal and see what they meant.
That’s handy sounding. There’s some use cases I was thinking about needing to read in high speed IO lines, above 1Mhz. SPI has odd timing requirements. Can you point to example code for this technique, or is it just a matter of using(abusing) the i2s library? And the horrible wire protocol is all too common.
I hadn't looked at the RMT peripheral before... Based on what you describe and from a quick skim of the documentation this also seems perfect for a simple logic analyzer!
