Thread: Opteron vs. Xeon "benchmark"
A colleague pointed me to this site tomorrow: http://tweakers.net/reviews/642/13 I can't read the language, so can't get a grip on what exactly the "benchmark" was about. Their diagrams show `Request per seconds'. What should that mean? How many connections PG accepted per second? So they measured the OS fork performance? Should that value be of any interrest? Anyone with heavy OLTP workload will use persistent connections or a connection pool in front. Do they mean TPS? That woulnd't make much sense in a CPU benchmark, as OLTP workload is typically limited by the disc subsystem. Can someone enlighten me what this site is about? -- Regards, Hannes Dorbath
Try the translation ;) http://tweakers.net/reviews/646/13 On 22-9-2006 10:32 Hannes Dorbath wrote: > A colleague pointed me to this site tomorrow: > > http://tweakers.net/reviews/642/13 > > I can't read the language, so can't get a grip on what exactly the > "benchmark" was about. > > Their diagrams show `Request per seconds'. What should that mean? How > many connections PG accepted per second? So they measured the OS fork > performance? Should that value be of any interrest? Anyone with heavy > OLTP workload will use persistent connections or a connection pool in > front. > > Do they mean TPS? That woulnd't make much sense in a CPU benchmark, as > OLTP workload is typically limited by the disc subsystem. > > Can someone enlighten me what this site is about? > >
Hello Hannes, The text above the pictures on page 13. Translated in my crappy english. The confrontation between the Opteron and Woodcrest was inevitable in this article, but who can add 1 and 1 should have known from the previous two pages that it doesn't look that good for AMD . Under loads of 25 till 100 simultaneous visitors, the Xeon performs 24% better with MSQL 4.1.20, 30% better in MySQL 5.0.20a and 37% better in PostgreSQL 8.2-dev. In short, the Socket F Opteron doesn't stand a chance, although the Woodcrest scales better and has such a high startpoint with one core, there is no chance of beating it. We can imagine that the Opteron with more memory and production hardware, would be a few % faster, but the difference with the Woodcrest is that high that we have a hard time believing that the complete picture would change that much. Regards, Nick Hannes Dorbath wrote: > A colleague pointed me to this site tomorrow: > > http://tweakers.net/reviews/642/13 > > I can't read the language, so can't get a grip on what exactly the > "benchmark" was about. > > Their diagrams show `Request per seconds'. What should that mean? How > many connections PG accepted per second? So they measured the OS fork > performance? Should that value be of any interrest? Anyone with heavy > OLTP workload will use persistent connections or a connection pool in > front. > > Do they mean TPS? That woulnd't make much sense in a CPU benchmark, as > OLTP workload is typically limited by the disc subsystem. > > Can someone enlighten me what this site is about? > >
On Sep 22, 2006, at 4:58 AM, nicky wrote: > till 100 simultaneous visitors, the Xeon performs 24% better with > MSQL 4.1.20, 30% better in MySQL 5.0.20a and 37% better in > PostgreSQL 8.2-dev. In short, the Socket F Opteron doesn't stand a > chance, although the Woodcrest scales better and has such a high > startpoint with one core, there is no chance of beating it. We so you think AMD is just sitting around twiddling their thumbs and saying "well, time to give up since Intel is faster today". no. there will be back-and forth between these two vendors to our benefit. I would expect next-gen AMD chips to be faster than the intels. If not, then perhaps they *should* give up :-)
Attachment
On 22-9-2006 22:34 Vivek Khera wrote: > so you think AMD is just sitting around twiddling their thumbs and > saying "well, time to give up since Intel is faster today". no. there > will be back-and forth between these two vendors to our benefit. I > would expect next-gen AMD chips to be faster than the intels. If not, > then perhaps they *should* give up :-) Please read the english translation of that article I gave earlier today. Than you can see the set-up and that its a bit childish to quote "benchmark" as you did in the title of this thread. All the answers in your initial mail are answered in the article, and as said, there is an english translation of the dutch article you posted. What you conclude from that translation is not the conclusion of the article, just that AMD has *no* answer at this time and won't have for at least somewhere in 2007 when their K8L will hit the market. But the K8L is not likely to be as much faster as the Opteron was to the first Xeon's, if at all faster... If you're an AMD-fan, by all means, buy their products, those processors are indeed fast and you can build decent servers with them. But don't rule out Intel, just because with previous processors they were the slower player ;) Best regards, Arjen van der Meijden
On Fri, Sep 22, 2006 at 11:50:47PM +0200, Arjen van der Meijden wrote:
> If you're an AMD-fan, by all means, buy their products, those processors
> are indeed fast and you can build decent servers with them. But don't
> rule out Intel, just because with previous processors they were the
> slower player ;)
Yep. From what I understand, Intel is 8 to 10 times the size of AMD.
It's somewhat amazing that AMD even competes, and excellent for us, the
consumer, that they compete well, ensuring that we get very fast
computers, for amazingly low prices.
But Intel isn't crashing down any time soon. Perhaps they became a little
lazy, and made a few mistakes. AMD is forcing them to clean up.
May the competition continue... :-)
Cheers,
mark
--
mark@mielke.cc / markm@ncf.ca / markm@nortel.com __________________________
. . _ ._ . . .__ . . ._. .__ . . . .__ | Neighbourhood Coder
|\/| |_| |_| |/ |_ |\/| | |_ | |/ |_ |
| | | | | \ | \ |__ . | | .|. |__ |__ | \ |__ | Ottawa, Ontario, Canada
One ring to rule them all, one ring to find them, one ring to bring them all
and in the darkness bind them...
http://mark.mielke.cc/
I find the benchmark much more interesting in comparing PostgreSQL to MySQL than Intel to AMD. It might be as biased as other "benchmarks" but it shows clearly something that a lot of PostgreSQL user always thought: MySQL gives up on concurrency ... it just doesn't scale well. cug On 9/23/06, mark@mark.mielke.cc <mark@mark.mielke.cc> wrote: > Yep. From what I understand, Intel is 8 to 10 times the size of AMD. > > It's somewhat amazing that AMD even competes, and excellent for us, the > consumer, that they compete well, ensuring that we get very fast > computers, for amazingly low prices. > > But Intel isn't crashing down any time soon. Perhaps they became a little > lazy, and made a few mistakes. AMD is forcing them to clean up. > > May the competition continue... :-) > > Cheers, > mark -- PostgreSQL Bootcamp, Big Nerd Ranch Europe, Nov 2006 http://www.bignerdranch.com/news/2006-08-21.shtml
On 23-Sep-06, at 9:00 AM, Guido Neitzer wrote: > I find the benchmark much more interesting in comparing PostgreSQL to > MySQL than Intel to AMD. It might be as biased as other "benchmarks" > but it shows clearly something that a lot of PostgreSQL user always > thought: MySQL gives up on concurrency ... it just doesn't scale well. > > cug > Before you get too carried away with this benchmark, you should review the previous comments on this thread. Not that I don't agree, but lets put things in perspective. 1) The database fits entirely in memory, so this is really only testing CPU, not I/O which should be taken into account IMO 2) The machines were not "equal" The AMD boxes did not have as much ram. DAVE > > On 9/23/06, mark@mark.mielke.cc <mark@mark.mielke.cc> wrote: >> Yep. From what I understand, Intel is 8 to 10 times the size of AMD. >> >> It's somewhat amazing that AMD even competes, and excellent for >> us, the >> consumer, that they compete well, ensuring that we get very fast >> computers, for amazingly low prices. >> >> But Intel isn't crashing down any time soon. Perhaps they became a >> little >> lazy, and made a few mistakes. AMD is forcing them to clean up. >> >> May the competition continue... :-) >> >> Cheers, >> mark > > > > -- > PostgreSQL Bootcamp, Big Nerd Ranch Europe, Nov 2006 > http://www.bignerdranch.com/news/2006-08-21.shtml > > ---------------------------(end of > broadcast)--------------------------- > TIP 6: explain analyze is your friend >
On 9/23/06, Dave Cramer <pg@fastcrypt.com> wrote: > 1) The database fits entirely in memory, so this is really only > testing CPU, not I/O which should be taken into account IMO I don't think this really is a reason that MySQL broke down on ten or more concurrent connections. The RAM might be, but I don't think so too in this case as it represents exactly what we have seen in similar tests. MySQL performs quite well on easy queries and not so much concurrency. We don't have that case very often in my company ... we have at least ten to twenty connections to the db performing statements. And we have some fairly complex statements running very often. Nevertheless - a benchmark is a benchmark. Nothing else. We prefer PostgreSQL for other reasons then higher performance (which it has for lots of situations). cug -- PostgreSQL Bootcamp, Big Nerd Ranch Europe, Nov 2006 http://www.bignerdranch.com/news/2006-08-21.shtml
On 23-Sep-06, at 9:49 AM, Guido Neitzer wrote: > On 9/23/06, Dave Cramer <pg@fastcrypt.com> wrote: > >> 1) The database fits entirely in memory, so this is really only >> testing CPU, not I/O which should be taken into account IMO > > I don't think this really is a reason that MySQL broke down on ten or > more concurrent connections. The RAM might be, but I don't think so > too in this case as it represents exactly what we have seen in similar > tests. MySQL performs quite well on easy queries and not so much > concurrency. We don't have that case very often in my company ... we > have at least ten to twenty connections to the db performing > statements. And we have some fairly complex statements running very > often. > > Nevertheless - a benchmark is a benchmark. Nothing else. We prefer > PostgreSQL for other reasons then higher performance (which it has for > lots of situations). I should make myself clear. I like the results of the benchmark. But I wanted to keep things in perspective. Dave > > cug > > -- > PostgreSQL Bootcamp, Big Nerd Ranch Europe, Nov 2006 > http://www.bignerdranch.com/news/2006-08-21.shtml > > ---------------------------(end of > broadcast)--------------------------- > TIP 1: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that > your > message can get through to the mailing list cleanly >