Power 7 CPU - 8 cores

[Iggy]

But everyone that can buy SAM or X1000 should do so.

Seriously considering a 460, Vox.
Can't justify an X1000, but I'm hoping that whatever Varisys designs as its sucessor is more affordable.

[vox]

Seriously considering a 460, Vox.
Can't justify an X1000, but I'm hoping that whatever Varisys designs as its sucessor is more affordable.

Have been doing the same, but after painful experience with building DJ Nicks SAM 460 board to fully usable system, and also comparing board exapandability and performance, X1000 is in my eyes better solution. Not to mention additional OS 4.2 licence for SAM.

However, who doesn‚t have patience to save and again wait for X1000 should go for SAM 460. 1Ghz CPU, DDR2 and SATA2 is nice setup. Would love to see MorphOS for it too. Debian Wheezy and OS 4.1.5 for now ...

[Iggy]

Yeah, the MorphOS development team has pretty much ruled out support for Acube hardware, but I wouldn't mind it either.
And the neat thing about the 460 (as opposed to the 400) is that you can use modern video cardss on it.
 
A Radeon HD 4650 or 4670 should work with the same drivers used on the X1000.

[vox]

Yeah, the MorphOS development team has pretty much ruled out support for Acube hardware, but I wouldn't mind it either.
And the neat thing about the 460 (as opposed to the 400) is that you can use modern video cardss on it.
 
A Radeon HD 4650 or 4670 should work with the same drivers used on the X1000.

It is sad they don`t wan`t to be avail for avail new HW (it would be much better representation to the world even with high price of SAMs, but 440 can now replace Efika as low end and 460 could be about Peg2 with PCI-E and SATA2). Some licences would be bought, and  more importantly, possibility for OS4 crowd to test and maybe even recompile, create for MorphOS.

PCIE bus is the major advancement of SAM 460 surely.

But when compared in expandability (USB, PCI ...) as well as in board pecularities of having awful integrated everything, X1000 is my choice. Hopefully, board will be fully supported and OS 4.2 out by the time I save $3000 + P&P + import fees ... in a country with 500$ average salary.

[Fats]

I suppose I need context for that.  If it's a current university professor expousing such things, yeah, I don't see how he could still believe that in the present day.

If it were university from 10+ years ago, ok, maybe I buy that he wasn't in a minority opinion at the time.

It was how people thought 10+ ago and the professor was certainly not alone in that line of thinking. The professor is retired now and I attended a lecture from him some months ago. He is now predicting a stop for the scaling around the 7nm. Making transistors that are smaller is claimed to be too difficult from physics point of view and chips should be able to do all we want from them...
My personal opinion is that as long that a chip can't run a game with
a) real-time movie quality graphics
b) opponents with human level intelligence
c) do that continuously for let's say one week when running of a battery
we will keep on scaling.

greets,
Staf.

[Hattig]

7nm is the current silicon wall that everybody is agreeing on (although it used to be 10nm, and before that 14nm, so don't bet on it not being worked around eventually).

[haywirepc]

So just make the chips bigger... I don't see a problem with that. Make the chip the size of current motherboards for all I care... Just make faster chips, whatever it takes. :laugh1:

[vidarh]

So just make the chips bigger... I don't see a problem with that. Make the chip the size of current motherboards for all I care... Just make faster chips, whatever it takes. :laugh1:

Two problems:

Speed of light. If a signal can't get from one end of the chip to the other in a clock cycle, you effectively have to start designing asynchroneous / clockless systems for starters. But more importantly our current programming model starts falling apart and every app that wants to take advantage of it will need to work like a large distributed system with all the complexities that involves.

Heat. Pumping heat away fast enough is the biggest current problem to upping clock speed. E.g. with custom (read: expensive) cooling, doubling to tripling current clock frequencies is doable, but you end up with a cooling system that's many times larger than the CPU with current tech.

So at some point we'll need to figure out smarter approaches instead of just throwing more transistors at the performance problem.

[Iggy]

So at some point we'll need to figure out smarter approaches instead of just throwing more transistors at the performance problem.

Yep, smarter, more efficient designs that make better use of those transistors.
 
BTW - Everyone take a good look at Vox's posts (at least as long as they aren't deleted). He seemed like a positive member of he community.

[Hattig]

So just make the chips bigger... I don't see a problem with that. Make the chip the size of current motherboards for all I care... Just make faster chips, whatever it takes. :laugh1:

Unfortunately yield drops by the square of the increase in chip area.

Fortunately technologies such as Silicon Interposer, Through Silicon Via, etc, will allow for many smaller dies to be used as a single chip, via various implementations of die stacking.

http://semiaccurate.com/2012/09/05/hot-chips-talks-all-about-chip-stacking-good-and-bad/
http://semiaccurate.com/2012/09/06/die-stacking-has-promise-and-problems/

[psxphill]

On the other hand, half the reason that's even true is because of the omnipresence of terribly slow (and almost always completely unnecessary) Javascript in modern websites, so even though there is a benefit from a properly multithreaded browser, it's mostly in making bad code less crippling.

I'm not going to defend every use of javascript as there are some very bad examples out there. However there will always be good uses for it and because websites have become more important, web browsers are becoming more standardised so we're unlikely to see major shifts in the the way websites are designed. HTML5 is mainly just a load of old technologies that have been standardised. I blame tim berners lee, but they knighted him.
 

Teachers have their own biases which are sometimes at odds with the real world.

Which is usually why they become teachers. It's much easier to tell people incorrect things, if they don't know any better.

[commodorejohn]

I'm not going to defend every use of javascript as there are some very bad examples out there. However there will always be good uses for it and because websites have become more important, web browsers are becoming more standardised so we're unlikely to see major shifts in the the way websites are designed. HTML5 is mainly just a load of old technologies that have been standardised. I blame tim berners lee, but they knighted him.

There are indeed some good uses for it - and they aren't the problem. Good Javascript, when it can be found, does only what static page content and server-side scripting can't, and does so efficiently, such that even an old browser can handle it. (I can log into GMail from iWeb on my A1200, for example.) The problem is bad Javascript, which is far more common, almost omnipresent in these days of glitz-focused "Web 2.0" design.

Bad Javascript eats up CPU cycles like popcorn, usually for no other purpose than to make "dynamic" a page that would have been perfectly fine static, or to badly reimplement basic browser functionality. (There is nothing in the world that makes me want to harm my fellow man the way Javascript links do.) The only way to avoid it is to have a Javascript whitelist feature such as NoScript, because it's currently still illegal to kill someone for bad web design. And it gets worse every year.

Good Javascript needs no special measures to work. Bad Javascript is the primary (almost the only) reason people keep having to throw more horsepower at a web browser.

As far as HTML5 goes, I know that HTML4 needed a cleanup, but this just gives more free reign to bad Javascript programmers. It isn't what was needed in the slightest.

[minator]

Speed of light. If a signal can't get from one end of the chip to the other in a clock cycle

This problem was encountered and fixed years ago.  IIRC the Pentium 4 was suspected to have pipeline stages just for moving things around.