These days, common practice of Licensing Enterprise SW for Servers is cost-per/core basis. ARM throughput is less than Intel throughput, on per/core basis. That means, we need more ARM cores for same job, thus increasing SW cost.
Cost-Per/Cycle model also not uniform, because, Intel processors do more operations per cycle than ARM. May be Cost-Per/GFLOP is slightly better?
Is an NVIDIA's Fermi 512-core GPU treated as 1-core, or, god-forbid, 512-core?
With Server HW changing from simple CPU core-count model towards custom-processors or GPU, these licensing models may also be changing.
I'm curious where your optimism comes from. for instance, are you assuming some kind of breakthrough in cache effectiveness, or do you have some "server" workload which is not IO-intensive? the classic example of cache-friendly workloads is, of course, GPUs, but surely that's not the direction you're thinking.
current arm systems are moderately hobbled by their low-power, low-width memory systems, even simply 4-core versions. it's hard to imagine how one could expect to put 25x more compute on chip without requiring an unreasonably wide memory system.
ARM processors scale horizontally very well and they are cheaper per computing hour. I'm certain we're going to have 1U, 100+ 64bit core systems that are 90 percent more energy efficient in 2K14.
This will be an interesting battle to watch - Samsung vs. Intel mano-a-mano. No longer the little guys trying to land a smooth pebble between Intel's eyes - this is a giant taking on another - both with deep pockets, their own fabs and Samsung has access to technology that Intel does not - namely DRAM, Flash etc.
I wonder how long it is going to take Samsung to come out with a part. Do they have an architecture license or are they just using ARM's cores.
Blog Doing Math in FPGAs Tom Burke 16 comments For a recent project, I explored doing "real" (that is, non-integer) math on a Spartan 3 FPGA. FPGAs, by their nature, do integer math. That is, there's no floating-point ...