Beowulf: A theorical approach
Many of your questions may have already been answered in earlier discussions or in the FAQ. The search results page will indicate current discussions as well as past list serves, articles, and papers.
Greg Lindahl glindahl at hpti.comFri Jun 23 09:21:52 PDT 2000
- Previous message: Beowulf: A theorical approach
- Next message: Beowulf: A theorical approach
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
> I don't like that name much. The address space is _not_ shared, > nothing is shared, an address is always local. (Which is a good thing > if you only have a 32 bit address space, since you'd soon blow it away > in a large machine if you had all the cooperating process' address > spaces mapped in). You don't understand how I was using the word 'address space'. The address space in question is NOT the memory address space. It is the namespace for all the data. The processor hardware isn't involved and you don't use the usual processor "load" instruction to access this data; you call a subroutine. This subroutine interprets an argument as the name of the data to fetch. That's shared. > Personally I always called it a "cache-coherent explicit remote store > access" model, But it isn't actually cache coherent. Remember Cray shmem(): To use data, you fetch it to be close to you, and then it isn't cache coherent while it's local. It IS cache coherent in that the fetch gets you the right data. > In any case you don't need to wait, the Quadrics' stuff does this now > (on PCI). Not a big surprise, really, given that it is the current > version of the Meiko interconnect. The PCI latency penalty is quite large. If I had to support SALC today, Quadrics is one approach, but I have another approach that I feel would be superior. -- g
- Previous message: Beowulf: A theorical approach
- Next message: Beowulf: A theorical approach
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Beowulf mailing list
