The next step: A way to produce flexible gallium arsenid wafers in quantity has been found

On a sunny day (Fri, 28 May 2010 10:57:50 +0300) it happened Paul Keinanen wrote in :

Thank you for the deep insight. Yes does not work for all frame types hehe.

Thank you for the deep insight. Just a quick question: How do you transfer data between those 300 cores?

I am just eager to see all the theoretical advantages of a 300 core, resulting in a real product that beats a 300x clock single core.

It will never happen. Publish the code! Your chance to fame!

On a sunny day (Thu, 27 May 2010 16:37:00 -0500) it happened "Tim Williams" wrote in :

Often video comes in ONE FRAME AT THE TIME. So I also do real time procesing. In a real broadcast say HD environment you have several HD cameras streaming, encoding is needed, recording is needed.

I give you that you could indeed chop a stream up once it is recorded and work on sections of that. not a bad idea actually. Bu tnot always easy to do, say you render a sequence with Blender? But for pure transcoding it could work.

As to pipes and streams, it is the best way I know to do multiple operations on signals. It is the Unix way, many have critised it, and it has always won in the end. First it was text only, filters via grep or awk or sed or whatever, then it was audio, then as speed increased it was video, I was the one of first to use it for video I think, more then 10 years ago. The system has proved itself, I wrote the C code with Moore's law in mind, knowing it would run faster and faster and finally real time.

Now yo ugo and write the 300 core parallel processing stuff, I am waiting.

You are so clever, I am amazed. I am just waiting for the programs. OTOH I aint'not buying no more then a 6 core I think. In fact I am not buying anything in the form of computer now, but I will go for the 300 GHz single core. Been fixing up the house lately :-) Tell you one thing, computahs are much cheaper.

A camera generating 1920x1080p60 requires only 125 Mpix/s (8ns/pixel), assuming 3x10 bits/pixel, this would fit into a 32 bit bus.

Using the producer/consumer model, in which each node only pics the data it is interested in, only a single 32 bit bus connected to all cores would be required running at 125 MHz. This does not seem too hard these days.

With 16x16 macro blocks, you need to communicate with 8 neighbor macro-blocks (N, NE, E, SE, S, SW, W, NW).

With slices, you only need to communicate with the slice above and below.

This is a simple case that would benefit from al large number of processors, making a general product that could use effectively the large number of cores is of course much harder.

On a sunny day (Fri, 28 May 2010 14:21:10 +0300) it happened Paul Keinanen wrote in :

Yes. Do you remember the 'transputer'?

Well in that case, you can't do better than transcoding 1 frame in 1/FPS seconds, so you only need a limited amount of processing power regardless. And it's going to be a lot less power than e.g. transcoding the Library of Congress in an hour.

What is significant about a "sequence with Blender" that can't be evaluated for all time? Are there animations composed of difference equations, rather than predefined equations (e.g. "live" physics simulation)?

Even if so, the geometry can be solved beforehand, or evaluated to a certain point so that each process can evaluate its section of time independently.

Lots of differentials problems (think FEA) are subject to useful parallelism (if not always as embarrassingly so as graphics tends to be), so I fail to see how it ends here. Just like ever... it is subject to the skill of the programmer, and how much foresight he has.

Tim

On a sunny day (Fri, 28 May 2010 16:33:48 -0500) it happened "Tim Williams" wrote in :

That last remark I fail to see, we are moving towards higher and higher resolutions, more complex encoding schemes, more frames per second with 3D, and more then one stream at the time.

Well, I dunno how big that is, but one day maybe it will fit all on a postage stamp size medium, but that is an other subject, and interesting one, it reminds me of the Alien anecdote: Alien came to earth, looked a around a bit, found it all very interesting, and wanted to take the accumulated knowledge of the earthlings home with him (it?) to the home-planet. So he got Encyclopedia Britannica, but it was too big and too heavy to fit in the flying sourcer. I have to change sentence construction constantly as to avoid the him / her / it dilemma with that alien. not sure how aliens reproduce, maybe of well, back to that problem with weight and size, hehe So, anyways, Alien writes down all of the characters in those books as one long hex ASCII string. Very long. Then did a 1 / number, took a stick, and put a mark on it from one side to represent that ratio, and took the stick with the (hehe) flying wok or sourcer or dishwasher or whatever,

One of the points and advantages of NOT going multi core is that you can use existing programs

Sounds cryptic to me.

When thinking about your idea of chopping up say a mpeg file, and 'real time' I was thinking maybe GOPs of 15, so 15 frames, at 25 fps that makes .6 seconds, you need to read-ahead for 300 cores makes 180 seconds latency (not counting any data transport delays).

Yea, it is all fun, you need to code some of that stuff, just for the honour, Klingon like :-()

quantity has been found:

Naw, 80 GHz (U)LVPECL 8-bitters and maybe 12 or 16 bitters. Single 1.5 V supply.

Larkin

quantity has been found:

efficiency is big news.

physics.

for that,

- filtering

work better then a general purpose core.

becomes a horror.

tasks

rarely.

any sense.

that point.

is not done very well every day,

multicore' remark,

impossible,

of the world may claim,

won.

manufacturer spouts about multicore.

=20

=20

On the other hand is gets increasing difficult to fully feed a processor past 100 MIPS (at whatever instruction word width), at 1 GHz it is sufficiently intractable as to require multiple levels of cache. For one core that is ok but with two, four or more cores cache coherency becomes a real problem, at 80 cores it is intractable. The maximum speeds going on-off chip are limited to about 12 Gbytes/s and that is nearly intractable. Optical interconnect may give us one more 10x speed increase, then again it may not. Distributed machine architectures are scalable to thousands of cores but are much harder to program and do not work well for all applications.

Williams"

If=20

wouldn't=20

How could you feed it over 30 billion memory transactions per second? =46or that matter over 3 billion memory transactions per second? Several sequenced edges are involved, and what about bus width? 64 lane PCIe

How are you going to cool it?

has been found:

In GaAs? Don't think so. Just driving the wires at that speed would take insane amounts of power.

Cheers

Phil Hobbs

quantity has been found:

is big news.

that,

filtering

better then a general purpose core.

becomes a horror.

sense.

point.

not done very well every day,

multicore' remark,

world may claim,

spouts about multicore.

There have been 128-way SMPs with full cache coherency for over a decade, and high performance processors are more like a terabit per second off-chip bandwidth. You do need quite a few I/Os for that! In my previous life, I was working on ways to have hundreds of terabits per second of on-chip bandwidth without causing the chips to melt. You have to get down to below 100 fJ/bit (i.e. 100 uW per Gb/s) to do that.

You can also have machines that are a bit more NUMA-ish(*), i.e. data cached for cores further away takes longer to get. That puts a burden on the compiler and OS to maintain efficiency, but oh, well.

Cheers

Phil

(*) Nonuniform memory access

The RAM part does not sound too demanding.

Assuming sufficient on chip memory, any external DRAM could act as the backing storage in a virtual system, assuming 4 KiB pages (for x86 architecture), a page load would transfer 32 Kib.

A 1 Gib DRAM is arranged as 32 kiRows x 32 KiColumns. Inside a DRAM, in a read request, the row address will be used to represent all bits in a row to the sense amplifiers (and eventually write pack those bits to all bits in the row). The column address is then used to select one (or more) sense amplifier(s) to the output pin(s). In videoRAMs, the row is parallel loaded into a shift register which is then clocked out at high speed.

Assuming 50 ns RAS cycle time, a virtual memory page can be delivered in less than 50 ns (compared to several milliseconds for a disk based backing storage), corresponding to 80 GiBytes/s.

With such long messages, the low speed of light does not destroy the throughput, even if the DRAM and CPU are at some distance from each other (for cooling etc.).

Transferring 80 GiBytes/s with one or few pins would be challenging, even with multilevel coding, however, this optical fiber, this could be realistic with multicolour (WDM) systems.

Why would driving a 50 ohm transmission line require a huge amount of power ? On the receiver side, how many bits would be required to _reliably_ detect if 0 or 1 is sent ?

Assuming -174 dBm/Hz thermal noise density at room temperature, at 80 GHz bandwidth, the thermal noise power would be -65 dBm and assuming a few dB extra required for binary detection, we are still talking about a few nanowatts at the receiver end.

Of course at these frequencies, the transmission line skin effect and dielectric losses on a PCB would be considerable, requiring a high transmitter power and hence limiting the transfer distance.

At such high frequencies, a low loss waveguide would have nearly manageable dimensions for "long distance" communication across the PCB:-).

Lines on ICs aren't 50 ohms, they're all RC. There are millions of them, so even with 200 mV swings you'd be talking about 400 watts per million wires. Lava city. Not to mention that the long lines all have repeaters to preserve the bandwidth, which multiplies the power dissipation.

Cheers

Phil Hobbs

When the speed goes up, the physical distances must be reduced, in which a single synchronous clock can be used and the logic considered by simple RC model.

In the old days a complete 19" box might considered a single entity clocked by a central clock and the interconnections analyzed as RC circuits. The interconnection between the boxes was handled with serial or parallel transmission lines driven by proper line drivers and receivers.

Later on a single card was a self contained unit with transmission line communication through the backplane.

These days the interconnections between ICs on a PCB are often transmission lines.

For even greater speeds, physically small sections within a single IC chip must be considered as independent entities, interconnected asynchronous transmission lines to transfer data between entities. The popularity of multicore processors is a clear indication of this trend.

On an independent entity, much less than 1 mm² in size, what forces using such huge voltage swing ?

At lower speeds with unbalanced logic, the ground bounce will finally eat the noise margin. How about some ECL style gates with true and complement outputs, the ground potential fluctuations would not be significant, thus reducing the required voltage swing and hence power dissipation ?

How many decibels/mm are the losses on a transmission line on the chip?

It's a statement of fact. IC lines do not have resistive terminations because you can't stand the dissipation.

Sure--such as a VAX 11/780, circa 1982. Not any time recently.

Almost always, in high performance computers.

That's one of several reasons for multicore, as I mentioned earlier.

Lots of reasons. For one thing, CMOS wants to swing from rail to rail, and you need a VDD of several times kT/e to have any output drive from any FET whatsoever. If the swing is less than VDD, somebody has to be dissipating a bunch of power to reduce it, unless you want to have a DC-DC converter for every single gate.

The higher you make VDD, the faster the logic goes, until it slows down due limits on the power dissipation density.

That doesn't reduce power dissipation, it just moves it from the load to the driver.

Because the losses per unit length go as 1/sqrt(f), the bandwidth of a given line goes as 1/(length)**2. Repeater spacing depends on clock frequency--I'm not sure what it is in 32-nm CMOS, but it takes several of them to get from one side of a chip to the other.

Cheers

Phil Hobbs

e 1.5 V

ould

ion.

Repeaters aren't used because of loss. They're used because RC is too high. The delay of a line is ~ the square of its length. At some point a gate delay becomes less than the difference between (2l)^2 and

I think that we disagree about what is intraunit and what is interunit communication.

In RF design, the old rule of thumb is that anything longer than about lambda/10 should be treated as a transmission line (in fact lambda/4 is an impedance inverter).

In the old days, the lamda/10 limit was not an issue, as long as the equipment was in the same room. However, if you want to operate with

At such frequencies, communication between the "dots" must be analyzed as transmission lines.

e 1.5 V

of

g a

out

nd

pation.

to

What _are_ you talking about?

We're not talking about RF design. We're not talking about lossless transmission lines.

Irrelevant. You're not going to get millions of transistors switching in that area.

You confuse LC and RC transmission lines.