Comments on: Big Computer Brains Need Big Memory Bandwidth

By: Kontör

Kontör — Sun, 16 Aug 2009 22:03:03 +0000

Good works Thanks from turkey

By: james braselton

james braselton — Sun, 31 May 2009 18:54:03 +0000

HI THERE WELL APLE HAS A MAC PRO WITH A 8 CORE CPU 32 GEGABYTES OF RAM AND UP TOO 4 TERABYTES OF STORAGE OR OPTIONAL 10,000 AND 15,000 RPM HARD DRIVES FOR FASTER ACESS

By: james braselton

james braselton — Sun, 31 May 2009 18:54:03 +0000

HI THERE WELL APLE HAS A MAC PRO WITH A 8 CORE CPU 32 GEGABYTES OF RAM AND UP TOO 4 TERABYTES OF STORAGE OR OPTIONAL 10,000 AND 15,000 RPM HARD DRIVES FOR FASTER ACESS

By: Netbook Chips Create a Low-Power Cloud — MIT Technology Review — GigaOM Pro

Thu, 28 May 2009 10:44:52 +0000

[...] shrinking the environmental footprint of computing. We’re taxing current technology, from the silicon to the software, with massive data demands, and technology like this is a piece of the solution, [...]

By: Why You Should Care About Intel’s New Server Chip

Why You Should Care About Intel’s New Server Chip — Mon, 30 Mar 2009 22:15:45 +0000

[...] more information to process from the memory. Under Intel’s previous architecture, they had to access that memory outside of the chip — and do it one by one. Intel has addressed this by including integrated memory on the latest [...]

By: Cisco’s Data Center Play Reinvents The Server

Cisco’s Data Center Play Reinvents The Server — Mon, 16 Mar 2009 19:20:42 +0000

[...] Intel processors, which have a technology used to speed up access to memory at the chip level as a way to reduce computation bottlenecks associated with multicore [...]

By: John

John — Sun, 08 Mar 2009 18:33:21 +0000

The IO-memory-CPU bottleneck was exactly why Map/Reduce got so popular. After a point, it doesn’t matter how fast your CPU is, you just can’t ship that much data to the processor. So instead of worrying about shipping the data faster on better hardware (where the cost is exponential to performance), the solution is to chunk up the data and send it to N cheap processors, achieving near-linear performance. While this is a great solution to build a dotcom company, it’s a huge blow to hardware research, since people are taking a step backwards towards commodity hardware.

Glad to see some steps in the right direction here.

By: Alan Wilensky

Alan Wilensky — Sat, 07 Mar 2009 17:45:42 +0000

In the days of LSI-11 (PDP 11 on a board) we had SMP VME cubes running multithreaded Pascal. 10 CPU’s for a lab realtime Chromatography system. I wrote the FORTH executive with native OS threads. Pend and Unpend processes.

I said to one of the geniuses: “You guys can’t see the big product picture like I can, but I can;t see the Multi-threading landmines”. So one real genius took my code, which was in production and just about real world bullet proof, and read the listing and ran coverage analysis. He came to me:

“This module deadlocks under these rare circumstances”. Mmm……I didn;t see that, It had never happened. I took it up with the Founders. “My production code has a rare potential SMP deadlock that was not foreseeable at design time, it will cost x man hours to modify”.

“Shit, no way”, said the boss, ” it will never come to pass”. “ok”, I said, “Your company”.

The system deadlocked and returned bad production data the next day for a major client. In my defense, I was 25 at the time, and new to threaded applications, and my code boundaries were interdependent with the peripheral group with the geniuses who were CS and Chem grads.

Beware the threads. More cores, diminishing returns until the compilers and JITS and can take whatever we throw and make the best of say, 8-24 cores.

By: Frank Miller

Frank Miller — Sat, 07 Mar 2009 16:33:01 +0000

Well put Alan. Programming has always been the biggest Achilles Heel of multiprocessors. SMP has been around for decades and decades. Countless papers have been written about the memory bandwidth and its closely related cousin, inter-processor communications, for years and years. These problems are very well understood. What has not progresses as quickly has been software technology. We have a hard enough time getting scantily trained programmers to write simple event loops for Windows. Something is going to have to be put in place that allows these non-academic coders to write code quickly without having to worry about cache coherence and mutual exclusion and memory and I/O bandwidth. Once that is in place, the smart people can go off and optimize that. But I don’t see the programming problem going away anytime soon.

By: Alan Wilensky

Alan Wilensky — Sat, 07 Mar 2009 04:39:02 +0000

More cores need better threading models that do not require programmers to think too much about semaphores and pending / unpending processes. We are WAY behind the curve in native code compilation for anything beyond four cores.

This is a far more pressing issue than inter-core communication, which can be readily addressed with on chip caches and registers.