New soft processor core paper publisher?

Just so, but even such nodes can be the subject of innovation. A recent good example is Sun's Niagara/Rock T series sparcs, which forego OOO and caches in favour of a medium number of cores each operating at the speed of main memory.

You are still thinking von Neumann. Any application can be broken down into small units and parceled out to small processors. But you have to think in those terms rather than just saying, "it doesn't fit". Of course it can fit!

Actually not. The aggregate comms requirements may increase, but we aren't sharing an Ethernet bus. All of the local processors talk to each other and less often have to talk to non-local processors. I think the phone company knows something about that.

If you apply your line of reasoning to FPGAs with the lowly 4 input LUT it would seem like they would be doomed to eternal comms congestion. Look at the routing in FPGAs and other PLDs sometime. They are hierarchical. Works pretty well, but the trade off is in worrying about providing enough comms to let all of the logic be used for every design or just not worrying about it and "making do". Works pretty well if the designers just chill about utilization.

That's me too, but I found some work that is paying off very well now. So I've got a foot in both camps, retired, not retired... both are fun in their own way. But dealing with international shipping is a PITA.

That has got to be fun! I've never worked up the whatever to learn to fly. It seems like a big investment and not so cheap overall. But there is clearly a great thrill there.

--

Rick

Intra brain communications are hierarchical as well.

I'm nobody, but one of the reasons for designing Hive was because I feel pr ocessors in general are much too complex, to the point where I'm repelled b y them. I believe one of the drivers for this over-complexity is the fact that main memory is external. I've been assembling PCs since the 286 days, and I've never understood why main memory wasn't tightly integrated onto t he uP die. Everyone pretty much gets the same ballpark memory size when pu tting a PC together, and I can remember only once or twice upgrading memory after the initial build (for someone else's Dell or similar where the init ial build was anemically low-balled for "value" reasons). Here we are in 2

013, the memory is several light cm away from the processor on the MB, talk ing in cache lines, and I still don't get why we have this gross inefficien cy.

My dual core multi-GHz PC with SSD often just sits there for many seconds a fter I click on something, and malware is now taking me sometimes days to f ix. Windows 7 is a dog to install, with relentless updates that often comp letely hose it rather than improve it. The future isn't looking too bright for the desktop with the way we're going.

RAM was both large and expensive until recently. Different people made RAM than made processors and it would have been challenging to get the business arrangements such that they'd glue up.

Plus, beginning not long ago, you're rwally dealing with cache directly, not RAM. Throw in that main memory is DRAM, and it gets a lot more complicated.

Building a BSP for a new board from scratch with a DRAM controller is a lot of work.

That's not generally the bottleneck, though.

Geez. Ever use virtual machines? If you break/infect one, just roll it back.

--
Les Cargill

I do - I've been doing it for a long time, too. It's not all that hard if you have no libraries getting in the way.

This, by the way, is absolutely nothing fancy. It's precisely the same concepts as when we linked stuff together with serial ports in the Stone Age.

Most *all* concepts in computers are from that long ago or longer. The "new stuff" is more about arbitraging market forces than getting real work done.

I respectfully disagree. But my standard for "decency" is probably different from your'n. My idea of an IDE is an editor and a shell prompt...

So don't do that. Write them to be parallel from the git-go. Write them to be event-driven. It's better in all dimensions.

After all, we're all really clockmakers. Events regulate our "wheels" just like the escapement on a pendulum clock. . When you get that happening, things get to be a lot more deterministic and that is what parallelism needs the most.

--
Les Cargill

(snip)

Not so long ago, some used separate chips for cache in the same package as the CPU die.

I have wondered if processors with large enough cache can run with no external RAM, as long as you stay within the cache.

Then you could call your L3 (I believe) cache the system main memory, either on chip or in the same package.

-- glen

That's not the reason. Intel could buy any of the DRAM makers any day of the week. At several points DRAM divisions of companies were sold off to form merged DRAM specialty companies primarily so the risk was shared by several companies and they didn't have to take such a large hit to their bottom line when DRAM was in the down phase of the business cycle. Commodity parts like DRAMs are difficult to make money on and there is always one of the makers who could be bought easily.

In fact, Intel started out making DRAMs! The main reason why main memory isn't on the CPU chip is because there are lots of variations in size *and* that it just wouldn't fit! You don't put one DRAM chip in a computer, they used to need a minimum of four, IIRC to make up a module, often they were 8 to a module and sometimes double sided with 16 chips to a DRAM module.

The next bigger problem is that CPUs and DRAMs use highly optimized processes and are not very compatible. A combined chip would likely not have as fast a CPU and would have poor DRAM on board.

I'm not so sure. With the multicore processors my understanding is that memory bandwidth *is* the main bottle neck. If you could move the DRAM on chip it could run faster but more importantly it could be split into a bank for each processor giving each one all the bandwidth it could want.

I think a large part of the problem is that we have been designing more and more complex machines so that the majority of the CPU cycles are spent supporting the framework rather than doing the work the user actually cares about. It is a bit like the amount of fuel needed to go into space. Add one pound of payload and you need some hundred or thousand more pounds of fuel to launch it. If you want to travel further out into space, the amount of fuel goes up exponentially. We seem to be reaching the point that the improvements in processor speed are all being consumed by the support software rather than getting to the apps.

--

Rick

Yes. Or even farther back, the chips were remote from the CPU package.

I am sure there are drawers full of papers on the subject :) If you were clever about managing cache misses* and they were sufficiently infrequent, it might work out to be a fraction of the same thing.

*as in "oops, your process gets queued if you have a cache miss".

I am not sure what prevents massive cache from being universal in the first pace. I expect it's pricing.

--
Les Cargill

Regrettably not. People have been trying different techniques for ~50 years, with varying degrees of success as technology bottlenecks change. The people working in those areas are highly intelligent and motivated (e.g. high performance computing research) and there is serious money available (e.g. life sciences, big energy).

As a good rule of thumb, if you can think of it, they've already tried it and found where it does and doesn't work.

That works to an extent, particularly in "embarrassingly parallel" problems such as telco systems. I know: I've architected and implemented some :)

It still has its limits in most interesting computing systems.

Or even sourcing some components, e.g. a MAX9979KCTK+D or +TD :(

Probably better than you imaging (and that's recursive without a terminating condition). I know instructors that still have pleasant surprises after 50 years :)

I did a tiny bit of kayaking on flat water, but now I wear hearing aids :(

Going solo is about as difficult as learning to drive a car. And then the learning really starts :)

Not in money. In the UK club membership is $500/year, a launch + 10 mins instruction is $10, and an hour instruction in the air is $30. The real cost is time: club members help you get airborne, and you help them in return. Very sociable, unlike aircraft with air conditioning fans up front or scythes above.

0-40kt in 3s, 0-50kt in 5s, climb with your feet above your head, fly in close formation with raptors, eyeball sheep on a hillside as you whizz past below them at 60kt, 10-20kft, 40kt-150kt, hundreds and thousands of km range, pre-solo spinning at altitudes that make power pilots blanche, and pre-solo flying in loose formation with other aircraft.

Let me know if you want pointers to youtube vids.

Partly. The random-access latency is also a killer (Sun's Niagara series sparcs have an interesting work-around.)

1) Yield => cost, which is highly non-linear with increasing area. Tolerable for big iron where the processor cost is a small fraction of the total 2) Different semiconductor structures, which are can't be used o the same die.

Download xubuntu, blow it onto a cd/dvd or usb. Reboot and try that "live cd" version without touching your disk.

Live cd has slow disk accesses since everything has to be fetched from cd. But the desktop is blindingly fast, even on notebooks.

No resident malware to worry about (just spearphishing and man-in-the browser attacks).

No endless re-booting whenever updates arrive - and they arrive daily. Only reboots are for kernel upgrades.

Speedy installation: I get a fully-patched installed system in well under an hour. Last time MS would let me (!) install XP, it took me well over a day because of all the reboots.

Speedy re-installation once every 3 years: your files are untouched so you just upgrade the o/s (trivial precondition: put /home on a separate disk partition). Takes < 1 hour.

From the point of view of speed, yes. The DRAM becomes the equivalent of paging to disk. But you still need DRAM to boot :)

Yup, that's the effect. Doesn't work with bloatware :(

Almost, but see how Sun's Niagara architecture circumvented that easily and cheaply.

Bandwidth and latency, particularly the mismatch between processor cycle speed and DRAM random-access cycle time.

You've just re-invented the L3 cache on AMD's Opteron processors :)

In general purpose desktop work, that's true.

For high-performance and industrial computing, it is less clear cut.

There's some truth in that. For most people re-inventing the wheel is completely unprofitable.

Who want to learn iron-mining, smelting, forging, and finishing when all you need to do is cut up this evening's meal.

But not at all scales; there's a reason fine-grained dataflow failed. And not with all timescales :)

Don't get me wrong, I really like event-driven programming, and some programming types are triumphantly re-inventing it yet again, many-many layers up the software stack!

For example, and to torture the nomenclature: - unreliable photons/electons at the PMD level - unreliable bits at the PHY level - reliable bits, unreliable frames at MAC level - reliable frames, unreliable packets at the IP level - reliable packets, unreliable streams at the TCP level - reliable streams, unreliable conversations at the app level - app protocols to make conversations reliable - reliable conversations within apps: - protocols to make apps reliable - streams to send unreliable message events - frameworks to make message events reliable where some of the app and framework stuff looks *very* like some of the networking stuff.

But I'm not going to throw the baby out with the bathwater: there are *very* good reasons why most (not all) of those levels are there.

My XP PC doesn't get infected too often, but I build PCs and do tech suppor t on the side for family and friends, so their problems become my problems. My last Win7 build took several days just to stabilize with all the updat es. One update put it in a permanent update loop and that took me a while to even notice. And I've got a Win7 laptop sitting here that for the life of me I can't get to run outside of safe mode. I did a repair install (mal ware knocked out system restore rollback) and it works fine until the .net v4 updates hit after which it stutters and the HD disappears. I don't get all the accolades for Win7, it's a dog.

I refuse, unless they let me install some version of Linux; so far the people that have accepted have been happy.

What?! That's ridiculous. I can just about understand that for the decade old XP (kudos to MS for supporting it for that long). But I sure can't see why that should be true for Win7.

Why not just do a full re-install from CD?

I was thinking of getting Win7 to replace XP when MS withdraw support next year. Now I'm in doubt. As for Win8: "just say no" (everyone else does).

Yes, but it is better than Vista, and the hacks don't feel so guilty about supporting it.

Good things about linux: fanbois are vocally and acerbically critical when things don't work smoothly, and then point you towards the many alternatives that /do/ work smoothly.

Zillions of updates that only begin to slow down coming at you after two da ys or so.

It's a couple of days trying to repair vs. a couple of days reinstalling an d updating. The former is usually the safe bet but I think I've met my mat ch in this laptop (which I previously did a reinstall on due to a hard driv e crash).

t year. Now I'm in doubt.

I'm riding XP Pro until the hubcaps fall off.

t supporting it.

I'm beginning to think the whole "every other MS OS is a POS, and every oth er one is golden" meme is 99% marketing. I work on a couple of Vista machi nes here and there and Win7 seems about the same in terms of fixing things (i.e. a dog). XP has it's issues as well, but it is simpler and there are more ways to fix it without blowing absolutely everything off the HD. I ju st want an OS that mounts a drive, garbage collects, and runs the programs I'm familiar with (the last is the kicker).

I have to presume they "couldn't", because they didn't. But memory architectures did evolve over time - I believe 286 machines still used DIP packages for DRAM. And the target computers I used from the mid-80s to the mid-90s may well have still used SRAM.

At that point, by the time SIP/SIMM/DIMM modules were available, the culture expected things to be seperate. We were also arbitraging RAM prices - we'd buy less-quantity, more-expensive DRAM now, then buy bigger later when the price dropped.

Some of that was doubtless retail behavioral stuff.

Right. So if you integrate it into the main core package, you no longer have to suffer as a commodity vendor. It's a captive market.

I'm sure it's not that simple.

Precisely! They did one of the first "bet the company" moves that resulted in the 4004.

If you were integrating inside the package, you could use any physical configuration you wanted. But the thing would still have been too big.

I also have to wonder if the ability to cool things was involved.

That's consistent with my understanding as well. The big thing on transputers in the '80s was the 100MBit links between them. As we used to say - "the bus is usually the bottleneck". Er, at least once you got past 10MHz clock speeds...

Yep - although it's eminently possible to avoid this problem. I use a lot of old programs - some going back to Win 3.1.

Really, pure 64-bit computers would have completely failed had there not been the abiity to run a legacy O/S in a VM or run 32 bit progs through the main O/S.

So Project X is trying to do something about that. There is something about engineering culture that "wants scale" - a Saturn V is a really impressive thing to watch, I am sure.

But things like BeOS and the like have been available, and remain widely unused. There is some massive culture fail in play; either that or things are just good enough.

Heck, pad/phone computers do much much *less* than desktops and have the bullet in the market. You can't even type on them but people still try...

--
Les Cargill

Ah! Right.

Holy cow. I would be tempted to just not do that, then.

Yeah, that's ugly. Although that's more the update infrastructure that's ugly rather than Win7 itself.

--
Les Cargill