Grid Processing
c1ay writes "We've all heard the new buzzword, "grid computing" quite a bit in the news recently. Now the EE Times reports that a team of computer architects at the University of Texas here plans to develop prototypes of an adaptive, gridlike processor that exploits instruction-level parallelism. The prototypes will include four Trips(Tera-op Reliable Intelligently Adaptive Processing System) processors, each containing 16 execution units laid out in a 4 x 4 grid. By the end of the decade, when 32-nanometer process technology is available, the goal is to have tens of processing units on a single die, delivering more than 1 trillion operations per second. In an age where clusters are becoming more prevalent for parallel computing I've often wondered where the parallel processor was. How about you?"
Normally I don't pimp Sun, but here's something that makes me think they still have a finger on the pulse of things:
;-)
Read about plans for Sun's "Niagra" core
I understand they hope to create blade systems using high densities of these multiscalar cores for incredible throughput.
There's your parallel/grid computing.
Fuck Beta. Fuck Dice
I still think this is not what is commonly understood by the term "Grid Computing". Maybe it's the environment I work in but to me Grid Computing means something else
And is exemplified by projects like MyGrid.
I don't read your sig, why do you read mine?
It's funny how people always seem to find a way to confuse what is meant by a "grid". The posting talks about a "4x4 grid" without clarification of the term "grid", which is confusing because grid computing has nothing to do with processing units being lined up in a grid. The "grid" in "grid computing" comes from an analogy with the power grid, not from any form of "grid layout". The analogy is based on the fact that with grid computing, you simply plug your "computing power client appliance" (not necessarily a PC, could be the fridge) into the "computing power outlet" in the wall (a network port, usually), and you can "consume computing power", like you would do with electricity. Computational grids don't even necessarily have to support parallel programs; it is easy to imagine grids that have a maximum allocated unit of a single processor. What makes such grids grids is that you can allocate the power on demand, when you need it, instead of that you have to have your own "computing power generator" (read: megapower CPU) at home.
The article doesn't actually have anything to do with "grid computing", but the processor's design is like a grid. The term "grid computing" often refers to large-scale resource sharing (processing/storage).
This story already appeared, but was posted by someone who was not confused by the use of the term "grid"... Doug Burger, one of the two key profs on this project (and no relation!), answered lots of questions, which you can see here.
-- emery berger, dept. of cs, univ. of massachusetts
- MIT's RAW project
- Berkeley's Garp architecture
- CMU's PipeWrench
Quite a number of researchers are looking at the performance and density adavantages of reconfigurable architectures in addition to the work mentioned in this article. What's really intriguing is considering how opreating systems could support reconfiguration. Doesn't seem to be much work on the subject.Most parallel systems only work for a certain type of problem - one where processing can be split into many small chunks, each one non-dependant on the others.
eg. who cares how many instructions you can process in parallel, if module A requires data from module B. In these cases parallelisation is limited to making each module run faster (if it doesn't have sub dependencies, of course), the entire program doesn't benefit from the parallelisation.
Good examples of parallel processing are the ones we know - distributed apps like SETI@home, graphics rendering, etc.
Bad systems are everyday data processing systems - they typically work on a single lump of data at a time in sequences.
A good source of parallel programming is http://wotug.ukc.ac.uk/parallel/ or, of course, google.
No no no.
Ok, HT double clocks the Cache! so you have two cache's for the price of one! The G5 is a multicore chip so is Cell Linky and The Opteron are all multicore chips, the diffrence (apart for the arch!) is the way VLIW's are feed to each of these. They are NOT paralell processors, paralellisam can be defined as the maintence of cache coherence, it is either inclusive (cray) or excluseive (rs6000), and requries a lot of bandwidth (local x-bar versus network). Where as parallel computers are not cache coherent and have a remote x-bar architechure, it all adds up to the same hypercube.
for parallel processing fortran boast many language level features that give ANY code implicit parallelism and implicit multi-threading and implicit distribution of memory WITHOUT the programmer cognizantly invoking multiple threads or having to use special libraries or overloaded commands.
An example of this is the FORALL and WHERE statements that replace the usual "for" and "if" in C.
FORALL (I = 1:5)
WHERE (A(I,:)
A(I,:) = log(A(i;0)
ENDWHERE
call some_slow_disk_write(A(I,:)
END FORALL
the FORALL runs the loop with the variable "i" over the range 1 to 5 but in any order not just 1,2,3,4,5 and also of course can be done in parallel if the compiler or OS, not the programmer, sees the opportunity on the run-time platform. The statement is a clue from the programmer to the compiler not to worry about dependencies. Moreover the program can intelligently multi-thread so the slow-disk-write operation does not stop the loop on each interation.
The WHERE is like an "if" but tells the compiler to map the if operation over the array in parallel. What this means is that you can place conditional test inside of loops and the compiler knows how to factor the if out of the loop in a parallel and non-dependant manner.
Moreover, since the WHERE and FORALL tell the compiler that the there are no memory dependent interactions it must worry about. thus it can simply distibute just peices of the A array to different processors, without having to do maintain concurrency between the array used by different processcors, thus elminating shared memory bottlenecks.
Another parallelism feature is that the header declaration not only declare the "type" of variable
Other rather nice virutes of FORTRAN is that it uses references rather than pointers (like java). And amazingly the syntax makes typos that compile almost impossible. that is, a missing +,=,comma, semi colon, the wrong number of array indicies, etc... will not compile (in contrast to ==, ++, =+ and [][] etc
One sad reason the world does not know about these wonderful features, or repeats the myths about the fortran language missing features is due to GNU. yes I know its a crime to crtisize GNU on slashdot but bear with me here because in this case they desereve some for releasing a non DEC-compatible language.
for the record, ancient fortran 77 as welll as modern fortran 95 DOES do dynamic allocation, support complex data structures (classes), have pointers (references) in every professional fortran compiler. Sadly GNU fortran 77, the free fortran, lacks these language features and there is no GNU fortran 95 yet. This is lack prevents a lot of people from writing code in this modern language. if Gnu g77 did not exist the professional compilers would be much more affordable. So I hope some reader who know about complier design is motivate to give the languishing GNU fortran 95 project the push it needs to finnish.
In the age of ubiquitous dual processing fortran could well become a valuable scientific language due to its ease of programming and resitance to syntax errors
Some drink at the fountain of knowledge. Others just gargle.