Tags:
tag this topic
create new tag
view all tags
---+ Single Instruction Multiple Data The biggest, baddest parallel clusters these days are SIMD clusters where the workers do not communicate directly with other workers. ---++ Hardware ---+++ Google * ~300K machines available, reportedly 2,000 worker machines is not unusual * Typical apps: search, distributed sort, distributed grep, [[http://labs.google.com/papers/sawzall-20030814.gif][world map showing location of queries]] * Map-partition-reduce * Sawzall: users write code to manipulate _one_ record, it takes care of rest * Distributed filesystem-based database * Code is a trade secret * Vandalism, malicious code low concerns * Communication: writes results to distributed file system, where further workers "pick it up" (sort of very slow shared memory!) Throughput more important than latency. ---+++ Volunteer megacluster * Variable. SETI@home claims 2M * Typical apps: biological simulations (protein folding, drug discovery) * Code varies from project to project and is pretty closely guarded to prevent vandalism * Vandalism, malicious code high concerns * Communication: infrequent, small size, presumably bottlenecked by small number of servers ---+++ Botnets * 1.5M (Dutch), 400K (US) * Typical distributed apps: denial-of-service attacks, spam delivery, click-fraud, subvert other computers (as well as mine local hard drive for account information) * Code apparently relatively easily available; some is GPLed! Legit sites not eager to spread the knowledge. * High concerns about tracability, malicious code (i.e. other bot herders) * Communication: command-and-control frequently through IRC; bandwidth and computing power is stolen so "free"; latency not particularly important. Concern about jumping to P2P networks soon. ---+++ GPUs * 20ish cores on GPU processor, tenish vertex processors and tenish fragment processors * Typical apps: graphics (duh), fluid flow, FFT * Higher level languages (HLLs) * Cg (nVidia) * Brook (open source, written on top of Cg) -- strong map/reduce component * No possibility of external malicious code. * Communication: vertex processors and fragment processors communicate via registers. Vertex processors can't write to external memory; fragment processors can't read from external memory (except in a hack-y way through texture buffer).
E
dit
|
A
ttach
|
Watch
|
P
rint version
|
H
istory
: r2
<
r1
|
B
acklinks
|
V
iew topic
|
Ra
w
edit
|
M
ore topic actions
Topic revision: r2 - 2006-04-03
-
DuckySherwood
Home
Site map
BETA web
Communications web
Faculty web
Imager web
LCI web
Main web
SPL web
Sandbox web
TWiki web
TestCases web
Main Web
Users
Groups
Index
Search
Changes
Notifications
RSS Feed
Statistics
Preferences
P
P
P
View
Raw View
Print version
Find backlinks
History
More topic actions
Edit
Raw edit
Attach file or image
Edit topic preference settings
Set new parent
More topic actions
Account
Log In
Register User
E
dit
A
ttach
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback