![[RSS]](http://tweakimg.net/g/if/v2/icons/rss_small.png){kind=icon}
![[quick]](http://tweakimg.net/g/if/icons/world_link_cropped.png){kind=icon}
PovRay and K-means
So, what type of application does clearly suit the X4600? Answering that question is probably best left up to Sun: the marketing department mentions records in a number of highly parallizable computationally intensive benchmarks: SpecFp_rate2000, SpecInt_rate2000, and SpecOmpm2001. These have been achieved under Solaris and with Suns own compiler. A number of the usual series of benchmarks (such as TPC-C en SpecJbb2005) have not been run or in any case not been published. The one that did appear is disappointing: in SAP-SD, 1650 users are served using eight 2.6GHz Opterons, worse than the 1980 or so which IBM and HP managed on four processors and also less than the score achieved on a double Clovertown: 1841. It appears then, that we are not the only ones that have (had) problems maximizing the potential of the X4600.
Armed with two benchmarks which share the characteristic with Sun's marketing department's test that they can be spread across multiple threads almost perfectly, we gave the X4600 an opportunity to prove its mettle. The first of these is ProvRay, the best-known software-based ray tracer. We chose version 3.7 beta, the first multithreaded version. The fastest time for the eight processor system was 160 seconds, some 35% quicker than the 246 seconds which were needed running on four processors. Still far from the ideal of double speed, but nevertheless the best we saw so far. The 1.6GHz Clovertown does not finish the test before 406 seconds have passed. Unfortunately the 2.66GHz version was not tested, but on the basis of the available evidence it does not appear as if it could overtake the X4600.
The second test was developed by Tweakers.net and is executed in PostgreSQL. It is an implementation of the K-means algorithm, that is meant to divide objects into groups of things which are similar. It is often used as an aid in the areas of data mining and search. The benchmark partitions 43,665 of our news items on the basis of the words which occur in them. On average, for every news item a little over a hundred characteristic words are selected. On the basis of the number of times that they appear, a 'distance' between two items can be computed. Stories that are close in terms of word usage are lumped together, and the test continues until every group has fewer than twenty members. The algorithm can be readily spread out across several threads by assigning subsets to each core.
The algorithm's scaling behaviour is illustrated nicely by Clovertown: a single thread on 1.6GHz takes 6,019 seconds, which decreases to 3883 seconds on 2.66GHz, almost perfect scaling of the performance with the clock speed. Doubling the number of threads works very well on small numbers, with more than 95% better performance for the step from one to two cores, more than 85% for the move to two cores, and more than 80% for the final transition to eight cores. In total, the program runs 6.8 times faster on 2.66Ghz and 7.2 times quicker on 1.6GHz, which is not far from the ideal of 8 times.
For the Opteron, we distinguish between Linux and Solaris. The first one yields a reasonable performance with eight cores: a time of 691 seconds may be higher than the 568 of the top model Clovertown, but not an odd result. But it is rather strange that the system needs almost twice the amount of time after going from eight to sixteen cores. Once more, we encounter an application which appears to scale well but collapses on eight sockets. A possible explanation for this is that PostgreSQL, under the intense pressure of eight dual-cores, needs to clean up its tables more often (vacuuming), which eventually has an adverse effect. However, under Solaris the picture is different again: here, a gain of 21% is achieved by adding the extra computational power. Unfortunately this is only a small comfort given the fact that the performance lags behind in absolute terms: even on 16 cores, the Opteron on Solaris needs almost four minutes more than the cheapest Clovertown.
Armed with two benchmarks which share the characteristic with Sun's marketing department's test that they can be spread across multiple threads almost perfectly, we gave the X4600 an opportunity to prove its mettle. The first of these is ProvRay, the best-known software-based ray tracer. We chose version 3.7 beta, the first multithreaded version. The fastest time for the eight processor system was 160 seconds, some 35% quicker than the 246 seconds which were needed running on four processors. Still far from the ideal of double speed, but nevertheless the best we saw so far. The 1.6GHz Clovertown does not finish the test before 406 seconds have passed. Unfortunately the 2.66GHz version was not tested, but on the basis of the available evidence it does not appear as if it could overtake the X4600.
The second test was developed by Tweakers.net and is executed in PostgreSQL. It is an implementation of the K-means algorithm, that is meant to divide objects into groups of things which are similar. It is often used as an aid in the areas of data mining and search. The benchmark partitions 43,665 of our news items on the basis of the words which occur in them. On average, for every news item a little over a hundred characteristic words are selected. On the basis of the number of times that they appear, a 'distance' between two items can be computed. Stories that are close in terms of word usage are lumped together, and the test continues until every group has fewer than twenty members. The algorithm can be readily spread out across several threads by assigning subsets to each core.
The algorithm's scaling behaviour is illustrated nicely by Clovertown: a single thread on 1.6GHz takes 6,019 seconds, which decreases to 3883 seconds on 2.66GHz, almost perfect scaling of the performance with the clock speed. Doubling the number of threads works very well on small numbers, with more than 95% better performance for the step from one to two cores, more than 85% for the move to two cores, and more than 80% for the final transition to eight cores. In total, the program runs 6.8 times faster on 2.66Ghz and 7.2 times quicker on 1.6GHz, which is not far from the ideal of 8 times.
For the Opteron, we distinguish between Linux and Solaris. The first one yields a reasonable performance with eight cores: a time of 691 seconds may be higher than the 568 of the top model Clovertown, but not an odd result. But it is rather strange that the system needs almost twice the amount of time after going from eight to sixteen cores. Once more, we encounter an application which appears to scale well but collapses on eight sockets. A possible explanation for this is that PostgreSQL, under the intense pressure of eight dual-cores, needs to clean up its tables more often (vacuuming), which eventually has an adverse effect. However, under Solaris the picture is different again: here, a gain of 21% is achieved by adding the extra computational power. Unfortunately this is only a small comfort given the fact that the performance lags behind in absolute terms: even on 16 cores, the Opteron on Solaris needs almost four minutes more than the cheapest Clovertown.
Next page (Power consumption and conclusion - 10/10)
