wowza

http://www.extremetech.com/computing/14 ... tonic-chip

Amazing breakthrough

BTW ahem viewtopic.php?f=7&t=12235&p=46940#p46940

So what's your cut of the profits?

As far as I can tell this is all solid-state, there are no MEMS involved. So what IBM invented is only very broadly in the same category as what Sigma proposed, and I suspect his cut will sadly be zero .

I am just glad that most of my ideas happen, whether or not I am involved, makes me feel like One day I will win out...

Also, these could be scaled down still, and powered with an input laser, that also provides a data pathway, making it scale even smaller,

My idea is still better, Mems are ok, but I am thinking that each "node" will be
1-small Graphics Processor(Vectors etc)
1-small Traditional CPu,
1-small local ram,
1-small global data,
1-network mapping data controller
1-small error controller
1-small laser
1-small photo-piezo-electric-speaker(IMPORTANT)

They can click together like Micro-Legos,
and a micro receiving laser, pointed at a nano-speaker, could send data, and receive power from the same point. as well as receive data,these could be stacked,
so the same architecture for your cheap chips, builds your mega chips,

and each end node could brodcast data-out and recieve power and data in,

So each packet that is going in would have (x,y,z, Data)

(x,y,z) is the location in 3d of the node in current map of computer,
the next section is String or Vector or Float or Instruction, instructions could change the way the map is, change what each section is devoted to, warn
user of errors etc.

The system could have configurations that are suited for tasks, added that are specialized.... beaming in power becomes more viable all the time, because contacts and metal can not re-map in real time.

I hope this ends up in reality, so anyone can just keep adding chunks, and have there own rendering-farm or server for cheap

http://www.pasteall.org/pic/show.php?id=41755


Another Rendition of same idea, slightly less complicated

Rigged for animating process BTW

That's pretty much a modern CPU core. The "Graphics Processor" would be the FPU and SIMD extensions (MMX/3DNow!/SSE/Altivec and what have you), the traditional CPU is the decoding and scheduling logic and the ALUs, local RAM is called L1/L2 cache, global data per core doesn't really make sense, we have RAM for that, and the network would be the various buses that the core is connected to.

The SIMD part is a bit of a stretch, the GPU cores on a modern CPU are separate cores that are much simpler than the CPU and specialised for "dumb" number crunching.

If the data is global, doesn't it make more sense to have it in one place rather than distributed across the nodes? If it's distributed, then every node has to be able to communicate with every other node, while with a separate memory everyone only has to communicate with that.

Sounds like a chip-level bus, I think the Cell processor has one. You should look into the Cell, it's not quite the same as what you describe here but there are definitely commonalities. Actually (and surprisingly), the main bottleneck in modern chips is not power or communication but synchronisation: to keep everything working correctly the entire chip has to run in lock-step, and a huge amount of the power and surface area is used to deliver the clock signal at the same time everywhere.

Perhaps also look at Intel's efforts and Tilera.

Each "Node" is given an instruction, like process this, or monitor that and flag this if that,

These "nodes" have there own memory, and can store global data, so you can locate global data near nodes that are using it, or just have "cloud" memory and a drive memory, the "cloud level" memory will be distributed....

The Highest level- instruction level is pretty much a whole normal PC, that is doing nothing but analyzing how to control the middle deck,

So Higher-Organizes lower systems communication like neurons and synapses, and groups things that are used together, as well as error control etc. If you had the right algorithms, you could have this tackle problems over and over, randomly assigning the nodes, until conditions are met, make a list of these "states" and then it could learn which configurations work best for which problems(human brain)-(This could take years)

I could have a node waiting for another, and not have marching issues, with this scheme,

so (1,1,1(adress))-((code line)if Input1 > X )Msg (2,1,5)-(float X min value is now 1 and Max is 4)

So these nodes don't handle binary exclusively, they handle Booleans and logic, or they are a clock, or they represent an object and have properties, like C,

the point is that I can add any pieces I need, and then keep scaling,
If I use a Digital Laser projector of X hertz, and one packet is sent to a X*X grid of chips every Hertz, then the grid of "nodes" will send its data below, to a target output stream, like back to instruction level or to an HDMI port etc. if I know how long it takes to return, then it is a traditional step problem, otherwise its like running lots of little computers, that each are prioritized for a task.

Right now data can only flow in lines that are pre-made, that is what I hope to avoid, A infinite scale ability as well as infinity parallel,

This could actually be much much slower initially, but if every chip I buy added to the last....

think lego PC

Well, there's two problems with programming parallel systems: one, we don't have any easy ways of dealing with the complexity this entails, and two, communication overhead.

The Cell chip I mentioned for example is used in the PlayStation 3 (although it's a version with only 5 SPUs). It's got quite a bit more raw number crunching power than the XBox 360's CPU, but the games aren't significantly better because the programmers have trouble actually using all that power due to the unusual architecture. It's the same thing on the desktop, even cell phones these days have multi-core CPUs, but software is only slowly being upgraded to use that effectively. And where the software uses multiple CPUs it's usually in tasks that are easy to parallellise, like image processing operations in which each resulting pixel only depends on a few surrounding pixels in a read-only source layer, so the different processors don't need to coordinate. The same thing goes for the graphics processing on GPUs.

Not all things are that easy to parallelise though. I'm currently running Markov Chain Monte Carlo simulations on a supercomputer at work, but it's not much faster than on my laptop since Markov chains are inherently serial, so the best I can do to use all that computing power is to run multiple simulations simultaneously. Sometimes a task can be parallellised in principle, but the required amount of communication between the processors slows things down so much that it's not worth it. Faster communications networks could help with that, which is what makes IBMs work so exciting.

Still, if you want a nice problem to chew on, try making parallel programming easier. We have a bunch of theory surrounding it, we know how to do it in principle, but in practice it's still more complicated than all but a small number of extremely smart programmers can handle (and they too get it wrong too often). It's a key technology you'll need for your idea, and if you manage it will also be immediately applicable to existing and near-future hardware and software.

PS: see also GreenArrays, Inc..

I believe that if each "sub-processor" is treated as a program object, and each processor has X number of dedicated outputs and inputs,and resources etc. that represent an multiple target laser, or solar input panel,
It's like a crazy secondlife sim...

Each node is like a Prim( a object primitive)- a code objected hosted on a cloud, that has properties, like color, velocity, mesh data, texture etc, and millions of people can look at one person, and it works......

So each core is not dependent on the other cores, Command Processor says the incoming data is going to you,(by aiming the laser at it that is that input data) you can then say when whatever condition is met, you do this, it sends it down to a direct output, or to the top level to change another node, etc.

this way no process slows any other, and some can just be waiting to initiate another segment when conditions change, it can't all work the same Inverse kinematics chain, but you can have each bone be a separate object,

The biggest gain here is the loss of physical architecture,

http://en.wikipedia.org/wiki/Intel_iAPX_432
here is a architecture that could work for my idea, when mixed with IBMs new optical chip, So, each "node" chip in the center plane, can have data steams by a central orchestrator, and then each "node" can be independently clocked and ran,

So each "Node" could have inputs, make decisions, and then effect other nodes, and be independent, or clustered, and prioritized,

The Computer Systems Architecture group at the University of Amsterdam does research in this direction. You might want to have a look.