Slashdot Mirror
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?"
Yep, that's just what I wondered.
And before anyone says it, no I have ever thought about a beowolf cluster of those...
"Those who cast the votes decide nothing; those who count the votes decide everything." (attrib. Joseph Stalin)
I have seen something like this somewhere... it was in Terminator II!!!
You can defy gravity... for a short time
Grid Engine is free, available on most of the Unix platforms, easy to set up and allows you to scale your processing pretty much linearly.
If you want to know more, I'd be happy to consult at $300/hour.
Government of the people, by corporate executives, for corporate profits.
To make a brick of these things, or some kind of cube, with massive processing power that one could just carry around and interface with via their PDA?
Just think about carrying around something as fast, if not faster, than your desktop that fits in the palm of your hand.
Edward@Tomato - /home/Edward/ man woman
man: no entry for woman in the manual.
"Qua!?"
My first thought when I saw "Trips" was "Total Reality Intrgrated Playing System" from Battletoads... What's next, we're going to get sucked into the gamescape? :)
------
"And may your days be long upon the earth."
A question for anyone with such experience:
I assume it would be somewhat difficult to program efficiently for such systems. I don't mean just getting programs to run, but getting the most bang for your buck. Can anyone here confirm or deny this? Also does anyone know where to find resources on the topic of programming such machines (and no, I am not talking about smp docs or bewoulf docs or even pvm docs)?
Anyone remember from T2 what the CPU looked like? It was a 3 dimentional grid of CPUs...
Don't say I didn't warn you!
Slashdot's rate-of-post filter: Preventing you from posting too many great ideas at once.
This is not an example of the Grid Computing (ala Globus) that we've been hearing about. This is another example of laying out processor cores on a chip. So a better thing would be to compare this to the ideas for the UltraSPARC V and IBM BlueGene computers where multiple processing cores are put on one chip and then arranged in a grid (think physical grid) architecture.
Grid Computing deals with computation and information sharing seemlessy across a network, they used to always say like how the power grid works. Which in reality is about right as it doesn't always work as advertised.
Anyway, Grid Computing is mainly concerned with software to allow multiple computers to work together seemlessly. This includes registry services, single sign of, information transfer, etc.
This appears to be the rather fortunate result of a phenomenon called "Buzzword collision", where two different projects pick the same buzzword in hopes to really confuse people who don't read the articles and trick PHBs into thinking that each project is ueberimportant.
My Slashdot account is old enough to drink...
There are some programming languages designed for parallelism. Biggest hassle is efficiently partitioning problems into something parallel. Not all problems can be done faster by doing more of it at once.
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?
How about the three ALU's in me Athlon? How's that for parallel?
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.
I use parallel computing on a cluster, in which I divide up my computational domain into a number of chunks, and each chunk is farmed out to a processor. Communication between the processes is required at the chunk boundaries.
For this case, I see how my code is partitioned, and I also understand (on a general level, at least) what the limitations on speed are: information based between the chunks.
Now, how will this processor do its 'instruction level' parallelization? Will it be great at do loops (one 'do' per processer)? Will it be like a mini vector processor? What will break down the efficiency of the parallelization?
I have found that efficiency in parallelization is very application dependent after about 8-32 procesors. Will this break that barrier?
Most importantly, will it kick butt for MY applications?
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).
What is the theoretical size limit of a beowulf cluster? 255? 35xxx? 10^20 ?
Has anyone thought of making a beowulf cluster of beowulf clusters yet?
Take a look at the intel ixp-2800. A network processor containing 16 multithreaded microprogrammable 32 bit processors and an xscale core riding herd. All are tightly coupled with a multi-layered memory architecture. Fun to program.
The prototypes will include four Trips 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.
At 32 nanometers, Intel could put tens of HT pentium cores on a single chip, achieving the same result.
"One key question is, Will this novel architecture perform well on a variety of commercial applications?"
For computational problems that can be broken down into parallel computations, the answer is yes. For all the other types of problems, the answer is no. Although I have to admit that most algorithmic bottlenecks is in iterative tasks that are highly parallelizable.
On Trips, a traditional program is compiled so that the program breaks down into hyperblocks. The machine loads the blocks so that they go down trees of interconnected execution units. As one instruction is executed, the next one is loaded, and so on.
*cough* EPIC *cough* VLIW architecture *cough*
I support parallelism and I am looking forward to seeing it on my desktop, as it will increase the computational power of my computer tremendously. Unfortunately, it will mean new compilers and maybe programming languages that have primitives for expressing parallelism.
By the way, the transputer chip was promising. The idea of lots of computational units running in parallel is nothing new(maybe each memory block must have its own processor to locally process and compute the data).
Forgive me if I'm off base here, but perhaps a proccie nerd can explain the differences between this design and say VLIW. They seem closely related, breaking the app into parallelizable chunks and sending them to n execution units. The article doesn't mention if the trips processing nodes can 'talk' to each other. If they can't, then this seems very similar in concept to vliw (if not different in physical and logical layout).
Grid Guru. It's a slash site devoted th Grid computing.
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
parallelizing the data-processing itself (Eg Seti@Home) whereby the data being worked on itself is spread amongst 'loosely parallel' execution units is much more practical, and doesn't suffer from the overhead involved in creating parallel processor servers, or even parallel execution chips. It also alleviates the memory bottlenecks of parallel execution cores.
I always wondered what kind of an app demands the kind of big iron that Cray and NEC churn out - that couldn't be more cost effectively realized through distributed processing amongst many independent computers (a la Google).
It seems, even cyclical, result-dependant processing (weather prediction) could be coded to work in such a manner.
1000 bare bones p4 3ghz PCs (~$600) have more processing power ( 2500 MFLOPS each ) than a single X1 cabinet ( 819 GFLOPS @ $2.5M ) and as you can see - for less than 1/4 of the cost.
( 2.55 TFLOPS @ $600,000 vs 819 GFLOPS @ $2.5M )
( p4 MFLOPS hit 5700 each w/ SSE2 )
Now I imagine there have to be exceptions. There -has- to be a reason to have such big iron for certain problems. There must be a reason that very smart people advise their superiors to buy up around $8b of this stuff each year.
but i don't personally see the applications, and given the monumental cost of developing a new processor nowadays - the market doesn't seem to either.
so that's my $0.02 as to why more complex esoteric parallel execution designed chips remain so rare.
// "Can't clowns and pirates just -try- to get along?"
- 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.They can use it to think up even more lame, far-fetched acronyms.
Carly said it is all hype and we cannot use grid's for at least another 5 years. Obviously Carly does not read slashdot or own a Linux box.
Got Code?
skynet to become selfaware is now what?
Shop smart, Shop S-Mart.
http://mission.base.com/tamiko/cm/
the connection machine was another parallel computing system (64k little bitty processors hooked together into a grid) that had a flurry of excitement around it (almost 70 of them in operation at the peak of activity!) and then sorta died off. alot of the problems with systems like this weren't really flaws in the basic idea, just economic issues. If you can make a cheap non parallel system run some ugly hack of solution to the problem in something semi close to the time that the elegant but expensive as far as price per unit of processing custom made parallel system can, then people aren't going to want to invest the money in a specialized system unless there is just no other way possible to get their work done without it. but being able to apply the same techniques that let moore's law bumble along should help things out.
If even with one CPU core, if your system is main memory bandwidth limited (or mostly), then extra cores won't help (much). So this kind of design looks good only for non bandwidth limited tasks, which is a much smaller market.
They don't seem to be considering business servers here, but they are more main memory latency limited than bandwidth limited, so multiple cores can help a lot. But you need more than simply lots of cores to have a good design. A critical thing to have is major software support which means using an existing ISA, not a new one.
So I'd expect this to be quite an obscure product in reality.
Naturally, if it was called Slow-poke Faulty, Blindly Restrictive Procesing System I would be less inclined to trust this solution.
Isn't this what the PS3 is supposed to use? Some sort of grid-like structure in their processor?
-----
Web Hosting @ HostForADollar.com
In an age where clusters are becoming more prevalent for parallel computing I've often wondered where the parallel processor was. How about you?"
;-)
I may be thinking in different terms than you, but my understanding of future chip design is, that multiple CPU cores on one chip, is basically becoming the norm. To some extent, is this what hyper threading does on the newest Intel chips? I recall also reading the PPC G5 chip in the newer Mac's has multiple processor cores.
So, to answer... where are parallel processor's? Try best buy!
Cray said "Modify the Algebra to suit your Hardware, don't kill your processors with floating point operations, instead use a diffrent more efficent method". And Intel Listened. Crossbar N-Dimensional hypercubes are great for decreaseing the wall-clock time on complex problems, most noteably simulations. The worlds Largest super computer (NEC's Earth Sim in Japan) is used to do just that. The issue is the netowrk bandwidth or moving information form one cache to another. That is costly and intorduces a processing tax on parallel information. Myrinet's solution is ultrafast interconnects so your crossbar is disgustinly fast. And essentially you are still dealing with a Hypercube, then the issue becomes the distrobution of information into and out of the cube.
big deal if i have 40 processers on a chip if i still can't get enough memory bandwidth to feed one of them.
In an age where clusters are becoming more prevalent for parallel computing I've often wondered where the parallel processor was. How about you?"
Danny Hillis, the guy who founded ThinkingMachines designed a mchine called The Connection Machine, (this story has a cooler, more sci-fi lookin' pic of the old beastie) the central design philosophy was to achieve MASSIVE computing power through parallelism. It had 65,535 procs, each of lived on a wafer with dram thereon and a high bandwidth connection to up to (if I remember correctly) up to 4 other of the procs. Young sir Danny wrote a book on his exploits, well worth checking out (seemingly, it's been calling to me from my bookshelf for about a year now).
And as someone pointed out, it seems we've seen this topic before. I'd have modded him up, (hint, hint) but I really like mentioning the connection machine where appropriate.
Quod scripsi, scripsi.
I'm just curious what will happen to the yields when they are busy cramming more cores onto a single die. Already they have to discard or down-rate many of the die on each wafer. What will happen when you have several cores, any of which might be faulty and ruin the remainder of the die.
This is very much not new. The basic idea has come and gone several times in the last twenty years, to my knowledge. Both SIMD and MIMD systems have been tried several timed. NCR even had one called the Grid, IIRC. Thinking machines (as seen on Jurassic Park I). The Inmos tranputer was designed for exactly this sort of connectivity. Intel had a development machine (?iWarp?) which tried to use it. And I am sure there were others that I don't recall. (As a user and fan of the transputer, I used to follow the field from a distance).
But the problem has always been the programming. Ordinary software does not map very well onto these architectures. Certain specific problems can be mapped well onto them, which results in spectacular performance claims for the system. But generally such systems perform well only on those problems for which they were specifically designed.
Communications is a common reason for failure. They scale very badly. In the early days of development, the first few processors have any-to-any connectivity, so the application will really fly. But since the connectivity rises as the square of the nuymber of processors, this cannot hold for very long. As soon as connectivity becomes limited, communications bottlenecks start to appear, and you get processors being held up either sending messages or waiting for them to arrive. Buffering (which many did not implement in their communications architectures) helps, but itm doesn't solve the problem. (A bit like lubrication - a small amount brings a considerable improvement in performance, but past a certain point, it only adds to costs).
Another problem is load balancing. It is very difficult to design your system so you don't end up with most of the CPUs waiting for one, overloaded, CPU to finish its job. The only architectures which really worked were the farm model - a central dispatcher sends tasks to a "farm" of identical "workers", which therefore request work units as and when they need them. This means that the whole code for the system has to be loaded into each worker; not necessarily a killer at todays memory prices, but it would be nice to be more efficient. It also requires the task to be divisible into a vey large number of chunks, which can executed independently without too much communications. OK for large volume simulations etc., but a disaster for (say) database programming, image/voice recognition.
It also doesn't help that not may people really think multi-threaded in their program design. Again, no-one that I know has a good Object Oriented multi-threading model. Current models are analagous to either pre-structured programming or early structured programming. Which means that people, reasonably, approach multi-threading as a dangerous monster to be approached only whan absolutely necessary, with great care, and if possible in flame-proof armour. For this sort of system to be much use we need a development which does to current threading what inheritance did to pre-OO languages: something that makes is so simple that, one over the hump of initial unfamiliarity, people use it all the time without even thinking about it.
I designed one of the larger heterogenous transputer based system to ship - up to 100 transputers in 6 different roles. Load and communications balancing was a real hassle from the the day the system first started to work for real, and we were constantly tuning buffers, fiddling with routing algoirithms, movong bits or processing from this CPU to that to get the perfomance up. (Not to mention that inmos completely blew their second generation transputer, which we had been hoping would solve many of our problems).
Consciousness is an illusion caused by an excess of self consciousness.
How long before Taco also posts it?
there's no place like ~
They have some papers available there...
I went to UT and had the privelege of taking computer architecture with Doug Burger about 4 years ago, one of the co P.I.s of the project. He used to give us rock hard exams ( but buy us pizza to ensure nobody felt bummed out because of them ). Also used to give tons of homework. However, he never came across as evil, just as someone who genuinely wanted us to learn. He's incredibly smart, knows what he is going and is good natured to boot. Check out some of the fun quotes in his plan I went to many lectures of his about his grid architecture project. At that time he had many graduate students working on it - some working on a simulator for the processor, some working on a compiler and some working on studies of what applications are going to take advantage of the new architecture. I'm sure this project is going to turn out to be really cool.
Ahh, there it is. That's the post i came here to see ;)
I read this as "Girl Processing" and was preparing a WTF? comment.
:)
... Wouldn't it make more sence to run them in series? :) (jk)
Internal parsing error reported.
I always thought the "single" processor paradigm has gone on way too long. I guess soon we'll be able to plug in multiple processors like we do ram.. But a question.
(1/req)=(1/R1)+(1/r2)+(1/R3)
-=fshalor
... As of August 14 seems like a terrific idea for electric power. Let's copy that fine idea of dependency on the perfect working for a system several states away.
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.
My God, that is probably the most insightful and informative comment I have ever read on slashdot, bar none!
Read the article - this isn't the case that you've got a whole bunch of traditional processors and you try and divide the work between them. They're talking about the CPU itself being split into several smaller general units, so that each instruction gets excecuted by several of these units. The instructions are grouped together and then sent to the CPU in blocks. All the work for that block is then split between the units, taking into account any interdependencies. I suppose the closest thing to it would be to have microcode being executed in parallel.
Since the article doesn't really have to do with grid computing. Here are some real Grid Computing links.
Globus Toolkit
LSF
openPBS
gridengine
OSCAR
ROCK MPP
maui
and last but not least: beowulf cluster
---
sure I'll have a sig.
There's a good book explaining a lot of this stuff in detail available from O'reilly. I can vouch for it having some neat stuff, and it covers how to write fortran in such a way as to take advantage of the parallelism features.
I wonder if there is some way someone could practically and legally set up a compilation server for F95 using a non gnu fortran. One could probably talk one of the proprietary compilers (Portland group or Absoft) into allowing this since it would actually promote sales of their products.
The reason this would improves sales is that This would alleviate the dillema programmers face. Write in crippled GNU syntax and have your program compilable by the masses or write in a sane, uncrippled syntax and produce great code that's easy to write, read and debug, and runs many times faster, but can only compile on an expesive compiler. the solution is to have a compilation server that serves a wide variety of target platforms.
The developers still buy the pro fortran since the server would be impractical for development. But it would allow end users to compile the source. thus it would increace the viability of fortran as a language and improve sales of the compilers
Some drink at the fountain of knowledge. Others just gargle.
Links:
- Globus FAQ
- Python Globus (pyGlobus)
- The Condor Project
- Beowulf FAQ
See also: Throughput ComputingIsn't this what the new Playstation 3 cpu is based on? Single chips that contain multiple processing cores?
Designed by the "grid" masters themselves -- IBM.
I am new at this. But i probably do know that if this is happening then someone is upgrading on this and so on and so on. See now we are getting into urgonomics. Man and Machine. We won't even need the internet. We will be the internet. Mankind will be the internet. With this grid processing, trillion bites and all. Imagine it being upgraded. I'm only 15 but i have amazing ideas about this stuff. I am a computer person. Any comments tell me. Yes i know i rambled but i need someone to tell
I wouldn't put much blame on GNU. Fortran 77 was a fairly unpleasant language, even before GNU existed. Compiler extensions sometimes helped but weren't too great for portability.
Not that I don't want to see a GNU Fortran 95, but if you can tolerate free as in beer software, Intel makes their fortran compiler available for free for noncommercial use on Linux: IFC
There is also the F programming language which is a (mostly) tastefully selected subset of Fortran 95: F. Mostly it just throws out redundant features and stuff inherited from Fortran 77. It's a little picky in a teaching-language sort of way and takes some getting used to, but I have ported code to F without pulling my hair out. And the code did end up a bit clearer for the changes.
...to see the heatsink on a 1THz, 16PU on die processor. Two cases? One for the liquid nitrogen cooling system, the other for your 48x dvd burner, etc.
... that parallel computers are prohibitively expensive, compared to a networked cluster, due to the hardware involved.
one word: Atari Transputer
;)
oldschool hardware kicks ass
I spent 13 years at the Supercomputer Computations Research Institute, an interdisciplinary research institute whose job it was to figure such things out. Amongst other goodies, we had the first CM-2 (a SIMD box with 65536 processors) with floating point chips, at the time the fastest machine in the world. We also had a homegrown machine for quantum chromadynamics. And a cluster with 150+ nodes, and some shared memory machines, yada yada yada. Lots of stuff.
So, from my experience:
It's a little bit tricky to do. Sometimes you find an algorithm that someone abandoned fifty years ago that turns out to map better onto the hardware. However, it isn't all that tricky to do, and there are plenty of algorithms and libraries to make the job easier.
But it still doesn't happen anyway, because even a small amount of work is more than no work at all. And besides, what people want to do is run their old dusty decks but just have them run faster. And in the mean time, Intel has just come out with a faster scalar processor, so why bother?
The only thing I can see coming out of this is if, say, NVidia makes a faster graphics card based on it.
For the best parallel performance you have to give up serial performance, and that is something the main processor lines cannot afford to do. Parallelism even when extensive is just something to use up all the extra gates they have.
... since m$&Nintendo are not investing enough and the graphics market is unstable the most promising is IBM&Sony's Cell.
The most powerfull parallel designs will come from areas which dont have to deal with legacy and can invest a lot of money for architecture development. So that pretty much means consoles and PC graphics
The only other market which can use processors designed for maximum parallel performance is HPC, and that market is just peanuts.
What if there are more clients needing the processing power that the grid can provide, or when one of the 'generators' shuts down? Given how often we have to deal with Windoze and virus, will it a local 'blackout' leaves 50 billion users with no computing powers? This kind of computing grid sounds like an accident waiting to happen, and a much more devastating one too. We no longer need centralized computing network for our processing needs, and we should not start going backwards now.
What if there are more clients needing the processing power that the grid can provide, or when one of the 'generators' shuts down? Given how often we have to deal with Windoze and virus, will a local 'blackout' leaves 50 billion users with no computing powers? This kind of computing grid sounds like an accident waiting to happen, and a much more devastating one too. We no longer need centralized computing network for our processing needs, and we should not start going backwards now. Hopefully we don't come to a society where we have to rely on a certain Blue NAVI from Lan to blast out the system errors...
Actually, the goal for this processor is to keep increasing single-thread performance, and not just by pumping up the clock speed, but by doing more ops per cycle. So, we want to increase performance *without* putting programmers through all the pain of parallelizing their code into fine-grained chunks.
--+-- Doug Burger, UT-Austin Computer Sciences
Are processors such as the one proposed by the end of the decade any threat to encryption products with small keys?
I.e., how soon will the average processor available on the street be able to crack a 56-bit DES key? A 128 bit key? Will a 1024 bit key ever be crackable by brute force?
We keep hearing that "all the kings computers and all the kings men" could never crack 1024 bits by brute force in millenia of trying. But does the continued exponential advancement of computing power threaten this state of affairs?