Most devs can't handle C. C++ perhaps, but I wouldn't bet on it. A lot is done in JS.
Got a tip for us?
Let us know
Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.
Anyone else a bit skeptical about Apple silicon future?
- Thread starter dapa0s
- Start date
- Sort by reaction score
I feel like you think we're disagreeing on more aspects than we actually are. I'm not saying this isn't an advantage. I'm just saying there's more to chip design than this and the chip designers should be acknowledged for their work rather than reducing it to ARM good x86 bad.
Besides, since each instruction can contain more "work" in x86 decoding 1 instruction on an ARM chip != decoding 1 instruction on x86. If your limiting factor isn't the time to decode instructions anyway, but your ALU or something else then this is an irrelevant difference. It's a meaningful difference when you are bound by the performance of decoding instructions but if it takes longer to execute one instruction than it does to figure out what to do next, well it doesn't matter much
It's not a question of whether or not devs can handle it, increasingly, many don't want to. Unless you really need that level of performance, the overhead in development and testing often isn't worth it. Most companies want to be able to iterate quickly and computing resources are much less expensive than development time and resources.
APIs that've existed for ages on iOS and macOS and dispatch work to whatever hardware is available, be it dedicated hardware on iOS and Apple Silicon Macs, T2 chips, GPUs or whatever else is available, yes. These are already widely used.
No offence intended but have you ever written code? What do you base this statement on?
C is a fairly simple language. C++ is insanely big. You can learn all of C over a weekend if you know programming already. You can spend a lifetime and not know all of C++. (by which I include stdlib.h for C and the standard template library for C++). C++ gives you a lot of tools to use to make abstractions and structure your code. It also gives you things like std::vector so you won't have to implement dynamically growing arrays yourself. But all the ways you can shoot yourself in the face with C you can do with C++ too. And more too.
Oh I recognize the business side. Problem is it leads to inferior products for the customer.
Yes I have. You're a talented person but a lot of devs couldn't handle C pointers. In C++ that became easier. Even in Objective-C people struggled with pointers in array elements. It's no coincidence most of these became structs in Swift.
Pointers exist in the exact same way in C++ though. I mean C++ also has smart pointers with the fancy-smanchy std::shared_pointer and all that jazz and instead of allocating space for your structs with malloc you can use new and delete, but C++ still has pointer arithmetic and everything C has so I struggle to imagine someone who can deal with pointers in C++ but panic when they see a C pointer. Maybe that's just me though
Oh you're right the concept is the same. In C however I recall &&&& **** . In C++ that be & *.Pointers exist in the exact same way in C++ though. I mean C++ also has smart pointers with the fancy-smanchy std::shared_pointer and all that jazz and instead of allocating space for your structs with malloc you can use new and delete, but C++ still has pointer arithmetic and everything C has so I struggle to imagine someone who can deal with pointers in C++ but panic when they see a C pointer. Maybe that's just me though
As said before you're talented.Pointers exist in the exact same way in C++ though. I mean C++ also has smart pointers with the fancy-smanchy std::shared_pointer and all that jazz and instead of allocating space for your structs with malloc you can use new and delete, but C++ still has pointer arithmetic and everything C has so I struggle to imagine someone who can deal with pointers in C++ but panic when they see a C pointer. Maybe that's just me though
"Here we get a big problem with the Intel and AMD business model. Their business models are based on selling general-purpose CPUs, which people just slot onto a large PC motherboard. Thus computer-makers can simply buy motherboards, memory, CPUs, and graphics cards from different vendors and integrate them into one solution.
But we are quickly moving away from that world. In the new SoC world, you don’t assemble physical components from different vendors. Instead, you assemble IP (intellectual property) from different vendors. You buy the design for graphics cards, CPUs, modems, IO controllers, and other things from different vendors and use that to design an SoC in-house. Then you get a foundry to manufacture this.
Now you got a big problem, because neither Intel, AMD, or Nvidia are going to license their intellectual property to Dell or HP for them to make an SoC for their machines.
Sure Intel and AMD may simply begin to sell whole finished SoCs. But what are these to contain? PC-makers may have different ideas of what they should contain. You potentially get a conflict between Intel, AMD, Microsoft, and PC-makers about what sort of specialized chips should be included because these will need software support.
For Apple this is simple. They control the whole widget. They give you, for example, the Core ML library for developers to write machine learning stuff. Whether Core ML runs on Apple’s CPU or the Neural Engine is an implementation detail developers don’t have to care about."
debugger.medium.com
But we are quickly moving away from that world. In the new SoC world, you don’t assemble physical components from different vendors. Instead, you assemble IP (intellectual property) from different vendors. You buy the design for graphics cards, CPUs, modems, IO controllers, and other things from different vendors and use that to design an SoC in-house. Then you get a foundry to manufacture this.
Now you got a big problem, because neither Intel, AMD, or Nvidia are going to license their intellectual property to Dell or HP for them to make an SoC for their machines.
Sure Intel and AMD may simply begin to sell whole finished SoCs. But what are these to contain? PC-makers may have different ideas of what they should contain. You potentially get a conflict between Intel, AMD, Microsoft, and PC-makers about what sort of specialized chips should be included because these will need software support.
For Apple this is simple. They control the whole widget. They give you, for example, the Core ML library for developers to write machine learning stuff. Whether Core ML runs on Apple’s CPU or the Neural Engine is an implementation detail developers don’t have to care about."
What Makes Apple Silicon So Fast?
Real world experience with the new Macs has sunk in. They are fast. Real fast. But why? What is the magic?
debugger.medium.com
? If the codebase you were looking at had a reference to a reference to a reference to a reference of a pointer of a pointer of a pointer of a pointer... I urge you to find the people responsible for that and slap them a few times, haha.
But no I get what you're saying. Same thing can happen in C++ but it's less likely to happen as people tend to think and code differently with the features available in C++.
Flattering. But I'm just as good at coding bugs as the next person
But no genuinely I'm better at C than I am C++. Mostly because I've used C a lot and I've not really used C++ all that much so my C++ code isn't. idiomatic C++, it's just C With Classes.
PS. Really hope I didn't come off hostile or anything earlier when I asked if you've written any code. In my world C++ programmers have always seemed like they needed to know more than C programmers because the language is so massive and has evolved so much over the past decades and C has been mostly static since C99. And you wouldn't even need to change all that much to be up to date if you were used to K&R C. So I was genuinely wondering about your statement back then, but I do see your point too - that while C++ is a bigger language with more things to learn, those language additions also help you stay away from situations where you need to more manually manage memory.
This is all part of the ebb and flow that is IT.
See, most people nowadays are either too young or don't remember the time when there was so much CPU fragmentation that different versions of various applications were written to conform with the architecture, and not standardized. For example, Firefox, Netscape, Opera, Mosaic, etc., were all written for the following CPU architectures: Linux x86, Linux x86-64, sparc (Solaris x86), sparc64 (Solaris x86-64), Cyrix, Ultrix, OSF/1 (Digital Unix), HP/UX, NetBSD, 386BSD, 486BSD, BSDi, FreeBSD, AIX, NeXT, MacOS, SunOS, Windows, and others.
Each program had to be recompiled on that architecture for it to be released, let alone supported on that architecture. In short, this fragmentation was already done before. Time caught up, to where things were getting standardized: Most of the xBSDs are gone (except for FreeBSD). All 32bit processors are gone. Solaris dropped Sparc for x86-64. DEC got bought by HP. HP barely uses HP/UX anymore. NeXT got bought by Apple. So out of all of those, the only contenders remaining are Linux, AIX, HP/UX, (Open)Solaris x64, FreeBSD, and Windows. And even with those, four of them conform to the x86-64 spec, so it is only a matter of linking against the properly compiled libraries to create the binary.
That is the flow we've had for 30 years.
The ebb is Apple going back the other way and supporting things with their own hardware internally. The software companies are simply doing the opposite again, but without all of the fragmentation we had. No more RISC, Sparc, and Mach architectures. only Silicon and x86-64, so that really isn't any fragmentation at all. Apple will be okay as long as the others have a baseline piece of hardware to do their work on, and they'll be good.
Where the issue will come in is if the Silicon architecture is publicly published, and Intel and AMD decide to make their own based off that architecture. But even that should be the same as it would conform to the spec that Apple published. If it doesn't, that would mean that Intel and AMD would be cannibalizing their own customer base by offering two of their own different products to their customer market. That would be bad for them unless they would be planning to get out of the x86 market.
BL.
Same, we buy whatever runs our software as that costs WAY more.
What effort? They've dabbled and that's about it.
Who cares? Chromebooks have even less chance of being used in my environment than Macs, and Macs basically have no chance.
I suspect licensing fee income. Doesn't matter to me in any case.
They're a chip foundry and make more than just x86 processors and RISC-V make pretty good device controllers. They'll probably sell a ton.
Who knows. Doesn't matter to me, we don't even need middle of the road video cards, so we don't buy their stuff either.
Just look at the market shares in the PC market and tell me who and what type of processors lead by a wide margin.
We need machines to run our software, that's it. fwiw, our main server is a Power9 machine, so we're not all x86, but close.
?? Laptops can come with x86 processors too, and no, we need way more than Office (though we do use it) and a browser!
Don't fret over it. It takes more to offend me. Plus I know you're a helpful person eager to improve IT and macrumors.? If the codebase you were looking at had a reference to a reference to a reference to a reference of a pointer of a pointer of a pointer of a pointer... I urge you to find the people responsible for that and slap them a few times, haha.
But no I get what you're saying. Same thing can happen in C++ but it's less likely to happen as people tend to think and code differently with the features available in C++.
Flattering. But I'm just as good at coding bugs as the next person
But no genuinely I'm better at C than I am C++. Mostly because I've used C a lot and I've not really used C++ all that much so my C++ code isn't. idiomatic C++, it's just C With Classes.
PS. Really hope I didn't come off hostile or anything earlier when I asked if you've written any code. In my world C++ programmers have always seemed like they needed to know more than C programmers because the language is so massive and has evolved so much over the past decades and C has been mostly static since C99. And you wouldn't even need to change all that much to be up to date if you were used to K&R C. So I was genuinely wondering about your statement back then, but I do see your point too - that while C++ is a bigger language with more things to learn, those language additions also help you stay away from situations where you need to more manually manage memory.
Think the point was that power consumption matters on laptops, not what architecture they run. And that a lot of laptops are effectively used as thin clients. You may run a lot of stuff on your laptop, but to a lot of folks in your organisation they may only use their laptop to SSH into a server or something like that. For that use case it doesn't matter if it runs ARM or x86 and if the ARM chip can provide 10x the battery life (just picking a random extreme number for the effect) that's a better device for the task
I know that was the point, but my point about what software it runs makes WAY more of a difference than that. That's all I'm saying, not that Arm is bad or not as power efficient as others say here, but it doesn't run what I need it to run to be considered where I work. I'm the IT manager, I know what we need to run and the budgets for everything.
Would you make the same choices if you could start from scratch? I don't know what you're running but I can imagine previous investments, personnel training, certain ERP systems pose a huge hurdle. Those budgets are monthly, quarterly, yearly, ...?
Right now with what else is available, hard to tell, maybe not with the power9 server, as that's where our ERP runs and I wouldn't mind a more mainstream ERP. Love the DB there, but that's just a personal like.
But with desktops and front end servers (and various PC device controllers), yes, I think I'd make the same choice, there's just more available to run in that space (software-wise is what I'm talking about)
lol, in consumer computer market? They dont make any of them but servers or super computers.. Even HP uses Intel, AMD, and Nvidia parts.
If you're developing specifially for Apple Silicon, rather than the APIs provided by apple which are CPU/GPU agnostic, you're probably doing development wrong, in this current century.
You're worried after the weakest AS chip ever is the only one released and it's a pretty amazing chip. The only way is up. Don't worry.
As for gaming. If you're serious about gaming on PCs you don't do so on a Mac. It really can't get much worse than it already is.
The AS future is so bright you're gonna have to wear shades when you use Macs.
As for gaming. If you're serious about gaming on PCs you don't do so on a Mac. It really can't get much worse than it already is.
The AS future is so bright you're gonna have to wear shades when you use Macs.