Re: Cluster computing drawbacks

In article <dcdrk8$j7e$1@xxxxxxxxxxxx>, Randy <joe@xxxxxxxxxxxxxxx> wrote:

>"which means that they all communicate at the same time" implies that
>all processes send each other data concurrently, in lockstep.

Ah. When you said "same data", I was thinking you were talking about
the same data, i.e. a collective operation.

> I'm
> countering that assertion, asserting that many parallel applications do
> not do this, although most HPC benchmarks probably do (like random
> ring's paired synchronous handshakes).

Many HPC applications do behave as I've said; it's not just a
benchmark special. For example, all spatially-decomposed stencil
algorithms work that way. That's an extremely large class of
applications. I also know of applications that don't behave like
this.

>You know, Greg, I suspect you piss off a lot of potential customers
>unnecessarily by arguing for argument's sake, like this.

Indeed, that's why we have marketing & sales people. But if I thought
I was arguing for argument's sake, I wouldn't bother to post. I give
you the benefit of the doubt; how about being more civil and giving me
that courtesy, too?

> SMP is an
> imprecise term that by convention refers only to cache coherent shared
> memory multiprocessor systems that share a snoopy bus.

Yes, we agree. Instead of confusing the issue, why not adopt one of
the suggested terms for these non-SMP systems you are talking about?
Inventing yet more terms is really annoying, but I'll be civil and
not use all-caps.

>> Given that there aren't any real noncoherent distributed memory
>> systems available on the market, I'm unsure how you can compute
>> scalability of them. In case you didn't notice, the T3E is dead,
>> and I refuse to count SCI or Quadrics or various RMDA approaches,
>> which are doomed to be slow.
>
>Not any more. Pathscale makes one.

We do not. Again, thanks for being nice, but that's not what we built.
You have *no* *idea* how our hardware works.

>For some reason, you just don't want to acknowledge that users might use
>InfiniPath in ways that differ from what your engineers intended.

I am 100% in favor of people using InfiniPath in ways we never dreamed
of. And yes, we've thought about how to implement MPI-2, GAS, ARMCI,
UPC, CAF, SHMEM, and any of the 40+ distributed software shared memory
approaches out there on our hardware. That's just part of the
engineering process of doing an interconnect. But our interconnect
doesn't work like you think it does.

> In my
> experience, which largely falls *outside* traditional numeric HPC
> applications, I think there's interesting potential there.

I agree. Someday you'll notice that we're mostly agreeing.

>But god knows, if I were a technical lead on one of those gov't projects
>and I read any of this thread, I'd RUN not walk to one of Pathscale's
>competitors (like Cray).

And then you wonder why vendor employees often don't post on Usenet?
It's because of threads like this, in which you try to tell me how my
hardware works, and then claim it scares off customers when I try to
point out where you're wrong. If you prefer, I could fall silent.

> Dealing with Pathscale and *you* would clearly
> be more pain than gain.

Then please add me to your killfile.

>Remember, I'm the customer here,

And the customer is always right. Even when he's wrong about how the
hardware in question works. Even when he's uncivil. Even when he
hasn't read the literature, and wants to propose what's been tried,
what's being tried, what's been shown to work or not work, and then
goes ballistic when pointed at the literature. And so on.

Yes, I'm now sorry I got involved with this thread to start with. It's
a good thing that Usenet is an irrelevant forum.

-- greg
.

Relevant Pages

  • Re: Nice touch, AMD
    ... >> executing the required processor instructions to support that). ... But if the OS is bright enough, and the hardware supports ... > it, it should allow multiple 32 bit applications to all run at once, ... memory, and NT and descendants can use it both to run multiple ...
    (comp.os.vms)
  • Memory usage with many w3wp.exe processes
    ... We make an ASP.NET web application and we host it for our customers. ... customers on this hardware. ... Will the CLR release memory as we approach the limits and the OS begins ... The application caches ADO.NET datatables in the HttpContext Cache ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Thoughts on Vista
    ... None of them, yet, since the hardware won't support it. ... Most 1960s applications run in very small amounts of memory. ... Some entire operating systems could run in a few ...
    (alt.comp.hardware.pc-homebuilt)
  • Re: Macs in the Enterprise: the Cost Factor
    ... has to "upgrade all the applications and often the hardware to meet the new ... memory requirements." ...
    (comp.sys.mac.advocacy)
  • Re: Macs in the Enterprise: the Cost Factor
    ... upgrade all the applications and often the hardware to meet the new memory ... has to "upgrade all the applications and often the hardware to meet the new ...
    (comp.sys.mac.advocacy)