Re: Microsoft destroys TPC-C records!

From: Don Macpherson <nearly-donmac_at_almost-erols.com>
Date: Wed, 23 Feb 2000 06:23:19 GMT
Message-ID: <r1Ls4.20919$gW5.99014@typhoon.southeast.rr.com>

"Christopher Browne" <cbbrowne_at_news.hex.net> wrote in message news:JQIs4.12022$Pa1.291907_at_news6.giganews.com...
> Centuries ago, Nostradamus foresaw a time when Don Macpherson would say:
> >"Raymond N Shwake" <rshwake_at_rsxtech.atww.org> wrote in message
> >news:Fq5u8x.40J_at_rsxtech.atww.org...
> >[snip]
> >>
> >> And of course, that means the customer has purchased *twelve*
> >> licenses for Win 2000 Advanced Server, not to mention the associated
> >> *client* licenses, and will have to maintain twelve servers.
> >
> >One of your implications is that of the supposed expense of the licences.
> >The total of all of these is supposed to be included in the costed
> >configuration, which calculates as approx 1/3 of the previous winner.
> >Is that a problem?
> >
> >Saving $8 million dollars still sounds like a saving to senior
management.

>

> *Sounds like* is right. The costing associated with these benchmarks
> includes a sizable host of things including software licenses,
> hardware, and, I believe, service contracts.

It does.

>

> As a result, licensing costs *are* controlled for in the calculations.

>

> A valid conclusion would be that "ceteris paribus," even if there is
> an increase in licensing costs, if there is a greater decrease in
> hardware and service contract costs, this can still be a net savings.
>

And your point is?
(That something other than the "bottom line" is being measured?)

> >It looks like we may be about to see some price competition for the
> >highend market.

>

> That is less obvious. It assumes that the functionality is truly
> equivalent.

And you propose that all problems require the same functionally in their solution?

[snip]

>

> This corresponds *directly* to the notions that:
> a) Communications between threads within a single process can be
> extremely cheap.
> b) IPC between processes on the same host is fairly cheap.
> c) IPC between processes on different hosts requires some degree of
> synchronization across the network, and can be hundreds of times
> slower than a) or b).

I would agree.

>

> Apparently Microsoft was able to partition TPC/C into subproblems that
> largely involve local host IPC. In real world problems that require
> more communication between hosts, the cost goes up...

They used 12 servers, which is why the original poster cited the expense of the licences.
You lost me when you stated that the solution in question involved 'local host IPC' to 12 different hosts.
(Assuming you meant either a) or b) above in your definition of 'local host IPC')
Either it was local or it was remote. It seems difficult that it could be "local" when it went to a different server.

In some respects, though, its like Oracle's innovation of materialized views for the now-defunct TPC-D.
(it has great benefits to the benchmark, and benefit to the users of that particular technology)

Is either of these technologies necessarily bad?

Don Macpherson Received on Wed Feb 23 2000 - 00:23:19 CST