Exascale, What about Exalead?
December 8, 2009
The Industry Standard ran an enigmatic and short news item in an article called “Scientists, IT Community Await Exascale Computers”. The write up is a collection of statements about super fast computers. The only problem I have with an article that references a computer with 100 million cores is that I struggle with its relevance. Google chugs along quite happily with mid range, commodity hardware. The bottlenecks are well known and not resolved with a dusting of technical verbiage. There is an outfit called Exalead. Its technology is able to handle petascale challenges. So Google is in the game as is Exalead. The demonstration systems referenced in the Industry Standard article give the impression that exascale is something that wanders in deep space like a quark star. Not true. For more information, navigate to www.exalead.com.
Stephen Arnold, December 8, 2009
Oyez, oyez, Government National Mortgage Association. I was not paid to point out that I did not mortgage my soul to point out that speculation that ignores the existing exascale solutions helps me not a whit.
Comments
One Response to “Exascale, What about Exalead?”
- Subscribe to Beyond Search
Feature archive
News archive
-
Thanks Stephen for the reference. Indeed, Exalead’s original design goal was to ultimately index and search Exabyte data sets (10 power 19 bytes). Hence the company name. We’re well on our way, using commodity server technology to do this. I think there are a couple of design challenges which are not mutually exclusive. Challenge #1 is designing software that, regardless of hardware architecture, can handle that amount of data. We’re on that at Exalead. The other challenge is creating a performance/price leading architecture for that. That’s Challenge #2. Commodity hardware architectures have their strengths and weaknesses. Low design costs and high volume manufacturing keep amortized design and fixed costs low for commodity system-based architectures. On the other hand I/O inefficiencies, due to sub-optimal I/O back planes can drive system quantities up. Systems designed to solve this problem may be cost effective if the design costs, fixed costs and margins are held in check.