Multi Core Chips and Search Performance
November 10, 2008
Most enterprise search systems hit a wall sooner or later. The vendors will suggest that the problem is the hardware, not their software. Server vendors will recommend faster gizmos, everything from routers to CPUs. The fix for most slugging search and content processing systems is to throw more hardware at the problem. One vendor has wrangled an investment from a chip maker. The idea is that with the chip maker’s hardware engineers working with the search vendors engineers, performance will be improved. Other vendors surf on Intel’s hot new CPUs. The problem is that the CPU is not often the problem with search system performance. If you are waiting on Intel’s multi core CPUs in order to turbo charge your enterprise search system, you will want to read IEEE Spectrum’s article “Multicore Is Bad News for Supercomputers” here. The key point in the article for me was this passage that asserts scientists
expect that supercomputer programmers will either turn off the extra cores or use them for something ancillary to the main problem. At the heart of the trouble is the so-called memory wall—the growing disparity between how fast a CPU can operate on data and how fast it can get the data it needs. Although the number of cores per processor is increasing, the number of connections from the chip to the rest of the computer is not. So keeping all the cores fed with data is a problem.
Search systems can be made to deliver speedy content processing, faster index updates, and subsecond query processing and results delivery. But to get the system to run like a goose before Thanksgiving dinner, system administrators have to do more than plugging in more servers, adding faster storage devices, and loading up motherboards with random access memory. What’s this mean for search vendors with computationally intensive systems that chew through hours and days indexing content and updating the master index? Not much. Performance will continue to creep up until engineers crack the problem of getting other parts of a server to keep up with the hot new CPUs. Slow search systems will probably remain, well, slow for the foreseeable future.
Stephen Arnold, November 10, 2008
Comments
4 Responses to “Multi Core Chips and Search Performance”
-
- Subscribe to Beyond Search
Feature archive
News archive
-
[…] * Multi Core Chips and Search Performance […]
Well, that’s why we found the Sun Fire X4600 (http://www.sun.com/servers/x64/x4600/) or Sun Fire X4440 (http://www.sun.com/servers/x64/x4440/) to be by far superior to other systems in the market. With properly designed search platforms like FAST that rely on numerous concurrent processes, and with high-performance RAM access (disks are usually not an issue in these servers), performance scales extremely well. A 32-core system with fast disks and sufficient RAM is a nice building block for demanding Enterprise and Federal Intelligence applications.
Cheers,
–Jürgen
Jurgen Wagner,
Sun hardware can be expensive, right? The search vendors that impress me are those who deliver solid performance on commodity hardware; for example, Google and Exalead. I used to be fond of Sun equipment. We used it for the original FirstGov.gov index of the US Federal government content. But the certification delays, the slow delivery of some devices, and the cost made me think commodity servers. You are fortunate that your customers are not price sensitive.
Stephen Arnold, November 10, 2008
Ha! You have customers who are not price-sensitive?
In fact, Sun hardware with SPARC processors is not the cheapest… however, the two systems I mentioned are x64 servers and pricewise rather competitive in the market. If you look for comparable systems from Dell, HP or IBM, you’d pay more. Noname boxes are not an option. The Sun x64 boxes are well-priced, quite performant, and have some nifty management gadgets. The Sun x64 boxes *are* commodity machines.
As for decent search performance on standard hardware, I would only count two companies in: FAST and Exalead.
Cheers,
–Jürgen