To: engineer who wrote (133331 ) 12/21/2016 8:06:45 PM From: Qurious 4 RecommendationsRecommended By Lance Bredvold lml waitwatchwander xr1
Read Replies (2) | Respond to of 196475 I try to supply only the most fundamental information, with the expectation that if it is important enough you guys will use that as the starting point to do your own research and reach your own conclusions. In a time of fake news, I think this is the best approach. That said, I think I should try to untangle several confusions re Q's 48 core server chip offering. 1) Linux. The data center/server market is even more of a monopoly than the PC, except in this case it is Lintel (Linux+Intel) rather than Wintel (Windows+Intel). Everyone (Amazon, Google, Facebook...) runs on some version of Linux (typically RHEL, for Redhat Enterperise Linux, or some proprietary variant). So Q needs Linux, period. And Q+Linux will have to compete against Intel+Linux, except Intel has spent the past 10 years fine-tuning their version of Linux to support increasing number of cores (currently up to 24). They have contributed their 8 cores version back to the Linux community, but have kept the >8 core enhancements to themselves.Draw your own conclusions. [Btw the handset mkt is also an OS monopoly. Android runs on Linux; iOS runs on FreeBSD --both variants of Unix.] 2) SMP. When I say every data center/server runs Linux, I mean every one of them runs SMP Linux. There is no foreseeable alternative to Linux or to SMP. Not because SMP Linux is great. It is not. But because software is one example of a self-organizing matrix where software bits large and small bind and continue to bind to a common core, until the point is reached where it becomes a single organism. In the case of Linux, there is another factor at play, which is that it is supposed to be open-source, which is seen as a great theoretical advantage for adopters and supporters. 3) Others. For a specific, dedicated application (e.g. page search) it is possible to design your own heterogeneous (i.e. non-SMP) system, with your own custom, de minimus OS. However, this is unlikely, and in any event, completely runs contrary to the raison d'etre for multicore in the 1st place. Unlikely, because the entire computer industry runs on the assumption that hardware is cheap and software life cycle cost is high. So, better to buy newer, faster hardware than invest to make software run on slow hardware. This is co-dependent with Moore's Law. To support this approach, we see the move to multicore, as it is deemed cheaper to replicate a lot of cores than to pack the same processing power in single core cpu. But that's in theory. In practice, there is a lot of monumental syatem stumbling blocks to achieving scalability (meaning 48 cores = near 48x performance of 1 core). My earlier posted links had to do with this issue of scalability. 3) I do not know what engineer means by super-threaded. In common usage, super-threading is about minimal incremental hardware support at the cpu level (i.e. inside each core) to support better virtual multi-threading (with 1 core). It is below the core level, and has nothing to do with utilization of the 48 cores. The entire point of multi-core is to enable physical multi-threading (or even finer grain parallelism). With physical multi-core threading, why bother with virtual super-threading? 4) For 48-core cpus which are deployed in any large system involving thousands of such units, it would be insane to run the cores as anything other than in SMP mode. To try to use the cores in a heterogeneous manner would make no architectural sense. If one were to adopt a heterogeneous model, fine, but do it between different clusters of 48-cores, not between cores inside a single 48 core unit. A 48 core CPU is architecturally for all purposes meant to be a single CPU. Everything aside, just watch how the industry is going to benchmark Q against Intel. If Q comes up short running tests under SMP Linux, it is cooked. It does not matter how well it performs under some custom test bench. Think about it. 5) engineer mentioned GPU. GPU is a totally different scenario. Compute intensive algorithms such as photo-realistic rendering are easily vectorizable. The parallelism is at the algorithmic level, very fine grained. There is no way of achieving this granularity in general purpose computing, because very few applications are vectorizable. Even if possible, it would require extreme hand-optimization. I can foresee machine learning as one example where fine grained vectorizing is both possible and helpful. But this is outside the scope of our concerns re Q's 48 core entry into the *server* mkt.