Machine identification

[Hyperdrive]

There may be workloads with TDM-friendly access patterns and there may be others. Hopefully we can provide a suitable consistency model for the latter. If not, we loose in this case.

There aren't any workloads with TDM-friendly access patterns - there's only workloads where the crappy characteristics of TDM aren't as obvious.

Hehe. Compare the two statements. I think they are the same. Both are biased (yours a bit more than mine, but that doesn't matter, at least I don't care). My statement is optimistic and yours pessimistic. You don't like TDM, I think it is interesting concept. You tend to think more traditionally, I'm more liberal about new techniques.

Well, that will always be the case - it depends how you look at something.

For all workloads and all access patterns, you can get better performance and better scalability with shared memory and traditional locking, and much better performance and much better scalability with messaging (and careful design).

That's not really true. Don't confuse '>' with '>='. And the 'much' may not be as much as you are thinking. And then again, you pay a price for the '>' and the 'much'. I never said that TDM/DSM is the best you can get in all cases. All I did say is that there may be advantages. And as I outlined we already have observed advantages.

The question isn't whether TDM sucks or not, the question is how badly TDM sucks. Does it suck so badly that no sane person will ever want to use it, or is the level of suckage small enough to justify it's use in some cases? IMHO the level of suckage is small enough to justify it's use in some cases, but not any of the cases where it's necessary to distribute a large application across many computers.

TDM works very well with number crunching. Isn't that a typical application for a cluster?

Of course distributed shared memory sucks too (even though it sucks less than TDM) - there's a reason why large distributed clusters use messaging (e.g. MPI) instead of distributed shared memory (e.g. OpenMP), and it has nothing to do with "programmer friendliness"...

MPI is for clusters, while OpenMP is for multiprocessor machines. Therefore your argument is broken. (I know OpenMP reasonably well. And I already worked with it. Did you, too? For some of my commercial projects I had very good results from using OpenMP to parallelize applications.)

--TS

[Combuster]

TDM works very well with number crunching. Isn't that a typical application for a cluster?

there's only workloads where the crappy characteristics of TDM aren't as obvious.

Some workloads are insanely easy to do in parallel - a class of problems called "embarrassingly parallel". For these workloads it doesn't matter what you do you'll get very good results, and you'd even get extremely good results (for a large group of single-CPU computers) if you used DOS. Saying your technique works well for these problems doesn't really help.

It seems your argument was dead on arrival.

[Brendan]

Hi,

There may be workloads with TDM-friendly access patterns and there may be others. Hopefully we can provide a suitable consistency model for the latter. If not, we loose in this case.

There aren't any workloads with TDM-friendly access patterns - there's only workloads where the crappy characteristics of TDM aren't as obvious.

Hehe. Compare the two statements. I think they are the same. Both are biased (yours a bit more than mine, but that doesn't matter, at least I don't care). My statement is optimistic and yours pessimistic. You don't like TDM, I think it is interesting concept. You tend to think more traditionally, I'm more liberal about new techniques.

The statements aren't the same - you think there's workloads that are TDM-friendly (that will justify your approach), and I don't.

I do think TDM is interesting, but if you filled your shoes with icecream on hot days I'd find that interesting too. Just because something is interesting doesn't mean it makes any sense in practice.

You've chosen the least scalable and most programmer friendly method, but your target market needs the most scalable method and won't care how programmer friendly it is if it doesn't scale.

For all workloads and all access patterns, you can get better performance and better scalability with shared memory and traditional locking, and much better performance and much better scalability with messaging (and careful design).

That's not really true. Don't confuse '>' with '>='. And the 'much' may not be as much as you are thinking. And then again, you pay a price for the '>' and the 'much'. I never said that TDM/DSM is the best you can get in all cases. All I did say is that there may be advantages. And as I outlined we already have observed advantages.

Sure, there *may* be advantages with filling your shoes with icecream on hot days too.

You didn't say you've already observed performance advantages. All you've really said is "Some experiments show, that it scales very well. Granted, that depends largely on the work load." but for these work loads I'm assuming it only scales very well and other approaches scale extremely well, and that your approach is worse.

The are advantages though - I don't deny that. It'll probably be a good introduction to distributed systems for beginners, until they move to a harder to program distributed system with better performance characteristics.

The question isn't whether TDM sucks or not, the question is how badly TDM sucks. Does it suck so badly that no sane person will ever want to use it, or is the level of suckage small enough to justify it's use in some cases? IMHO the level of suckage is small enough to justify it's use in some cases, but not any of the cases where it's necessary to distribute a large application across many computers.

TDM works very well with number crunching. Isn't that a typical application for a cluster?

TDM should work very well where none of the data needs to be shared (but every sane approach will also work very well on these workloads, and TDM offers no "programmer friendliness" advantage at all in these cases because they're extremely simple anyway).

Of course distributed shared memory sucks too (even though it sucks less than TDM) - there's a reason why large distributed clusters use messaging (e.g. MPI) instead of distributed shared memory (e.g. OpenMP), and it has nothing to do with "programmer friendliness"...

MPI is for clusters, while OpenMP is for multiprocessor machines. Therefore your argument is broken. (I know OpenMP reasonably well. And I already worked with it. Did you, too? For some of my commercial projects I had very good results from using OpenMP to parallelize applications.)

You're right - I failed to find an example of shared memory being used for distributed systems, and OpenMP was the next best thing. Maybe I should rephrase what I originally said (to make sure you don't miss the point while you're paying so much attention to trivialities):

Of course distributed shared memory sucks too (even though it sucks less than TDM) - there's a reason why large distributed clusters use messaging instead of distributed shared memory, and it has nothing to do with "programmer friendliness"...


Cheers,

Brendan

[Brendan]

Hi,

TDM works very well with number crunching. Isn't that a typical application for a cluster?

there's only workloads where the crappy characteristics of TDM aren't as obvious.

Some workloads are insanely easy to do in parallel - a class of problems called "embarrassingly parallel". For these workloads it doesn't matter what you do you'll get very good results, and you'd even get extremely good results (for a large group of single-CPU computers) if you used DOS. Saying your technique works well for these problems doesn't really help.

It seems your argument was dead on arrival.

Hehe - sure, I can imagine the marketing material now: "SomeOS! The perfect distributed OS for when you don't need a distributed OS!"


Cheers,

Brendan

[Hyperdrive]

Well, it seems that this discussion is a dead end. Maybe it would be better to not bother you any further with this...

--TS