In some applications like HFT being 10% slower is the same as not working at all. I was responding specifically to the claim that "As others have said, most developers don't (need to) care about what processor they are designing for anymore".
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 agree that you will always be running the OS, other apps maybe not. As for the cache size varying, that is certainly true but if you pick the CPU you use, you will know the cache size.
Mkay, define the smallest time difference there can be between 2 trades and then check how many instructions any current CPU can do in that time......
No, there are a lot of differences. Using a web view is optional, you can also use only native code, use a cross-platform UI layer over native components, and mix-and-match the combinations, per each platform. My Blazor web code also doesn't run via an internal web-server, but natively by the .NET runtime. Unlike Electron you don't embed and instantiate a Chromium (and Javscript engine) for each instance, it uses the native machine's browser component, among many other things. It's much lighter-weight, more flexible, higher-performance, and more flexible than Electron.
Last edited:
this is something every guy in processor industry knows since M1’s worldwide presentation
There are no doubts! Apple did the transition as soon as they could, this means there are more leaps to coming next years.
moreover, Intel could make similar or faster processors for workstations, but laptops are going to be ARM yes or yes
No, the problem is the trading software is running an OS which just has too much overhead to accomplish what they wanted. The FPGA just shortcuts execution of a specific task. Not even a RTOS can compete with that. Remember they are competing with other traders so no matter how fast it goes, it needs to be faster than "the other guys".
Not any jobs our PC's do, though I definitely know those jobs exist and one should buy the right computer for the job! Our Power9 gets those tasks.
Did you ever go though this June 2021 thread?
Alleged Intel source: "Apple scares us more than AMD"
So, while listening to leaks on the PC side of the street, "Moore's Law is Dead" had a few interesting quotes that he purports to be from a source within Intel. Normally, I wouldn't give much credence to inside sources if it were from someplace incompetent like Digitimes, but I've been watching...
forums.macrumors.com
Sure, but the templates thing was just one example. Point was more just that I generally find the C++ community can be a bit exclusionary at times. That's again not a dig at anyone, just my personal experiences and only online. In person everyone's lovely. But even Bjarne Stroustrup seemed to think it was a bit of a problem last I saw him. At least he showed a lot of concern for getting new people involved with an ever more complex language like C++ and making the environment nice for them to come into.
Swift is great. Presently my favourite language too. And yeah, F# is basically the .NET OCaml
Truth be told I don't like OCaml all that much. It's got a design that makes some things just super simple to do, but it also feels like it makes other things really hard to do. Last time I used it I made a compiler with it (compiled to LLVM so Chris Lattner really has been a hero for me, both Swift and LLVM ) it was pretty good for that cause it was fairly easy to do things in a pretty functional manner and really utilise pattern matching heavily. The project I am working on now with OCaml is something completely different though; Distributed systems code. So far I miss C which isn't a great sign, haha. But the university would like it done in OCaml because the goal is to do formal verification on implementations of advanced distributed systems algorithms and we have a lot of tooling in OCaml - whole thing partially funded by Amazon. So yeah that's the fun I get up to haha; But no Swift is great and while I haven't experimented much with it yet the new structured concurrency model looks pretty solid. Hopefully it lives up to the name and does for concurrency what structured programming did to programming in general. I'd argue that in a great deal of cases you can even do all this in a portable way, making the amount of developers who "need" to worry about this an even smaller subset of the already small subset who do write code to such a performance standard that 10% slower == not working at all.
Though I mean I guess it depends what we mean when we say caring about the hardware it runs on. I've never written code for HFT or anything similar to that - but I have code where I consider the platform it's likely to run on. It *will* run on any chip but it's tuned for some assumptions - Well, I say "any chip" - come to think of it; If you send data over a socket on a big endian chip and read it on a little endian chip do you need to swap the ordering yourself or does the socket layer enforce the ordering? Cause if you need to worry about that, then some of my stuff only works when machines have the same endianness, haha. But ARM and x86 are both little endian anyway. Think the only code I've ever written that's x86 specific is the OS I made for my bachelor project, and the final part of the compiler I made - And the final part wasn't really necessary. We already had LLVM-IR so we could just pass that to LLVM and we'd be done. We only made a backend as a learning exercise.
Some Metal code I've written will work optimally if you can assume a minimum threadGroupSize being supported by the GPU hardware. Similarly you may utilise AVX and have no NEON/SVE alternative because you mainly target x86 chips with the relevant extensions - but whatever the case; For the consumer devices Apple is making, the most important factor is "will it run" so I don't see any of these considerations to be a hurdle for developer adoption of the Apple Silicon platform
Sure, but the templates thing was just one example. Point was more just that I generally find the C++ community can be a bit exclusionary at times. That's again not a dig at anyone, just my personal experiences and only online. In person everyone's lovely. But even Bjarne Stroustrup seemed to think it was a bit of a problem last I saw him. At least he showed a lot of concern for getting new people involved with an ever more complex language like C++ and making the environment nice for them to come into.
Swift is great. Presently my favourite language too. And yeah, F# is basically the .NET OCaml
I'd argue that in a great deal of cases you can even do all this in a portable way, making the amount of developers who "need" to worry about this an even smaller subset of the already small subset who do write code to such a performance standard that 10% slower == not working at all.
Though I mean I guess it depends what we mean when we say caring about the hardware it runs on. I've never written code for HFT or anything similar to that - but I have code where I consider the platform it's likely to run on. It *will* run on any chip but it's tuned for some assumptions - Well, I say "any chip" - come to think of it; If you send data over a socket on a big endian chip and read it on a little endian chip do you need to swap the ordering yourself or does the socket layer enforce the ordering? Cause if you need to worry about that, then some of my stuff only works when machines have the same endianness, haha. But ARM and x86 are both little endian anyway. Think the only code I've ever written that's x86 specific is the OS I made for my bachelor project, and the final part of the compiler I made - And the final part wasn't really necessary. We already had LLVM-IR so we could just pass that to LLVM and we'd be done. We only made a backend as a learning exercise.
Some Metal code I've written will work optimally if you can assume a minimum threadGroupSize being supported by the GPU hardware. Similarly you may utilise AVX and have no NEON/SVE alternative because you mainly target x86 chips with the relevant extensions - but whatever the case; For the consumer devices Apple is making, the most important factor is "will it run" so I don't see any of these considerations to be a hurdle for developer adoption of the Apple Silicon platform
Sockets don’t automatically resolve endianness. Usually what you do is use macros (htonl(), etc.) to send things in an agreed-upon format. You are just sending bytes, anyway (if you are operating at the lowest level), so it all depends on what functions you are using to write values into the socket and receive them.
With the draconian Windows 11 specs seem to lock non-Intel Macs so most gamers on AMD machines will have to stay on 10! To bad about that fact!
And the bold goes back to your goal post shift. That is where you are wrong. You made such a broad claim and have been called out on that claim that now you have shifted your line in the sand to maintain your stance. That is the problem here, and even that has been called out:
Good points here. I didn't even bring in Rasberry Pi, which Broadcom makes, and while are SoC, they are geared to the consumer market. So even that kills the final argument.
With that said, this part is completely buried. And like I said before about Silicon, if these other companies can make and produce their own CPUs for over the past 30 to 40 years, with all said fragmentation and contraction, and still continue to make them to this day, Apple Silicon is in no danger of being made obsolete by any other CPU manufacturer.
BL.
Figured as much. The code I've worked with at the socket layer have all just been on homogenous machines so it hasn't really mattered.
Thanks for confirming it
“Catch up” is the wrong framing. Apple is the one that caught up more or less to Intel and AMD, not the other way around. Apple is making CPUs that are legitimately on par with high-end stuff. Right now AMD’s architecture is the most powerful, but all three companies have very similar, very high-end CPUs.
Apple includes a bunch of hardware separate from the CPU and GPU… Arm is doing some of that also, as is I think Intel, and I don’t know how well any of that hardware is ever going to be used by anyone but like Apple for their own programs. It seems somewhat dubious to me, I would rather have more or bigger CPUs, bigger GPUs that can be used by all programs.
AMD and Intel need to catch up with Apple in performance/watt. If they don’t, the fact that they can sell CPUs that are 5% faster but require a nuclear reactor to power up and an A/C unit to cool isn’t going to do them much good.
Nope, everything will be fine.
I know, but someone else would probably be better, he's already trying to do too much.