SoylentNews is people
SoylentNews is powered by your submissions, so send in your scoop. Only 19 submissions in the queue.
SoylentNews
On Youtube I watched a Mac user who had bought an iMac last year. It was maxed out with 40 GB of RAM costing him about $4000. He watched in disbelief how his hyper expensive iMac was being demolished by his new M1 Mac Mini, which he had paid a measly $700 for.
In real world test after test, the M1 Macs are not merely inching past top of the line Intel Macs, they are destroying them. In disbelief people have started asking how on earth this is possible?
If you are one of those people, you have come to the right place. Here I plan to break it down into digestible pieces exactly what it is that Apple has done with the M1.
Related:
What Does RISC and CISC Mean in 2020?
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
My LESLIE GORE record is BROKEN ...
(Score: 1, Insightful) by Anonymous Coward on Wednesday December 02 2020, @09:48PM
Checking for NULL isn't a malloc problem. You can eliminate all NULL checks due to malloc failure simply by making a NULL return from malloc a panic condition. NULL checks aren't even the performance hit you think, unless you're foolishly failing to factor them out of tight loops. The overhead of malloc/free is the record keeping for what's being used and what isn't. If you have a simple application that can allocate all its memory at startup, great. Otherwise you're just going to reinvent all the record keeping. Sometimes the usage pattern can be tuned to your application, (memory pools) and that's faster; but simply allocating all your memory to some global variable isn't a silver bullet. If it were, there wouldn't be any discussion. Aside from that, you may still have to interact with libraries that use NULL as a sentinel.