From: joswig on
On 1 Nov., 20:50, Tim Bradshaw <t...(a)cley.com> wrote:
> On 2009-11-01 19:19:21 +0000, vippstar <vipps...(a)gmail.com> said:
>
> > With the exception C processors never existed.
>
> Actually, they did.  There were processors produced by AT&T / Bell Labs
> in the 80s and early 90s which were heavily oriented to C.  I think
> these were the CRISP and Hobbit (which may have been the same, I'm not
> sure.
>
> But my point was that people don't optimise processors to for a
> particular HLL any more (or for ease of programming in assembler).

They build processors just so? Intel does not look at the Microsoft
software stack? The Intel C compiler exists for fun?


From: Tim Bradshaw on
On 2009-11-01 19:55:12 +0000, "joswig(a)corporate-world.lisp.de"
<joswig(a)lisp.de> said:

> They build processors just so? Intel does not look at the Microsoft
> software stack? The Intel C compiler exists for fun?

Yes, of course they look at the software stack: the point I am trying
to make is that they no longer put naive language-specific features
into designs because they are almost always a disaster, and compilers
are much better now.

(The ARM JVM-support stuff you mention seems to be an exception to
this: I'd be interested in knowing how much use it gets.
Interestingly, of course, the JVM is itself an example of the kind of
catastrophe you get when you let software people lose on (virtual)
machine design. Half of the effort to make Java go fast has been using
various JIT techniques to convert from the stupid JVM stack
architecture to something a bit less 70s.)

I'm not going to respond further in this thread: what I'm saying is not
exactly controversial to anyone who doesn't have romantic ideas about
certain dead systems.

From: joswig on
On 1 Nov., 21:08, Tim Bradshaw <t...(a)cley.com> wrote:
> On 2009-11-01 19:55:12 +0000, "jos...(a)corporate-world.lisp.de"
> <jos...(a)lisp.de> said:
>
> > They build processors just so? Intel does not look at the Microsoft
> > software stack? The Intel C compiler exists for fun?
>
> Yes, of course they look at the software stack: the point I am trying
> to make is that they no longer put naive language-specific features
> into designs because they are almost always a disaster, and compilers
> are much better now.
>
> (The ARM JVM-support stuff you mention seems to be an exception to
> this: I'd be interested in knowing how much use it gets.  
> Interestingly, of course, the JVM is itself an example of the kind of
> catastrophe you get when you let software people lose on (virtual)
> machine design.  Half of the effort to make Java go fast has been using
> various JIT techniques to convert from the stupid JVM stack
> architecture to something a bit less 70s.)

http://blogs.azulsystems.com/cliff/2008/11/a-brief-conversation-with-david-moon.html

Check out the offerings of them. Looks like exactly the thing you say
nobody does:

'Azul Systems provides a network computing appliance which has as a
close parallel with NAS. At the center of their appliance is the Azul
Vega 1 processor which is capable of scaling to 384 coherent threads
per system – well beyond even the Intel IA64 Montecito.

It is estimated that 50% of the enterprise applications are today
being developed in Java and by 2006 80% will migrate to Java. With J2E
being fully multi-threaded it can be effectively employed on a virtual
machine targeted to executing the Java VM.

The Azul Vega processor does not expose its instruction set because it
executes the Java VM code. A major improvement made with the Vega is
“pauseless” garbage collection. The processor has 24 cores per chip.
The design supports multi-chip SMP where each processor has complete
and equal access to memory.

An appliance which is 11RU has up to 384 cores and 256GB of memory.
The appliance can respond to spikes in processor demand in 10ms. The
implementation requires no changes to existing Java applications and
the appliance is OS agnostic. The appliance can just be plugged into
the data center and it runs.

One of the first commercial installations is in travel industry for
reservations – the company is Pegasus. They had 8 X 8 SPARC and 4 X 2
way SPARC servers – 72 CPUs which were running at 70% utilization.
When an Azul appliance was added, 15 cores, its utilization was only
3%. The system still included a 3 X 2 SPARC server running at 70%
utilization. The net result was a reduction in CPUs from 72 to 6.'





From: joswig on
On 1 Nov., 21:08, Tim Bradshaw <t...(a)cley.com> wrote:
> On 2009-11-01 19:55:12 +0000, "jos...(a)corporate-world.lisp.de"
> <jos...(a)lisp.de> said:
>
> > They build processors just so? Intel does not look at the Microsoft
> > software stack? The Intel C compiler exists for fun?
>
> Yes, of course they look at the software stack: the point I am trying
> to make is that they no longer put naive language-specific features
> into designs because they are almost always a disaster, and compilers
> are much better now.
>
> (The ARM JVM-support stuff you mention seems to be an exception to
> this: I'd be interested in knowing how much use it gets.  
> Interestingly, of course, the JVM is itself an example of the kind of
> catastrophe you get when you let software people lose on (virtual)
> machine design.  Half of the effort to make Java go fast has been using
> various JIT techniques to convert from the stupid JVM stack
> architecture to something a bit less 70s.)
>
> I'm not going to respond further in this thread: what I'm saying is not
> exactly controversial to anyone who doesn't have romantic ideas about
> certain dead systems.

IBM offers a $125000 processor for mainframes which have JVM support
in microcode:

http://en.wikipedia.org/wiki/Z_Application_Assist_Processor

From: Pascal J. Bourguignon on
"joswig(a)corporate-world.lisp.de" <joswig(a)lisp.de> writes:
> IBM offers a $125000 processor for mainframes which have JVM support
> in microcode:
>
> http://en.wikipedia.org/wiki/Z_Application_Assist_Processor

I assume a corporation with a need for a lot of lisp cycles, could use
such a processor, rewriting the microcode for a lisp machine...

--
__Pascal Bourguignon__