Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #15821 > unrolled thread

Java processors

Back to article view | Back to comp.lang.java.programmer

Contents

  Java processors bob smith <bob@coolfone.comze.com> - 2012-07-05 08:01 -0700
    Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-05 11:28 -0400
      Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 13:00 -0500
        Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-05 14:31 -0400
          Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 16:42 -0500
          Re: Java processors Arne Vajhøj <arne@vajhoej.dk> - 2012-07-05 20:30 -0400
            Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 21:12 -0500
            Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-06 00:13 -0400
              Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:26 -0700
                Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-06 13:50 -0700
                  Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-06 14:17 -0700
                    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:07 -0700
                      Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 09:34 -0500
                        Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-07 21:01 -0700
                          Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 00:28 -0500
                            Re: Java processors Lew <noone@lewscanon.com> - 2012-07-07 23:00 -0700
                              Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 10:20 -0500
                                Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 09:16 -0700
                              Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-08 17:46 +0000
                                Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 11:52 -0700
                                  Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-08 21:41 +0000
                                    Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 17:56 -0700
                                      Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:44 -0700
                                        Re: Java processors Lew <noone@lewscanon.com> - 2012-07-09 23:41 -0700
                                      Re: Java processors David Lamb <dalamb@cs.queensu.ca> - 2012-07-16 13:22 -0400
                                        Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-16 14:03 -0700
                                  Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:42 -0700
                      Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-10 01:13 +0200
                        Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-09 16:26 -0700
                        Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-11 15:41 -0700
                          Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-12 01:02 +0200
                        Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-21 18:46 +0200
                          Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-21 13:05 -0400
                            Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-21 19:23 +0200
                              Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-21 14:10 -0400
                                Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-23 01:17 +0200
                                  Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-22 20:15 -0400
                          Re: Java processors Daniele Futtorovic <da.futt.news@laposte-dot-net.invalid> - 2012-07-22 15:13 +0200
                  Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:03 -0700
                    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 19:51 -0700
                Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-07 21:17 -0700
                  Re: Java processors Lew <noone@lewscanon.com> - 2012-07-07 23:04 -0700
                    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-08 09:29 -0700
                      Re: Java processors Lew <noone@lewscanon.com> - 2012-07-08 11:57 -0700
              Re: Java processors Wanja Gayk <brixomatic@yahoo.com> - 2012-07-08 15:40 +0200
                Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-08 10:36 -0500
            Re: Java processors Lew <lewbloch@gmail.com> - 2012-07-06 11:31 -0700
        Re: Java processors Jim Janney <jjanney@shell.xmission.com> - 2012-07-05 13:02 -0600
          Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-05 16:09 -0500
          Re: Java processors Jan Burse <janburse@fastmail.fm> - 2012-07-06 01:29 +0200
            Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 00:42 +0000
              Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:53 -0700
                Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 21:18 +0000
                  Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-06 18:17 -0400
                    Re: Java processors Martin Gregorie <martin@address-in-sig.invalid> - 2012-07-06 22:29 +0000
                    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:10 -0700
                      Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 09:42 -0500
                        Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 10:58 -0400
                      (OT) Was: Re: Java processors Eric Sosman <esosman@ieee-dot-org.invalid> - 2012-07-07 11:38 -0400
                        Re: (OT) Was: Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-07 21:19 -0700
                          Re: (OT) Was: Re: Java processors "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-07-08 12:15 +0200
                      Re: Java processors Gene Wirchenko <genew@ocis.net> - 2012-07-07 21:17 -0700
            Re: Java processors Jim Janney <jjanney@shell.xmission.com> - 2012-07-05 19:14 -0600
          Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:34 -0700
            Re: Java processors Jan Burse <janburse@fastmail.fm> - 2012-07-06 23:04 +0200
              Re: Java processors Silvio Bierman <silvio@moc.com> - 2012-07-07 00:13 +0200
                Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 19:16 -0700
                  Re: Java processors "Peter J. Holzer" <hjp-usenet2@hjp.at> - 2012-07-08 11:37 +0200
        Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 13:24 -0700
          Re: Java processors BGB <cr88192@hotmail.com> - 2012-07-07 10:06 -0500
    Re: Java processors Roedy Green <see_website@mindprod.com.invalid> - 2012-07-06 05:22 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#15865

On Fri, 06 Jul 2012 13:26:58 -0700, Roedy Green
<see_website@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :

>
>That is just what JITs do. It is only after a while they have gathered
>some stats to they decide which classes to turn to machine code. The
>astounding thing is they stop the interpreter in mid flight executing
>a method, and replace it with machine code and restart it. That to me
>is far more impressive than walking on water.

I wonder how long until hyperjits.  They would burn a programmable
gate array to handle the innermost loops once they saw it was
justified.  It would be optimised to the gate level.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15870

Roedy Green wrote:
>> That is just what JITs do. It is only after a while they have gathered
>> some stats to they decide which classes to turn to machine code. The
>> astounding thing is they stop the interpreter in mid flight executing
>> a method, and replace it with machine code and restart it. That to me
>> is far more impressive than walking on water.
>
> I wonder how long until hyperjits.  They would burn a programmable
> gate array to handle the innermost loops once they saw it was
> justified.  It would be optimised to the gate level.

How would these guys "unburn" the gates - reprogram them to a different 
configuration?

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#15877

On Sat, 07 Jul 2012 23:04:37 -0700, Lew <noone@lewscanon.com> wrote,
quoted or indirectly quoted someone who said :

>
>How would these guys "unburn" the gates - reprogram them to a different 
>configuration?

they would not.  Presumably these things would be so cheap that you
would just replace a bank that had too many pieces of abandoned code,
and repack them onto a fresh bank, like the way the Replicator repacks
zips when they get too full of junk.  If there were sufficiently
dense, e.g. some sort of 3D array, you might just keep everything.

Also somebody might invent an erasable array, where you don't
literally burn, just program.

I hope somebody does this in the lab no matter how impractical just to
find out the order of magnitude efficiency improvement that could be
had.
-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15880

Roedy Green wrote:
> Lew wrote, quoted or indirectly quoted someone who said :
>> How would these guys "unburn" the gates - reprogram them to a different
>> configuration?
>
> they would not.  Presumably these things would be so cheap that you
> would just replace a bank that had too many pieces of abandoned code,
> and repack them onto a fresh bank, like the way the Replicator repacks
> zips when they get too full of junk.  If there were sufficiently
> dense, e.g. some sort of 3D array, you might just keep everything.
>
> Also somebody might invent an erasable array, where you don't
> literally burn, just program.
>
> I hope somebody does this in the lab no matter how impractical just to
> find out the order of magnitude efficiency improvement that could be
> had.

The reason I ask is that the HotSpot compiler works by compiling and 
uncompiling sections of code many times as program dynamics dictate.

Write-once mechanisms will need huge capacity to handle the myriads of 
abandoned code fragments. Also, the compilation is occurring during program 
execution, so they'd also have to be write-extremely-fucking-fast, or WEFF.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg

[toc] | [prev] | [next] | [standalone]

#15873

In article <jt5okh$53a$1@dont-email.me>, esosman@ieee-dot-org.invalid 
says...

>      My colleague's point was that JITting the code, aggressively
> or not, is pre-execution overhead: It is work spent on something
> other than running your code. 

Thet's a pretty single threaded point of view.

> If you just dove in and started
> interpreting you might be running more slowly, but you'd have a
> head start: Achilles is the faster runner, but cannot overcome
> the tortoise's lead if the race is short.

In fact optimiziation, profiling an compiling can be done while the code 
is being interpreted.

>      I dunno: Are JIT's nowadays smart enough to recognize code
> that will (future tense) execute too few times to be worth JITting?

As far as I know it does take things like simple loop counters into 
account when comparing invocation counts to the compilation threshold, 
so it can compile more eagerly.

Kind regards,
-Wanja-


-- 
..Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#15875

On 7/8/2012 8:40 AM, Wanja Gayk wrote:
> In article <jt5okh$53a$1@dont-email.me>, esosman@ieee-dot-org.invalid
> says...
>
>>       My colleague's point was that JITting the code, aggressively
>> or not, is pre-execution overhead: It is work spent on something
>> other than running your code.
>
> Thet's a pretty single threaded point of view.
>
>> If you just dove in and started
>> interpreting you might be running more slowly, but you'd have a
>> head start: Achilles is the faster runner, but cannot overcome
>> the tortoise's lead if the race is short.
>
> In fact optimiziation, profiling an compiling can be done while the code
> is being interpreted.
>

potentially, but some profiling activities will risk reducing 
interpreter performance, since they have to be done inline with 
interpreting the code (for example, updating counters, ...).

if the program is both multi-threaded and CPU bound, then the effects of 
a JIT running in a different thread may be visible, but granted, it is 
also fairly unlikely for many apps (many are not CPU-bound, and many of 
which are CPU bound have most of their activity concentrated in 1 or 2 
threads anyways).


>>       I dunno: Are JIT's nowadays smart enough to recognize code
>> that will (future tense) execute too few times to be worth JITting?
>
> As far as I know it does take things like simple loop counters into
> account when comparing invocation counts to the compilation threshold,
> so it can compile more eagerly.
>

yep.

a simple strategy like "compile this code once it has been executed N 
times" actually works reasonably well.

code executed less than this remains interpreted, and probably isn't 
really a huge time-waster anyways, whereas code which is executed often 
will more quickly trigger the JIT to "do its thing" (causing it to go 
faster).

[toc] | [prev] | [next] | [standalone]

#15839

Arne Vajhøj wrote:
> (or equivalent) is rather aggressive about JIT compiling.
> 
> .NET CLR always does it first time I believe.

WRT Java, there are options such as "-XX:CompileThreshold=10000" (default for -server).

That means that the HotSpot compiler sees the same code 10000 times 
before deciding to compile it.

<http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html>

There's a reason performance white papers for Java discuss 
GC and other options. They can influence performance more than 
JIT does.

<http://www.oracle.com/technetwork/java/javase/tech/performance-jsp-141338.html>

Not that optimization of the JITter is a bad idea.

<http://www.oracle.com/technetwork/java/6-performance-137236.html#2.1.6>

You can see the effect of memory and other non-JIT enhancements on 
the performance of Java 6 here:
<http://www.oracle.com/technetwork/java/6-performance-137236.html#2.3>

<http://www.oracle.com/technetwork/java/hotspotfaq-138619.html>

Perhaps the source code will help you understand:
<http://openjdk.java.net/groups/hotspot/>

-- 
Lew

[toc] | [prev] | [next] | [standalone]

#15825

BGB <cr88192@hotmail.com> writes:

> On 7/5/2012 10:28 AM, Eric Sosman wrote:
>> On 7/5/2012 11:01 AM, bob smith wrote:
>>> What ever happened to those processors that were supposed to run Java
>>> natively?
>>>
>>> Did Sun or anyone else ever make those?
>>
>> http://en.wikipedia.org/wiki/Java_processor
>>
>> (If you need help clicking links, just ask.)
>>
>
> and, of those, AFAIK, ARM's Jazelle was the only one to really gain
> much widespread adoption, and even then is largely being phased out in
> favor of ThumbEE, where the idea is that instead of using direct
> execution, a lightweight JIT or similar is used instead.
>
> part of the issue I think is that there isn't really all that much
> practical incentive to run Java bytecode directly on a CPU, since if
> similar (or better) results can be gained by using a JIT to another
> ISA, why not use that instead?

The cost of entry into CPU manufacturing is far from cheap, and once
you're in it's anything but a level playing field.  Intel has an
enormous advantage due to the amount of money it can plow into improving
its manufacturing processes.  And the demand for a system that can only
run JVM-based software is relatively limited.

Back in the day Niklaus Wirth had a system that was optimised for
running Modula-2, with its own processor and operating system written in
Modula-2.  I don't remember now what it was called.

-- 
Jim Janney

[toc] | [prev] | [next] | [standalone]

#15829

On 7/5/2012 2:02 PM, Jim Janney wrote:
> BGB <cr88192@hotmail.com> writes:
>
>> On 7/5/2012 10:28 AM, Eric Sosman wrote:
>>> On 7/5/2012 11:01 AM, bob smith wrote:
>>>> What ever happened to those processors that were supposed to run Java
>>>> natively?
>>>>
>>>> Did Sun or anyone else ever make those?
>>>
>>> http://en.wikipedia.org/wiki/Java_processor
>>>
>>> (If you need help clicking links, just ask.)
>>>
>>
>> and, of those, AFAIK, ARM's Jazelle was the only one to really gain
>> much widespread adoption, and even then is largely being phased out in
>> favor of ThumbEE, where the idea is that instead of using direct
>> execution, a lightweight JIT or similar is used instead.
>>
>> part of the issue I think is that there isn't really all that much
>> practical incentive to run Java bytecode directly on a CPU, since if
>> similar (or better) results can be gained by using a JIT to another
>> ISA, why not use that instead?
>
> The cost of entry into CPU manufacturing is far from cheap, and once
> you're in it's anything but a level playing field.  Intel has an
> enormous advantage due to the amount of money it can plow into improving
> its manufacturing processes.  And the demand for a system that can only
> run JVM-based software is relatively limited.
>
> Back in the day Niklaus Wirth had a system that was optimised for
> running Modula-2, with its own processor and operating system written in
> Modula-2.  I don't remember now what it was called.
>

yes, but ARM already had direct JBC execution in the form of Jazelle, 
which it is then phasing out in favor of ThumbEE, which is a JIT-based 
strategy.

I suspect this is telling, IOW, that even when one *can* directly 
execute on raw hardware, does it actually buy enough to make it worthwhile?

these occurrences imply a few things: Java is a fairly big thing on ARM, 
and even then it was likely either not sufficiently performance or 
cost-effective to keep direct execution, leading to a fallback strategy 
of making extensions to ease JIT compiler output.


yes, on x86 targets, it is a much harder sell.

[toc] | [prev] | [next] | [standalone]

#15831

Jim Janney schrieb:
> Back in the day Niklaus Wirth had a system that was optimised for
> running Modula-2, with its own processor and operating system written in
> Modula-2.  I don't remember now what it was called.

Do you mean?
http://en.wikipedia.org/wiki/Lilith_%28computer%29

[toc] | [prev] | [next] | [standalone]

#15834

On Fri, 06 Jul 2012 01:29:51 +0200, Jan Burse wrote:

> Jim Janney schrieb:
>> Back in the day Niklaus Wirth had a system that was optimised for
>> running Modula-2, with its own processor and operating system written
>> in Modula-2.  I don't remember now what it was called.
> 
> Do you mean? http://en.wikipedia.org/wiki/Lilith_%28computer%29

Well spotted.

IIRC that was roughly contemporary with the Burroughs x700 systems, which 
had an interesting take on virtualisation: its MCP OS ran each user 
program in a VM that supported the conceptual model used by its 
programming language, so a FORTRAN program ran in a word-addressed VM 
with a register set, COBOL ran in a byte-addressed VM (also with 
registers) while Algol/Pascal/C (if it had existed at the time), ran in a 
stack-based VM, all using instruction sets that suited that programming 
model. Unfortunately I never got to play with that kit, but wish I had 
known more about it because it was well ahead of its time.

The nearest I got to that, somewhat later, was a 2966 running 1900 
programs (24bit word addressed, register-based, 6 bit ISO characters) 
under George 3 simultaneously with native programs (byte-addressed, stack-
based, 8-bit EBCDIC characters) under VME/B. 

IMHO the 2966 trick of hosting a VM per OS with appropriate microcode was 
neat, but was blown away by the Burroughs trick of spinning up the 
appropriate VM for each application program and controlling the lot from 
the same OS. IBM's OS/400 could do this to run S/36 software on an AS/400 
but I don't know of anything else that comes close.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#15844

On Fri, 6 Jul 2012 00:42:25 +0000 (UTC), Martin Gregorie
<martin@address-in-sig.invalid> wrote, quoted or indirectly quoted
someone who said :

>Unfortunately I never got to play with that kit, but wish I had 
>known more about it because it was well ahead of its time

I got to write code for the  Burroughs 1900, a successor. The code
density was about 10 times what I was used to. I loved the machine,
but it was not that much fun to code since everything was done at a
high level language level.   It was just so straightforward. The thing
I found most fun was NCP language.  Even a salesman could write a
custom program for polling a set of multi-drop terminals.

The underlying hardware had only 24 bits addressing, but it was bit
addressable. That let you address bytes with 21 bits, a mere 2
megabytes.Yet that little machine pumped out transactions like you
would not believe.  It used memory very cleverly dynamically balancing
system, app, database, disk cache.

I suppose they could have extended the architecture, leaving the
per-process limits in place. Univac and Burroughs merged to form
UniSys.  I don't know what happened to their various architectures.  

Univac had the 1100 36 bit machines, and some mid range IBM
compatibles inherited from RCA. Burroughs had the high end Algol
machines (fiendishly complex), mid range decimal addressed (designed
for easy assembler coding) and the 1900 series -- the interpreter per
language design.


-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15847

On Fri, 06 Jul 2012 13:53:21 -0700, Roedy Green wrote:

> The underlying hardware had only 24 bits addressing, but it was bit
> addressable. That let you address bytes with 21 bits, a mere 2
> megabytes.Yet that little machine pumped out transactions like you would
> not believe.  It used memory very cleverly dynamically balancing system,
> app, database, disk cache.
>
As I'm certain you know, driving 24x80 green screens allowed machines to 
use very much less memory than today's hardware with its memory-hungry 
high-resolution graphics. The BBC's pair of 2966s could each run 10-12 
online IDMSX-based systems, which together were accessed by 300-400 
terminals, yet each machine did all that with 16 MB of RAM.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#15849

On 7/6/2012 5:18 PM, Martin Gregorie wrote:
> On Fri, 06 Jul 2012 13:53:21 -0700, Roedy Green wrote:
>
>> The underlying hardware had only 24 bits addressing, but it was bit
>> addressable. That let you address bytes with 21 bits, a mere 2
>> megabytes.Yet that little machine pumped out transactions like you would
>> not believe.  It used memory very cleverly dynamically balancing system,
>> app, database, disk cache.
>>
> As I'm certain you know, driving 24x80 green screens allowed machines to
> use very much less memory than today's hardware with its memory-hungry
> high-resolution graphics. The BBC's pair of 2966s could each run 10-12
> online IDMSX-based systems, which together were accessed by 300-400
> terminals, yet each machine did all that with 16 MB of RAM.

     "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
But yew troi tellin' the kids nawadays ..."

     [*] A couple decades ago it suddenly dawned on me that my
rather bare-bones video card had sixteen times the memory of my
college's mainframe.  But yew troi tellin' the kids nawadays ...

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15850

On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman wrote:

> On 7/6/2012 5:18 PM, Martin Gregorie wrote:
>> On Fri, 06 Jul 2012 13:53:21 -0700, Roedy Green wrote:
>>
>>> The underlying hardware had only 24 bits addressing, but it was bit
>>> addressable. That let you address bytes with 21 bits, a mere 2
>>> megabytes.Yet that little machine pumped out transactions like you
>>> would not believe.  It used memory very cleverly dynamically balancing
>>> system,
>>> app, database, disk cache.
>>>
>> As I'm certain you know, driving 24x80 green screens allowed machines
>> to use very much less memory than today's hardware with its
>> memory-hungry high-resolution graphics. The BBC's pair of 2966s could
>> each run 10-12 online IDMSX-based systems, which together were accessed
>> by 300-400 terminals, yet each machine did all that with 16 MB of RAM.
> 
>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz. But yew
> troi tellin' the kids nawadays ..."
> 
>      [*] A couple decades ago it suddenly dawned on me that my
> rather bare-bones video card had sixteen times the memory of my
> college's mainframe.  But yew troi tellin' the kids nawadays ...

I wuz IMPRESSD by awl thet MEMORY in the 2966. 

The biggest 1900 I ever used, a 1904S, had 256 Kwords of core memory 
(24bit words). The one that taught me how to tune George 3 was a 1903S 
with 32 Kwords of core memory - the equivalent of either 96 kB (counting 
bits) or 128 KB (counting characters). The 1900 packed 4 6-bit ISO 
characters into a word. 


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

[toc] | [prev] | [next] | [standalone]

#15854

On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
someone who said :

>     "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>But yew troi tellin' the kids nawadays ..."

Univac made a unit record handling computer with 16K.  Yet we had
threads in the thing and look-ahead i/o.  Someday people won't believe
this.  A beast like this ran the Vancouver Stock exchange.

-- 
Roedy Green Canadian Mind Products
http://mindprod.com
Why do so many operating systems refuse to define a standard 
temporary file marking mechanism? It could be a reserved lead character
such as the ~ or a reserved extension such as .tmp.
It could be a file attribute bit. Because they refuse, there is no 
fool-proof way to scan a disk for orphaned temporary files and delete them. 
Further, you can't tell where the orhaned files ame from. 
This means the hard disks gradually fill up with garbage.

[toc] | [prev] | [next] | [standalone]

#15859

On 7/6/2012 9:10 PM, Roedy Green wrote:
> On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>> But yew troi tellin' the kids nawadays ..."
>
> Univac made a unit record handling computer with 16K.  Yet we had
> threads in the thing and look-ahead i/o.  Someday people won't believe
> this.  A beast like this ran the Vancouver Stock exchange.
>

give it a few years and GB will likely seem small...

like, "how could you write that application using under 1GB of RAM?".

[toc] | [prev] | [next] | [standalone]

#15860

On 7/7/2012 10:42 AM, BGB wrote:
> On 7/6/2012 9:10 PM, Roedy Green wrote:
>> On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
>> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>>> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>>> But yew troi tellin' the kids nawadays ..."
>>
>> Univac made a unit record handling computer with 16K.  Yet we had
>> threads in the thing and look-ahead i/o.  Someday people won't believe
>> this.  A beast like this ran the Vancouver Stock exchange.
>>
>
> give it a few years and GB will likely seem small...
>
> like, "how could you write that application using under 1GB of RAM?".
>

     640YB ought to be enough for anybody.

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15862 — (OT) Was: Re: Java processors

On 7/6/2012 10:10 PM, Roedy Green wrote:
> On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
> someone who said :
>
>>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>> But yew troi tellin' the kids nawadays ..."
>
> Univac made a unit record handling computer with 16K.  Yet we had
> threads in the thing and look-ahead i/o.  Someday people won't believe
> this.  A beast like this ran the Vancouver Stock exchange.

     The Wikipedia article on the VSE makes interesting reading.  This
bit I found somewhat eyebrow-raising:

	The history of the exchange's index provides a standard case
	example of large errors arising from seemingly innocuous
	floating point calculations. [...] The accumulated truncations
	led to an erroneous loss of around 25 points per month."

Not enough RAM to retain the "unimportant" digits?

-- 
Eric Sosman
esosman@ieee-dot-org.invalid

[toc] | [prev] | [next] | [standalone]

#15867 — Re: (OT) Was: Re: Java processors

On Sat, 07 Jul 2012 11:38:13 -0400, Eric Sosman
<esosman@ieee-dot-org.invalid> wrote:

>On 7/6/2012 10:10 PM, Roedy Green wrote:
>> On Fri, 06 Jul 2012 18:17:49 -0400, Eric Sosman
>> <esosman@ieee-dot-org.invalid> wrote, quoted or indirectly quoted
>> someone who said :
>>
>>>      "MEGAbytes? Looxurry.  Moi 'ole college campus 'ad a grand
>>> total of 128 KILObytes,[*] an' we wuz glad to 'ave it, we wuz.
>>> But yew troi tellin' the kids nawadays ..."
>>
>> Univac made a unit record handling computer with 16K.  Yet we had
>> threads in the thing and look-ahead i/o.  Someday people won't believe
>> this.  A beast like this ran the Vancouver Stock exchange.
>
>     The Wikipedia article on the VSE makes interesting reading.  This
>bit I found somewhat eyebrow-raising:
>
>	The history of the exchange's index provides a standard case
>	example of large errors arising from seemingly innocuous
>	floating point calculations. [...] The accumulated truncations
>	led to an erroneous loss of around 25 points per month."
>
>Not enough RAM to retain the "unimportant" digits?

     Probably not.  I would blame the use of FP.

Sincerely,

Gene Wirchenko

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.lang.java.programmer

csiph-web