4 ms·
OK, let's go with your analogy. Five days a week you drive fifteen miles to work over roads constrained by traffic, getting up to 60MPH for two minutes and spe
by dsr_ 8y ago
OK, let's go with your analogy.
Five days a week you drive fifteen miles to work over roads constrained by traffic, getting up to 60MPH for two minutes and spending the rest of the trip at 0-30. On weekends you sometimes drive two hours to visit friends or go to a special event.
The fact is that the Honda is much more appropriate for your life than a Bugatti; 5 days a week you don't do anything that the Accord can't do, and on weekends you could take the money you saved by not buying the Bugatti and rent a Corvette or a Ferrari, and still come out ahead.
Most desktops and laptops spend 5 days a week being idle and waiting on RAM, SSDs, spinning disks, or network data... or worse, waiting for human input. During that time, you might as well have a cheap ARM. When you ask for peak power, mostly you could rely on an outboard GPU.
- 666lumberjack 8y agoThis is an argument for 'ARM chips are a viable CPU option in consumer laptops/desktops', but not for the title's original claim.
- benj111 8y agoI think its a very interesting analogy actually, even if OT. The Bugatti has higher performance but for 90% of people isn't the better car. How long before Intel paint themselves into a corner by going for performance to justify their prices, when everyone just needs a bog standard ARM?
- dsr_ 8y agoThe title's original claim is reasonably supported in the article. I'm pointing out that even if ARM development mysteriously stops making gains against x86 development, it's entirely reasonable to think that Apple might announce that the next revision of OS X has an ARM version that runs on their new 16 hour Macbook Air and their new 14 hour Macbook.
- 666lumberjack 8y agoI confess, I hadn't finished reading the original article when I posted my previous comment so I was operating under the assumption that ARM single-core performance was significantly further from parity than it apparently is. My original objection was that an external GPU can't shield you from lag and unresponsiveness in normal, everyday (ie. not designed to take advantage of GPU compute) software, but if the single core performance delta between an A12 and a reasonably recent desktop i7 is genuinely only 20% then that's not an issue.
- _red 8y agoMy company does some embedded work. The problem with your analogy is that edge-cases drive CPU purchase decisions far more often than you would normally think. A simple example: You have designed an ATM using a lower powered ARM CPU. 99.9% of the use-cases never tax the CPU beyond 30%. However, in specific cases where the ATM must simultaneously access the bill dispenser, printer, and note acceptor the hardware interrupts overwhelm the CPU and leads to 2-3 secs of "CPU lock". After those 3 secs, everything returns to normal. The problem is that the bill dispenser protocol only allows for 1000ms in delay in ack to messages, thus when this situation occurs, the lag is longer than the protocol allows, so it errors out and FUBARs the entire transaction. In this case, even though this only occurs .1% of the time, the existence of this edge-case will mandate that you not use this specific CPU. Spoken another way: The ongoing issue of certain edge-cases will cost much more in the long term, than the extra $50 for a different CPU.
- lsllc 8y agoHaving built exactly this kind of thing, a decent ARM CPU is more than capable of running these things together. Network (TLS encryption), bill stacker over MDB (which requires continuous polling otherwise the devices shut down), credit card swipe/NFC, keyboard, display, receipt printer (USB) and dispenser. Plenty of horse power left in both ARM Cortex-A8 and MIPS 24Kc configurations running Linux.
- _red 8y agoGreat. But you seem to have missed that I was just providing an example. However, to further the requirements. These days many people throw around the term "ATM" sort of indiscriminately. So, they call everything from a simple 3rd party cash dispensing kiosk to full-on bank automation centers "ATM's". The problem is, that for a simple cask dispensing kiosk, you may be totally correct. Linux + ARM may work fine. However, the more functionality this device is suppose to have (ie. do 90% of the functions of a real bank teller: deposit checks, cash checks, etc), then the more these edge-cases become an issue. Because of this tight integration with backend banking system, and regulatory requirements, these edge cases will become magnified (i.e. who says you can use linux?). Additionally, since all other players in this market also have to deal with all these issues, the $50 difference in CPU cost is totally absorbed into the rather high-dollar price tag associated with this automated teller.