Re: [fonc] History of computing talks at SJSU

2011-12-21 Thread David Goehrig 
On Dec 20, 2011, at 4:54 AM, Eugen Leitl  wrote:

> I think the reason we've made so little progress is precisely because
> we're computationally bound. Many solutions are suddenly viable if
> everybody has access to nine orders of magnitude more storage and 
> more performance.

This is painfully true in my experience.  My day job involves the machine 
learning / image and speech recognition space. We have thousands of cores, and 
we process petabytes of data a month.  We need another order of magnitude of 
processing power to get to the point where we could see the sort of accuracy 
necessary to make it generally useful.  This is not to say it isn't useful in 
special cases right now, but the limiting problem is having enough parallelism. 
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread Jecel Assumpcao Jr. 
Eugen Leitl wrote on Sat, 17 Dec 2011 10:43:09 +0100

> [300 EUR GPU]
> [InfiniBand features]

Thanks for the tip about InfiniBand. I kept track of it while it was
being developed but had wrongly assumed it had mostly died off when PCI
Express started to become popular. It is actually a lot faster than my
design in terms of bandwidth, though I think my latency is better (it
has hard to compare since the architectures have some important
differences).

What I am doing it patching the Squeak VM so that the send bytecodes
work the normal way when the receiver is in the same core as the sender
but they become a "send message over the network" instruction if the
receiver is remote.

The Wikipedia article mentions an article about using a different
topology (flattened butterfly) for a network using Infiniband in order
to reduce the power consumed by the network. I was able to find the
paper - "Energy proportional datacenter networks" by rs:Dennis Abts,
Michael R. Marty, Philip M. Wells, Peter Klausler and Hong Liu.

http://dl.acm.org/citation.cfm?id=1816004
> http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/pt-BR//pubs/archive/36462.pdf

While looking for this, I saw that this conference's keynote was Chuck
Thacker's Turing Award talk:

> http://isca2010.inria.fr/media/slides/Turing-Improving_the_future_by_examining_the_past.pdf

And this brings us right back to the start of this thread since he is
saying the same thing that Alan Kay said at SJSU.

-- Jecel


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread Steve Dekorte 

karl ramberg wrote:
> Your use case is rather similar to what Engelbart had in his demo 40 years 
> ago (his shopping list)
> And he made that possible on a super computer of his age.
> I don't think that computer was idle most of the time during that demo.

Sure but now developer machines are idle, which is why I'm suggesting the 
bottleneck for development (and therefore economic utility via a longer 
argument) is currently not computation. 



___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread karl ramberg 
On Tue, Dec 20, 2011 at 10:12 PM, Steve Dekorte  wrote:

>
> On 2011-12-20 Tue, at 11:55 AM, Eugen Leitl wrote:
> > On Tue, Dec 20, 2011 at 10:50:36AM -0800, Steve Dekorte wrote:
> >> Could you describe how more compute power helps you write the app I
> described faster?
> >
> > It is a really narrow problem space I'm not familiar with. I presume
> > this isn't about scheduling, but about UI and usability?
>
> Well, take a look at the software that touches the lives of a typical
> person on a typical day (since we are looking at the utility that computers
> provide) and ask if a 1000x faster machine would help write that software
> faster when compared to sw tools such as gc, frameworks, etc. AFAICS, it
> would not.
>
> In as much as faster machines make better tools more practical, I'd agree
> they are helpful for this. But most developers are already sitting in front
> of idle machines. Just what is it they are spending their time doing and
> what can we do to help them are the questions I feel we should be, but
> aren't really asking.
>
>
A use case you describe does not need the computing power of tomorrow.
Your use case is rather similar to what Engelbart had in his demo 40 years
ago (his shopping list)
And he made that possible on a super computer of his age.
I don't think that computer was idle most of the time during that demo.

What will a use case of 40 years in the future look like ?
I hope I don't book meetings in a Excel form then ;-)

Karl
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread Steve Dekorte 

On 2011-12-20 Tue, at 11:55 AM, Eugen Leitl wrote:
> On Tue, Dec 20, 2011 at 10:50:36AM -0800, Steve Dekorte wrote:
>> Could you describe how more compute power helps you write the app I 
>> described faster? 
> 
> It is a really narrow problem space I'm not familiar with. I presume
> this isn't about scheduling, but about UI and usability?

Well, take a look at the software that touches the lives of a typical person on 
a typical day (since we are looking at the utility that computers provide) and 
ask if a 1000x faster machine would help write that software faster when 
compared to sw tools such as gc, frameworks, etc. AFAICS, it would not. 

In as much as faster machines make better tools more practical, I'd agree they 
are helpful for this. But most developers are already sitting in front of idle 
machines. Just what is it they are spending their time doing and what can we do 
to help them are the questions I feel we should be, but aren't really asking.
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread Eugen Leitl 
On Tue, Dec 20, 2011 at 10:50:36AM -0800, Steve Dekorte wrote:

> Could you describe how more compute power helps you write the app I described 
> faster? 

It is a really narrow problem space I'm not familiar with. I presume
this isn't about scheduling, but about UI and usability?

Anything people-centric will become the bottleneck, so apart from
automatic program generation you can only use systems observe users
in action (machine vision) and find something that maximizes
some observable metric. Of course extracting metrics from behaving
people is a hard problem on its own right, but it if solved it
*will* make things happen faster, and it will have considerable
applicability elsewhere.

But this is really a pathological case. Most problems are computationally
bound, especially if you consider problem specification and implementation.
People just want solutions, and an interactive way to refine the problem until
a good enough solution emerges would work for them.

I would also like machines to become persons. It's not everything always
about us primates.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread Steve Dekorte 

karl ramberg wrote:
> Steve Dekorte wrote:
> 
> > Suppose you want to write an app to help people organize events.
> > Neither the development or running the app is compute bound
> > and a machine 1000x faster in itself likely wouldn't much with either.
...
> 
> 
> I think the reason we've made so little progress is precisely because
> we're computationally bound. Many solutions are suddenly viable if
> everybody has access to nine orders of magnitude more storage and
> more performance.

Could you describe how more compute power helps you write the app I described 
faster? 

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread karl ramberg 
On Tue, Dec 20, 2011 at 10:54 AM, Eugen Leitl  wrote:

> On Mon, Dec 19, 2011 at 01:02:28PM -0800, Steve Dekorte wrote:
>
> > Suppose you want to write an app to help people organize events.
> > Neither the development or running the app is compute bound
> > and a machine 1000x faster in itself likely wouldn't much with either.
>
> Suppose I need to simulate 10^12 neurons with a full compartmental
> model in realtime. Or render photorealistic 4K video for an
> interactive virtual world. Or optimize a vehicle for atmospheric
> reentry. Simulate climate. Fold proteins. Map a barren parameter
> space for barren areas. Optimize circuit layout on silicon.
> Analyze a NEMS device in a hybrid model, with some 10 atoms given
> full QM treatment.
>
A lot of simulation and analysis will benefit greatly from more computing
power.
Quite a bit of writing programs/games now are possible because people have
spent weeks
optimizing. And building lots of boundaries around edge cases so you don't
see that the
game is built by low polygons and texture maps. A more naive approach to
computing will
be possible, as we see in Wolfram Alpha. Let the computer do the hard work
and just make what I want possible. Programming based on searching,
analyzing and transforming data.

Karl

>
> > However, using a garbage collected OO language would. So in as
> > much as faster machines lower the cost of higher abstractions, they
> > are helpful for programming. But we are already at the point where
> > most of our time programming is sitting in front of an idle machine
> > trying to tell it what to do.
>
> Massively parallel systems would eliminate the coding and letting
> you specify the boundary conditions. Or evaluate system behaviour
> for better solutions.
>
> > I can't make a hard case for it, but I'd suggest that most of the
> > utility we've gained from computers has been from communication
> > and organization for more efficient resource allocation, that
> > the development of tools for these areas is the largest bottleneck
> > to maximizing the utility of computers and that this is generally
> > not a compute bound problem.
>
> I think the reason we've made so little progress is precisely because
> we're computationally bound. Many solutions are suddenly viable if
> everybody has access to nine orders of magnitude more storage and
> more performance.
>
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread John Zabroski 
I am curious whether Kathryn McKinley's Power Wall argument is measuring a 
first order or second order effect. (This argument is essentially a furthering 
of Google's cost per killowatt hour utility company perspective, which says 
that as a process becomes more parallel it becomes more power hungry.)

It was only 2002 when a paper was published about the significant benefits of 
using control theory to scale up the DTM package on a chip; previous methods 
used peak power as an approximation for controlling thermal dissipation. These 
heuristics also throttled EVERYHING down, not just say instruction prefetching. 
I guess what I am trying to say is, from an outsider's perspective, the trade 
off might simply be based on current engineering practice rather than long term 
trend.

The other thing to note is that while compiler optimizations do play a role in 
power vs speed tradeoffs, higher level languages capable of describing 
transformations to themselves will play a bigger role.

Sent from my Droid Charge on Verizon 4GLTE

--Original Message--
From: David Corking 
To: "Fundamentals of New Computing" 
Date: Tuesday, December 20, 2011 9:28:05 AM GMT+
Subject: Re: [fonc] History of computing talks at SJSU

John Zabroski wrote:

> We have also yet to put into practice languages which limit the client
> run-time of an algorithm on a server (assuming the client can
> parameterize over the server's service in some disciplined way).
>
> Solving this problem will eliminate virtually all IT jobs.

Thanks for being provocative. In my turn, I think everything but your
last sentence is correct.

Google engineers have said that a key design parameter for their
services is the cost of instructions in kilowatt-hours. So the problem
may be less about idle cycles than about wasted cycles such as context
switches, inefficient algorithms and compiler optimization.

Meanwhile, I suspect servers for interactive services are rarely more
than 90% idle.

So I would suggest that efficient scheduling and request run-time
limits are important economic and environmental problems to solve, but
the solutions are unlikely to eliminate many digital tech jobs, as it
is unlikely to benefit society by more than the equivalent of two
Moore's law doubling cycles. That is a huge prize, but not the end of
the world as we know it.

My 2 farthings.
David

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread John Zabroski 
I am curious whether Kathryn McKinley's Power Wall argument is measuring a 
first order or second order effect. (This argument is essentially a furthering 
of Google's cost per killowatt hour utility company perspective, which says 
that as a process becomes more parallel it becomes more power hungry.)

It was only 2002 when a paper was published about the significant benefits of 
using control theory to scale up the DTM package on a chip; previous methods 
used peak power as an approximation for controlling thermal dissipation. These 
heuristics also throttled EVERYHING down, not just say instruction prefetching. 
I guess what I am trying to say is, from an outsider's perspective, the trade 
off might simply be based on current engineering practice rather than long term 
trend.

The other thing to note is that while compiler optimizations do play a role in 
power vs speed tradeoffs, higher level languages capable of describing 
transformations to themselves will play a bigger role.

Sent from my Droid Charge on Verizon 4GLTE

--Original Message--
From: David Corking 
To: "Fundamentals of New Computing" 
Date: Tuesday, December 20, 2011 9:28:05 AM GMT+
Subject: Re: [fonc] History of computing talks at SJSU

John Zabroski wrote:

> We have also yet to put into practice languages which limit the client
> run-time of an algorithm on a server (assuming the client can
> parameterize over the server's service in some disciplined way).
>
> Solving this problem will eliminate virtually all IT jobs.

Thanks for being provocative. In my turn, I think everything but your
last sentence is correct.

Google engineers have said that a key design parameter for their
services is the cost of instructions in kilowatt-hours. So the problem
may be less about idle cycles than about wasted cycles such as context
switches, inefficient algorithms and compiler optimization.

Meanwhile, I suspect servers for interactive services are rarely more
than 90% idle.

So I would suggest that efficient scheduling and request run-time
limits are important economic and environmental problems to solve, but
the solutions are unlikely to eliminate many digital tech jobs, as it
is unlikely to benefit society by more than the equivalent of two
Moore's law doubling cycles. That is a huge prize, but not the end of
the world as we know it.

My 2 farthings.
David

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread Eugen Leitl 
On Tue, Dec 20, 2011 at 09:28:05AM +, David Corking wrote:

> Google engineers have said that a key design parameter for their
> services is the cost of instructions in kilowatt-hours. So the problem

The costs of energy have been dominating the data centers for
many years now. This is the reason for introducing higher
temperatures, water cooling, ambient cooling, more energy-efficient
nodes (ARM, Blue Gene) and so on. This will eventually lead to
fully static designs, most likely spintronics which only burn
power when switching. It's obviously the only way to achieve
3d integration, along with reversible computing.

> may be less about idle cycles than about wasted cycles such as context
> switches, inefficient algorithms and compiler optimization.
> 
> Meanwhile, I suspect servers for interactive services are rarely more
> than 90% idle.

Clusters are computers, too. These are almost never idle, and
don't context-switch (typically dedicated to scheduled batches).
 
> So I would suggest that efficient scheduling and request run-time

There's a tentative trend for allocating invididual dedicated nodes
to particular tasks (instead, of, say threads), such as a sea of ARM 
cores on a mesh fabric. This seems to match cloud workloads quite 
well as well. The next years should be rather interesting.

> limits are important economic and environmental problems to solve, but
> the solutions are unlikely to eliminate many digital tech jobs, as it

The first jobs to go are that of server monkeys. Lights out data
centers do exist, and many developers are already using comfortably
abstracted hardware instantiated, scaled and destroyed by APIs.
This is dangerous, but also convenient. 

> is unlikely to benefit society by more than the equivalent of two
> Moore's law doubling cycles. That is a huge prize, but not the end of

Intel is down to 14 nm. Not many more where these came from.

> the world as we know it.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread Eugen Leitl 
On Mon, Dec 19, 2011 at 01:02:28PM -0800, Steve Dekorte wrote:

> Suppose you want to write an app to help people organize events. 
> Neither the development or running the app is compute bound 
> and a machine 1000x faster in itself likely wouldn't much with either.

Suppose I need to simulate 10^12 neurons with a full compartmental
model in realtime. Or render photorealistic 4K video for an 
interactive virtual world. Or optimize a vehicle for atmospheric 
reentry. Simulate climate. Fold proteins. Map a barren parameter 
space for barren areas. Optimize circuit layout on silicon. 
Analyze a NEMS device in a hybrid model, with some 10 atoms given 
full QM treatment.
 
> However, using a garbage collected OO language would. So in as 
> much as faster machines lower the cost of higher abstractions, they
> are helpful for programming. But we are already at the point where
> most of our time programming is sitting in front of an idle machine
> trying to tell it what to do. 

Massively parallel systems would eliminate the coding and letting
you specify the boundary conditions. Or evaluate system behaviour
for better solutions.
 
> I can't make a hard case for it, but I'd suggest that most of the
> utility we've gained from computers has been from communication 
> and organization for more efficient resource allocation, that
> the development of tools for these areas is the largest bottleneck
> to maximizing the utility of computers and that this is generally 
> not a compute bound problem.

I think the reason we've made so little progress is precisely because
we're computationally bound. Many solutions are suddenly viable if
everybody has access to nine orders of magnitude more storage and 
more performance.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread David Corking 
John Zabroski wrote:

> We have also yet to put into practice languages which limit the client
> run-time of an algorithm on a server (assuming the client can
> parameterize over the server's service in some disciplined way).
>
> Solving this problem will eliminate virtually all IT jobs.

Thanks for being provocative. In my turn, I think everything but your
last sentence is correct.

Google engineers have said that a key design parameter for their
services is the cost of instructions in kilowatt-hours. So the problem
may be less about idle cycles than about wasted cycles such as context
switches, inefficient algorithms and compiler optimization.

Meanwhile, I suspect servers for interactive services are rarely more
than 90% idle.

So I would suggest that efficient scheduling and request run-time
limits are important economic and environmental problems to solve, but
the solutions are unlikely to eliminate many digital tech jobs, as it
is unlikely to benefit society by more than the equivalent of two
Moore's law doubling cycles. That is a huge prize, but not the end of
the world as we know it.

My 2 farthings.
David

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-20 Thread Steve Dekorte 

On 2011-12-19 Mon, at 09:15 PM, John Zabroski wrote:
>> I can't make a hard case for it, but I'd suggest that most of the
>> utility we've gained from computers has been from communication
>> and organization for more efficient resource allocation, that
>> the development of tools for these areas is the largest bottleneck
>> to maximizing the utility of computers and that this is generally
>> not a compute bound problem.
> 
> Everything except the last bit is correct, IMHO.
> 
> Virtual machines, today, by and large, lack support for first-class
> scheduling of resources.  Reasoning about resources is all about
> compute bound problems, like how much resources a client is allowed to
> reserve per server request.
> 
> We have also yet to put into practice languages which limit the client
> run-time of an algorithm on a server (assuming the client can
> parameterize over the server's service in some disciplined way).
> 
> Solving this problem will eliminate virtually all IT jobs.

Sorry, I should have been more clear - I meant the allocation 
of resources in the general economic sense (labor, materials, etc).



___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-19 Thread John Zabroski 
On Mon, Dec 19, 2011 at 4:02 PM, Steve Dekorte  wrote:
>
> On 2011-12-17 Sat, at 01:17 AM, Eugen Leitl wrote:
>> On Fri, Dec 16, 2011 at 02:16:41PM -0800, Steve Dekorte wrote:
>>> Is speed really the bottleneck for making computers more useful?
>>
>> Many major scientific problems or even gaming are resource-constrained.
>> I personally would have no difficulties keeping astronomical numbers
>> of nodes at 100% CPU for years and decades.
>
>> Consider what a BlueGene/Q on every desktop would mean.
>
>
> Suppose you want to write an app to help people organize events.
> Neither the development or running the app is compute bound
> and a machine 1000x faster in itself likely wouldn't much with either.
>
> However, using a garbage collected OO language would. So in as
> much as faster machines lower the cost of higher abstractions, they
> are helpful for programming. But we are already at the point where
> most of our time programming is sitting in front of an idle machine
> trying to tell it what to do.
>
> I can't make a hard case for it, but I'd suggest that most of the
> utility we've gained from computers has been from communication
> and organization for more efficient resource allocation, that
> the development of tools for these areas is the largest bottleneck
> to maximizing the utility of computers and that this is generally
> not a compute bound problem.

Everything except the last bit is correct, IMHO.

Virtual machines, today, by and large, lack support for first-class
scheduling of resources.  Reasoning about resources is all about
compute bound problems, like how much resources a client is allowed to
reserve per server request.

We have also yet to put into practice languages which limit the client
run-time of an algorithm on a server (assuming the client can
parameterize over the server's service in some disciplined way).

Solving this problem will eliminate virtually all IT jobs.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-19 Thread Steve Dekorte 

On 2011-12-17 Sat, at 01:17 AM, Eugen Leitl wrote:
> On Fri, Dec 16, 2011 at 02:16:41PM -0800, Steve Dekorte wrote:
>> Is speed really the bottleneck for making computers more useful?
> 
> Many major scientific problems or even gaming are resource-constrained.
> I personally would have no difficulties keeping astronomical numbers
> of nodes at 100% CPU for years and decades.

> Consider what a BlueGene/Q on every desktop would mean.


Suppose you want to write an app to help people organize events. 
Neither the development or running the app is compute bound 
and a machine 1000x faster in itself likely wouldn't much with either.

However, using a garbage collected OO language would. So in as 
much as faster machines lower the cost of higher abstractions, they
are helpful for programming. But we are already at the point where
most of our time programming is sitting in front of an idle machine
trying to tell it what to do. 

I can't make a hard case for it, but I'd suggest that most of the
utility we've gained from computers has been from communication 
and organization for more efficient resource allocation, that
the development of tools for these areas is the largest bottleneck
to maximizing the utility of computers and that this is generally 
not a compute bound problem.


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-17 Thread Alan Kay 
This idea was tried by the Engelbartians with chord keyboards integrated with 
the mouse mechanism. In their design, there wasn't enough stability to do 
positioning well (although one could imagine other technologies that would do 
both good pointing with both hands and allow all fingers to be used).

Cheers,

Alan




>
> From: Casey Ransberger 
>To: Alan Kay ; Fundamentals of New Computing 
> 
>Sent: Friday, December 16, 2011 9:07 PM
>Subject: Re: [fonc] History of computing talks at SJSU
> 
>Below. 
>
>On Dec 16, 2011, at 3:19 PM, Alan Kay  wrote:
>
>> And what Engelbart was upset about was that the "hands out -- hands 
>> together" style did not survive. The "hands out" had one hand with the 5 
>> finger keyboard and the other with the mouse and 3 buttons -- this allowed 
>> navigation and all commands and typing to be done really efficiently 
>> compared to today. "Hands together" on the regular keyboard only happened 
>> when you had bulk typing to do.
>
>Are you talking about the so-called "chording keyboard?"
>
>I had an idea years ago to have a pair of "twiddlers" (the one chording 
>keyboard I'd seen was called a twiddler) which tracked movement of both hands 
>over the desktop, basically giving you two pointing devices and a keyboarding 
>solution at the same time. 
>
>Now it's all trackpads and touch screens, and my idea seems almost Victorian:)
>
>___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-17 Thread Eugen Leitl 
On Sat, Dec 17, 2011 at 12:04:48AM -0300, Jecel Assumpcao Jr. wrote:
> Eugen Leitl wrote:
> 
> > [human limits - growing code]
> 
> Perhaps the copycat work Doug Hofstadter, did is a step in this
> direction?
> 
> http://en.wikipedia.org/wiki/Copycat_%28software%29

Thanks for the pointer, I haven't heard of that.
It would be interesting to see how Koza's GP would
work on realtime selection of very large agent
populations.
 
> > FPGAs suffer the problem of lack of embedded memory. Consider
> > GPGPU with quarter of TByte/s bandwidth across 2-3 GByte grains.
> > You just can't compete with economies of scale which allows you
> > hundreds to thousands of meshing such with InfiniBand.
> 
> You can have the same external memories with an FPGA as with a GPU. I
> don't think that is an important difference between them.

The commodity/off the shelf (COTS) aspect is important, though. 
E.g. a common graphics card buys you for 300 EUR some

Up to 880MHz Engine Clock
2GB GDDR5 Memory
1375MHz Memory Clock (5.5 Gbps GDDR5)
176 GB/s memory bandwidth (maximum)
2.7 TFLOPs Single Precision compute power
683 GFLOPs Double Precision compute power
TeraScale 3 Unified Processing Architecture

1536 Stream Processors
96 Texture Units
128 Z/Stencil ROP Units
32 Color ROP Units
Dual geometry and dual rendering engines

High Speed 256-bit GDDR5 memory interface
PCI Express 2.1 x16 bus interface 

There's no problem putting 2-4 of these in a
single computer, shelve hundreds to thousands
of these and link them up with low-budget
InfiniBand. The bang for the buck is really hard
to beat with custom architectures.
 
> > [large clusters with COTS]
> 
> Ok, but the networks used in clusters are a bit slow for the experiments
> I want to do.

Interesting. End to end latency in InfiniBand is almost exactly
a microsecond, 10-40 GBit/s thoughput allows you mesh topologies 
and all kind of funky message types. You're obviously working
directly at FPGA level and need ns latency. What kind of work do you do?

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-17 Thread Eugen Leitl 
On Fri, Dec 16, 2011 at 02:16:41PM -0800, Steve Dekorte wrote:

> Is speed really the bottleneck for making computers more useful?

Many major scientific problems or even gaming are resource-constrained.
I personally would have no difficulties keeping astronomical numbers
of nodes at 100% CPU for years and decades.

Consider what a BlueGene/Q on every desktop would mean. Even if
Moore continues to hold, it will be a great long while until
it happens.
 
> Personally, I don't find myself waiting on my computer much anymore. 
> Most of my time is instead spent trying to tell the machine what to do 
> while it sits there, idling.

All the big clusters are booked out. It's the main reason why people
are building their own clusters. A bird in the hand is worth two in the bush.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-17 Thread Casey Ransberger 
That's really funny:)

On Dec 16, 2011, at 7:13 PM, John Zabroski  wrote:

> On Fri, Dec 16, 2011 at 10:10 PM, John Zabroski  
> wrote:
>> On Fri, Dec 16, 2011 at 10:04 PM, Jecel Assumpcao Jr.
>>  wrote:
>>> Steve Dekorte wrote:
>>> 
 [NeXTStation memories versus reality]
>>> 
>>> I still have a running Apple II. My slowest working PC is a 33MHz 486,
>>> so I can't directly do the comparison I mentioned. But I agree we
>>> shouldn't trust what we remember things feeling like.
>>> 
>>> -- Jecel
>> 
>> 
>> The Apple booting up faster was not simply a feeling, but a fact owing
>> to its human-computer interaction demands.  They set fast boot speeds
>> as a design criteria.  Jef Raskin talks about this in the book The
>> Humane Interface.  Even modern attempts to reduce boot speed have not
>> been that good, such as "upstart", an event-driven alternative to
>> "init".
>> 
>> Eugen has some very good points about human limits of managing
>> performance details, though.  Modern approaches to performance are
>> already moving away from such crude methods.
> 
> By the way, slight tangent: Modern operating systems, with all their
> hot-swapping requirements, do a poor job distinguishing device error
> from continuously plugging-in and plugging-out the device. For
> example, if you have an optical mouse and damage it, it might slowly
> die and your entire system will hang because 99% of your CPU will be
> handling plugin and plugout events.
> 
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-17 Thread Casey Ransberger 
Whereas my Squeak environment comes up in a second. No, it isn't an "OS," or 
not anymore anyway. But it pops right where I left it. The system that supports 
it is lucky to boot in a minute... and I can't easily prove it, but...

I have this *feeling* that my OS is doing a lot durring boot to set up things I 
never use in a suboptimal way. And it doesn't even come up exactly where I left 
it. It *tries* by reopening various things and *sometimes* it works well enough 
that I don't notice that something is broken. 

Usually, though, I'm sitting there wondering why I have to spend minutes of my 
day waiting for the tool that I need to do my job to become available. This 
sucks. Rebooting at all is a PITA. That it takes minutes, I think, is just lack 
of forethought or designing for the wrong use case. 



On Dec 16, 2011, at 7:10 PM, John Zabroski  wrote:

> On Fri, Dec 16, 2011 at 10:04 PM, Jecel Assumpcao Jr.
>  wrote:
>> Steve Dekorte wrote:
>> 
>>> [NeXTStation memories versus reality]
>> 
>> I still have a running Apple II. My slowest working PC is a 33MHz 486,
>> so I can't directly do the comparison I mentioned. But I agree we
>> shouldn't trust what we remember things feeling like.
>> 
>> -- Jecel
> 
> 
> The Apple booting up faster was not simply a feeling, but a fact owing
> to its human-computer interaction demands.  They set fast boot speeds
> as a design criteria.  Jef Raskin talks about this in the book The
> Humane Interface.  Even modern attempts to reduce boot speed have not
> been that good, such as "upstart", an event-driven alternative to
> "init".
> 
> Eugen has some very good points about human limits of managing
> performance details, though.  Modern approaches to performance are
> already moving away from such crude methods.
> 
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-17 Thread Casey Ransberger 
Below. 

On Dec 16, 2011, at 9:03 PM, Wesley Smith  wrote:

>> Some things are just expensive. No one has found an acceptable solution. 
>> These are things we should avoid in the infrastructure underneath a personal 
>> computing experience:)
> 
> 
> Or figure out how to amortize them over time.  I think recent
> raytracing apps are a good example of this.  You can preview the image
> as it is rendered to see if it's just right and if not, tweak it.
> Another example is scraping data to build a database that will inform
> autocompletion and other productivity enhancing UI effects.  Sometimes
> gather and parsing out the data to put in the database can be
> expensive, but it can easily be done in a background thread without
> any cost to responsiveness.  I'm sure there are plenty of other
> examples.
> 
> wes

Totally. Look for new ways to make expensive things cheap. Look for ways to 
turn NP-complete linear! And never ever stop trying. 

Just don't put factorial complexity in my email client if you can avoid it:);):P

> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Casey Ransberger 
Below. 

On Dec 16, 2011, at 3:19 PM, Alan Kay  wrote:

> And what Engelbart was upset about was that the "hands out -- hands together" 
> style did not survive. The "hands out" had one hand with the 5 finger 
> keyboard and the other with the mouse and 3 buttons -- this allowed 
> navigation and all commands and typing to be done really efficiently compared 
> to today. "Hands together" on the regular keyboard only happened when you had 
> bulk typing to do.

Are you talking about the so-called "chording keyboard?"

I had an idea years ago to have a pair of "twiddlers" (the one chording 
keyboard I'd seen was called a twiddler) which tracked movement of both hands 
over the desktop, basically giving you two pointing devices and a keyboarding 
solution at the same time. 

Now it's all trackpads and touch screens, and my idea seems almost Victorian:)
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Wesley Smith 
> Some things are just expensive. No one has found an acceptable solution. 
> These are things we should avoid in the infrastructure underneath a personal 
> computing experience:)


Or figure out how to amortize them over time.  I think recent
raytracing apps are a good example of this.  You can preview the image
as it is rendered to see if it's just right and if not, tweak it.
Another example is scraping data to build a database that will inform
autocompletion and other productivity enhancing UI effects.  Sometimes
gather and parsing out the data to put in the database can be
expensive, but it can easily be done in a background thread without
any cost to responsiveness.  I'm sure there are plenty of other
examples.

wes

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Casey Ransberger 
Below. Abridged. 

On Dec 16, 2011, at 1:42 PM, Steve Dekorte  wrote:

> 
> FWIW, in my memory, my old NeXTstation felt as snappy as modern desktops but 
> when I ran across one at the Computer History Museum it felt painfully slow. 
> I've had similar experiences with seeing old video games and finding the 
> quality of the graphics to be much lower than I remembered.
> 
> This is just a guess, but I suspect what we remember is strongly influenced 
> by our emotional reactions which in turn are shaped by our expectations. At 
> the time, my expectations were lower.

This is an excellent point. 

At work I'm using a 32-bit single core machine that's 0.6ghz slower than my 
personal 64-bit dual core machine. 

Once in awhile, I notice that it's slower. I have a feeling, though, that this 
is a consequence of slower hardware *compounded* by expensive software, because 
most of the time, I can't tell the difference at all.

What I'm saying is in part that the computational power of modern computers 
typically eclipses my personal need for computing power. When things are 
suddenly slow, I suspect algorithm/datastructure. 

Whereas: it used to be that everything seemed to take a long time. 

Some things are just expensive. No one has found an acceptable solution. These 
are things we should avoid in the infrastructure underneath a personal 
computing experience:)
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread John Zabroski 
On Fri, Dec 16, 2011 at 10:10 PM, John Zabroski  wrote:
> On Fri, Dec 16, 2011 at 10:04 PM, Jecel Assumpcao Jr.
>  wrote:
>> Steve Dekorte wrote:
>>
>>> [NeXTStation memories versus reality]
>>
>> I still have a running Apple II. My slowest working PC is a 33MHz 486,
>> so I can't directly do the comparison I mentioned. But I agree we
>> shouldn't trust what we remember things feeling like.
>>
>> -- Jecel
>
>
> The Apple booting up faster was not simply a feeling, but a fact owing
> to its human-computer interaction demands.  They set fast boot speeds
> as a design criteria.  Jef Raskin talks about this in the book The
> Humane Interface.  Even modern attempts to reduce boot speed have not
> been that good, such as "upstart", an event-driven alternative to
> "init".
>
> Eugen has some very good points about human limits of managing
> performance details, though.  Modern approaches to performance are
> already moving away from such crude methods.

By the way, slight tangent: Modern operating systems, with all their
hot-swapping requirements, do a poor job distinguishing device error
from continuously plugging-in and plugging-out the device. For
example, if you have an optical mouse and damage it, it might slowly
die and your entire system will hang because 99% of your CPU will be
handling plugin and plugout events.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread John Zabroski 
On Fri, Dec 16, 2011 at 10:04 PM, Jecel Assumpcao Jr.
 wrote:
> Steve Dekorte wrote:
>
>> [NeXTStation memories versus reality]
>
> I still have a running Apple II. My slowest working PC is a 33MHz 486,
> so I can't directly do the comparison I mentioned. But I agree we
> shouldn't trust what we remember things feeling like.
>
> -- Jecel


The Apple booting up faster was not simply a feeling, but a fact owing
to its human-computer interaction demands.  They set fast boot speeds
as a design criteria.  Jef Raskin talks about this in the book The
Humane Interface.  Even modern attempts to reduce boot speed have not
been that good, such as "upstart", an event-driven alternative to
"init".

Eugen has some very good points about human limits of managing
performance details, though.  Modern approaches to performance are
already moving away from such crude methods.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Jecel Assumpcao Jr. 
Eugen Leitl wrote:

> [human limits - growing code]

Perhaps the copycat work Doug Hofstadter, did is a step in this
direction?

http://en.wikipedia.org/wiki/Copycat_%28software%29

> [OpenMP doesn't match reality]

I agree 100%. But it didn't mess up the logic as much as MPI does. This
was a class, so every learning experience is interesting.

> FPGAs suffer the problem of lack of embedded memory. Consider
> GPGPU with quarter of TByte/s bandwidth across 2-3 GByte grains.
> You just can't compete with economies of scale which allows you
> hundreds to thousands of meshing such with InfiniBand.

You can have the same external memories with an FPGA as with a GPU. I
don't think that is an important difference between them.

> [large clusters with COTS]

Ok, but the networks used in clusters are a bit slow for the experiments
I want to do.

Steve Dekorte wrote:

> [NeXTStation memories versus reality]

I still have a running Apple II. My slowest working PC is a 33MHz 486,
so I can't directly do the comparison I mentioned. But I agree we
shouldn't trust what we remember things feeling like.

-- Jecel


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Jecel Assumpcao Jr. 
John Zabroski wrote:

> You said that our field had become so impoverished because nobody
> googles Douglas Englebart and watches The Mother of All Demoes, and
> also noted that evolution finds "fits" rather than optimal solutions.
> But you didn't really provide any examples of how we are the victims
> of evolution finding these fits. 

Alan mentioned the Burroughs B5000 compared with the architectures that
survived. In Donald Knuth's talk the same design was mentioned as an
example of a mistake we got rid of (a guy who still only programs in
assembly would say that ;-). So the students got to hear both sides.

> So I think I am providing a valuable
> push back by being my stubborn self and saying, Hey, wait, I know
> that's not true.  It just seemed very incongruent to the question of
> how we see the present: is it solely in terms of the past?

Normally Alan presents seeing the past only in terms of the present as
being the problem because this also limits how you see the future. Take
any modern timeline of the microprocessor, for example. It will indeed
be a line and not a tree. It will start with the 4004, then 8008, 8080,
8086, 286 and so on to the latest Core i7. Interesting parts of the
past, like the 6502, the 29000 and so many others can't be seen because
nothing in the present traces back to them.

-- Jecel


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread John Zabroski 
On Fri, Dec 16, 2011 at 6:19 PM, Alan Kay  wrote:
> I hope I didn't say "there was absolutely nothing worth talking about in the
> 'personal computing' space in the past 30 years" (and don't think I did say
> that).
>
> "Let us all share in the excitement of Discovery without vain attempts to
> claim priority" -- Goethe
>

Certainly.  We can't argue with Goethe.  Yet, I don't think that applies here.

You said that our field had become so impoverished because nobody
googles Douglas Englebart and watches The Mother of All Demoes, and
also noted that evolution finds "fits" rather than optimal solutions.
But you didn't really provide any examples of how we are the victims
of evolution finding these fits.  So I think I am providing a valuable
push back by being my stubborn self and saying, Hey, wait, I know
that's not true.  It just seemed very incongruent to the question of
how we see the present: is it solely in terms of the past?  And "the
real question is what do you want it to do for its end users?"  You
answer this question with your own perspective, but only saying "*WE*
wanted children to learn profound things..."

There is good content in your talk, owing to your immense experience
and knowledge, but it is dispersed like a spray.

If I could summarize one thing to takeaway, it's that the medium is
the message, and the performance of the medium changes how people
think and interact with computers and each other.  But even that
takeaway feels buried in digressions.  The other takeaways I got was:

* a note to self to read E.M. Forster's The Machine Stops.
* "Nobody wants a coordinate system if we don't have to use one, for
goodness sakes."
* We still don't write computer system's that take into account the
user's context
* You mention that you "worked on fonts", but didn't say anything
about the books you read and research you did on displaying fonts

Just 2 cents.

> Dick Shoup at Xerox PARC and later at Interval, conceived and showed
> something very similar.

Tried googling this using various phrases and spellings.  Zero results.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Alan Kay 
I hope I didn't say "there was absolutely nothing worth talking about in the 
'personal computing' space in the past 30 years" (and don't think I did say 
that).

"Let us all share in the excitement of Discovery without vain attempts to claim 
priority" -- Goethe

So some recent manifestations of ideas and technologies such as multitouch, 
mouseless, and SixthSense, should be praised.

However, it is also interesting to discover where ideas came from and who came 
up with them first -- this helps us understand and differentiate "high 
creativity from low context" from "low creativity from high context".

I don't know who did the mouseless idea first, but certainly Dick Shoup at 
Xerox PARC and later at Interval, conceived and showed something very similar. 
One of the central parts of this was to use image recognition to track people, 
hands, and fingers.

Similarly, the SixthSense idea has much in common with Nicholas Negroponte's 
(and many in his Arch-Mac group at MIT) idea in the 70s that we would wear 
things that would let computers know where we are and where we are pointing, 
and that there will be displays everywhere (from a variety of means) and the 
Internet will also be everywhere by then, and there will be embedded computers 
everywhere, etc., so that one's "helper agents" will have the effect of 
following us around and responding to our gestures and commands. There are 
several terrific movies of their prototypes.


Multitouch, similarly is hard to find out who did it first, but again Nicholas' 
Arch-Mach group certainly did do it (Chris Herot as I recall) in the 70s.

And what Engelbart was upset about was that the "hands out -- hands together" 
style did not survive. The "hands out" had one hand with the 5 finger keyboard 
and the other with the mouse and 3 buttons -- this allowed navigation and all 
commands and typing to be done really efficiently compared to today. "Hands 
together" on the regular keyboard only happened when you had bulk typing to do.

It should be clear that being able to sense all the fingers in some way that 
allows "piano keyboard" like fluency/polyphony is still a good idea. Musical 
instruments require some training and practice but then allow many more degrees 
of freedom to be controlled.


And, though Nick Sheriden was the leader of the PARC "electrophoretic 
migration" display project, it was colloidal chemist Ann Chiang who 
accomplished many of the breakthroughs in the 70s. That Xerox didn't follow 
through with this technology was a great disappointment for me. It was really 
nice, and even the prototype had higher contrast ratios than the e-ink displays 
of today (different approach, different kinds of particles).

And a few things have happened since 1980  but the talk was supposed to be 
about the Dynabook idea 

Best wishes,

Alan




>____________
> From: John Zabroski 
>To: Fundamentals of New Computing  
>Sent: Friday, December 16, 2011 1:12 PM
>Subject: Re: [fonc] History of computing talks at SJSU
> 
>I disagree with the tone in Alan's talk here.  While it is great to
>see what was happening in the 50-70s, he makes it sound like there is
>absolutely nothing worth talking about in the "personal computing"
>space in the past 30 years.
>
>Pranav Mistry's work on "sixth sense technology" and the mouseless
>mouse alone raise legitimate counterpoints to much of what is
>suggested by this talk.  For example, Alan touches upon Englebart's
>fury over what happened with the mouse and how the needs of mass
>market commercialization trump utility.  Yet, I see a future where we
>are far less dependent on mechanical tools like the mouse.
>
>But progress takes time.  For example, the first e-ink technologies
>were developed at PARC in the 70s by Nicholas K. Sheridan as a
>prototype for a future Alto computer (not mentioned at all by Alan in
>his talk).  Reducing the cost to manufacture such displays has been a
>long-running process and one I follow intently.  For example, only
>recently has a consortium of researchers gotten together and come up
>with a fairly brilliant idea to use the same techniques found in
>inkjet printing to print pholed screens, making the construction of
>flexible e-paper as cost effective as the invention of inkjet printing
>to the paper medium.
>
>With these newer mediums we will also need greater automation in
>analyzing so-called "big data".  Today most analysis is not automated
>by computers, and so scientists are separated from truly interacting
>with their massive datasets.  They have to talk to project managers,
>who then talk to programmers, who then write code that gets deployed
>to QA, etc.  The human

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Steve Dekorte 

On 2011-12-16 Fri, at 01:38 PM, Eugen Leitl wrote:
>> How can we spend money now to live in the future? Alan mentioned the
>> first way in his talk: put lots and lots of FPGA together. The BEE3
> 
> FPGAs suffer the problem of lack of embedded memory. Consider
> GPGPU with quarter of TByte/s bandwidth across 2-3 GByte grains.
> You just can't compete with economies of scale which allows you
> hundreds to thousands of meshing such with InfiniBand.

Is speed really the bottleneck for making computers more useful?

Personally, I don't find myself waiting on my computer much anymore. 
Most of my time is instead spent trying to tell the machine what to do 
while it sits there, idling.

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Steve Dekorte 

FWIW, in my memory, my old NeXTstation felt as snappy as modern desktops but 
when I ran across one at the Computer History Museum it felt painfully slow. 
I've had similar experiences with seeing old video games and finding the 
quality of the graphics to be much lower than I remembered.

This is just a guess, but I suspect what we remember is strongly influenced by 
our emotional reactions which in turn are shaped by our expectations. At the 
time, my expectations were lower.

On 2011-12-16 Fri, at 11:14 AM, Jecel Assumpcao Jr. wrote:

> Compare running Squeak on a 40MHz 386 PC (my 1992 computer) with running
> the exact same code on a 1GHz Pentium 4 PC (available to me in 2000).
> Not even the old MVC interface is really usable on the first while the
> second machine can handle Morphic just fine. The quantitive difference
> becomes a qualititive one. I didn't feel the same between my 1 MHz Apple
> II and the 6MHz PC AT. But of course there was a diffence - to show of
> the AT in trade shows we used to run a Microsoft flight simulator called
> Jet (later merged with MS Flight Simulator) on that machine side by side
> with a 4.77MHz PC XT. It was a fun game on the AT, but looked more like
> a slide show on the XT. I still felt I could get by with the Apple II,
> however.


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Eugen Leitl 
On Fri, Dec 16, 2011 at 04:14:40PM -0300, Jecel Assumpcao Jr. wrote:
> Eugen Leitl wrote:
> 
> > It's remarkable how few are using MPI in practice. A lot of code 
> > is being made multithread-proof, and for what? So that they'll have
> > to rewrite it for message-passing, again?
> 
> Having seen a couple of applications which used MPI it seems like a dead
> end to me. The code is mangled to the point where it becomes really hard

Yes, you're running into the limitations of the human mind. Despite
being a massively parallel process underneath somewhat paradoxically
the upper layers have big problems with utilizing parallelism.

I actually think that the problem is unsolvable at the human end
(just consider debugging millions to billions of fine-grained
asynchronous shared-nothing processes) and have to be routed around
the human by automatic code generation by stochastical means.
Growing your code a la Darwin might be the only thing that could
scale. Of course, we have to learn evolvability first. Current
stuff is way too brittle.

> to understand what it does (in one case I rewrote it with OpenMP and the

OpenMP assumes shared memory, and shared memory does not exist in
this universe. It has to be expensively emulated. Cache coherency
will be distinctly dead well before we'll get to kilonode country.
We can already rack some quite impressive numbers of ARM-based
SoCs on a mesh without the corium failure mode if cooling
fails briefly.

> difference in clarity was amazing). Fortunately, message passing in
> Smalltalk looks far nicer and doesn't get in the way. So that is what I

I must admit I've never done Smalltalk in anger, though I definitely
loved the concept when I did my history in early 1980s.

> am working on (and yes, I know all about Peter Deutsch's opinion about
> making local and remote messages look the same -
> http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing).

If you remove the cache and use cache-like embedded memory
than accessing remote locations by message passing (routed via
cut-through signalling mesh) is only slightly more expensive than
accessing local embedded memory. Some gate delays and relativistic
latency (think of pingpong across a 300 mm wafer) do apply, of course.
 
> How can we spend money now to live in the future? Alan mentioned the
> first way in his talk: put lots and lots of FPGA together. The BEE3

FPGAs suffer the problem of lack of embedded memory. Consider
GPGPU with quarter of TByte/s bandwidth across 2-3 GByte grains.
You just can't compete with economies of scale which allows you
hundreds to thousands of meshing such with InfiniBand.

> board isn't cheap (something like $5K without the FPGAs, which are a few
> thousand dollars each themselves, nor memory) and a good RAMP machine
> hook a bunch of these together. The advantage of this approach is that
> each FPGA is large enough to do pretty much anything you can imagine. If
> you know your processors will be rather small, it might be more cost
> effective to have a larger number of cheaper FPGAs. That is what I am
> working on.
> 
> A second way to live in the future is far less flexible, and so should
> only be a second step after the above is no longer getting you the
> results you need: use wafer scale integration to have now roughly the
> same number of transistors you will have in 2020 on a typical chip. This
> is pretty hard (just ask Clive Sinclair or Gene Amdahl how much they
> lost on wafer scale integration back in the 1980s). But if you can get
> it to work, then you could distribute hundreds (or more) of 2020's
> computers to today's researchers.

But today's computers as tomorrow's are already large clusters.
The question is one of how many nodes you can afford, and what is
your electricity bill. If you know how your problem maps you'll just
pick the best of COTS of today, and run it for 3-5 years after which
it's cheaper to buy new hardware than to keep paying the electricity
bill.

I'm not sure how well the SmallTalk model would fare here. 


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread John Zabroski 
I disagree with the tone in Alan's talk here.  While it is great to
see what was happening in the 50-70s, he makes it sound like there is
absolutely nothing worth talking about in the "personal computing"
space in the past 30 years.

Pranav Mistry's work on "sixth sense technology" and the mouseless
mouse alone raise legitimate counterpoints to much of what is
suggested by this talk.  For example, Alan touches upon Englebart's
fury over what happened with the mouse and how the needs of mass
market commercialization trump utility.  Yet, I see a future where we
are far less dependent on mechanical tools like the mouse.

But progress takes time.  For example, the first e-ink technologies
were developed at PARC in the 70s by Nicholas K. Sheridan as a
prototype for a future Alto computer (not mentioned at all by Alan in
his talk).  Reducing the cost to manufacture such displays has been a
long-running process and one I follow intently.  For example, only
recently has a consortium of researchers gotten together and come up
with a fairly brilliant idea to use the same techniques found in
inkjet printing to print pholed screens, making the construction of
flexible e-paper as cost effective as the invention of inkjet printing
to the paper medium.

With these newer mediums we will also need greater automation in
analyzing so-called "big data".  Today most analysis is not automated
by computers, and so scientists are separated from truly interacting
with their massive datasets.  They have to talk to project managers,
who then talk to programmers, who then write code that gets deployed
to QA, etc.  The human social process here is fraught with error.

On Tue, Dec 13, 2011 at 3:02 PM, Kim Rose  wrote:
> For those of you looking to hear more from Alan Kay -- you'll find a talk
> from him and several other "big names in computer science" here -- thanks to
> San Jose State University.
>
>  http://www.sjsu.edu/atn/services/webcasting/archives/fall_2011/hist/computing.html
>
>  -- Kim
>
>
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread Jecel Assumpcao Jr. 
Eugen Leitl wrote:

> It's remarkable how few are using MPI in practice. A lot of code 
> is being made multithread-proof, and for what? So that they'll have
> to rewrite it for message-passing, again?

Having seen a couple of applications which used MPI it seems like a dead
end to me. The code is mangled to the point where it becomes really hard
to understand what it does (in one case I rewrote it with OpenMP and the
difference in clarity was amazing). Fortunately, message passing in
Smalltalk looks far nicer and doesn't get in the way. So that is what I
am working on (and yes, I know all about Peter Deutsch's opinion about
making local and remote messages look the same -
http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing).

In other messages in this thread there were comments about software
bloat hiding the effects of Moore's Law. There was a funny quote about
that (I was not able to track down who first said it): "What Andy
giveth, Bill taketh away!" (meaning Andrew Grove of Intel and Bill Gates
of Microsoft - this was a while ago). But we were talking about
selecting machines for research, and in that case the same software
would be used.

Compare running Squeak on a 40MHz 386 PC (my 1992 computer) with running
the exact same code on a 1GHz Pentium 4 PC (available to me in 2000).
Not even the old MVC interface is really usable on the first while the
second machine can handle Morphic just fine. The quantitive difference
becomes a qualititive one. I didn't feel the same between my 1 MHz Apple
II and the 6MHz PC AT. But of course there was a diffence - to show of
the AT in trade shows we used to run a Microsoft flight simulator called
Jet (later merged with MS Flight Simulator) on that machine side by side
with a 4.77MHz PC XT. It was a fun game on the AT, but looked more like
a slide show on the XT. I still felt I could get by with the Apple II,
however.

How can we spend money now to live in the future? Alan mentioned the
first way in his talk: put lots and lots of FPGA together. The BEE3
board isn't cheap (something like $5K without the FPGAs, which are a few
thousand dollars each themselves, nor memory) and a good RAMP machine
hook a bunch of these together. The advantage of this approach is that
each FPGA is large enough to do pretty much anything you can imagine. If
you know your processors will be rather small, it might be more cost
effective to have a larger number of cheaper FPGAs. That is what I am
working on.

A second way to live in the future is far less flexible, and so should
only be a second step after the above is no longer getting you the
results you need: use wafer scale integration to have now roughly the
same number of transistors you will have in 2020 on a typical chip. This
is pretty hard (just ask Clive Sinclair or Gene Amdahl how much they
lost on wafer scale integration back in the 1980s). But if you can get
it to work, then you could distribute hundreds (or more) of 2020's
computers to today's researchers.

-- Jecel


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-16 Thread karl ramberg 
On Thu, Dec 15, 2011 at 2:09 AM, Jecel Assumpcao Jr. wrote:

> Karl Ramberg wrote:
>
> > One of Alans points in his talk is that students should be using
> bleeding edge
> > hardware, not just regular laptops. I think he is right for some part
> but he also
> > recollected the Joss environment which was done on a machine about to be
> > scraped. Some research and development does not need the bleeding edge
> > hardware. It can get a long way by using what you have till it's fullest.
>
> You mixed research and development, and they are rather different. One
> is building stuff for the computers of 2020, the other for those of
> 2012.
>

It's true that I mixed them. Alas much development is research and much
research is development :-)

Karl

>
> I was at a talk where Intel was showing their new multicore direction
> and the guy kept repeating how the academic people really should be
> changing their courses to teach their students to deal with, for
> example, four cores. At the very end he showed an experimental 80 core
> chip and as he ended the talk and took questions he left that slide up.
> When it was my turn to ask, I pointed to the 80 core chip on the screen
> and asked if programming it was exactly the same as on a quad core. He
> said it was different, so I asked if it wouldn't be better investment to
> teach the students to program the 80 core one instead? He said he didn't
> have an answer to that.
>
> About Joss, we normally like to plot computer improvement on a log
> scale. But if you look at it on a linear scale, you see that many years
> go by initially where we don't see any change. So the relative
> improvement in five years is more or less the same no matter what five
> years you pick, but the absolute improvement is very different. When I
> needed a "serious" computer for software development back in 1985 I
> built an Apple II clone for myself, even though that machine was already
> 8 years old at the time (about five Moore cycles). The state of the art
> in personal computers at the time was the IBM PC AT (6MHz iAPX286) which
> was indeed a few times faster than the Apple II, but not enough to make
> a qualitative difference for me. If I compare a 1992 PC with one from
> 2000, the difference is far more important to me.
>
> > On Tue, Dec 13, 2011 at 9:02 PM, Kim Rose wrote:
> >
> > For those of you looking to hear more from Alan Kay -- you'll find a
> talk from
> > him and several other "big names in computer science" here -- thanks to
> San
> > Jose State University.
> >
> >
> http://www.sjsu.edu/atn/services/webcasting/archives/fall_2011/hist/computing.html
>
> Thanks, Kim, for the link!
>
> I have added this and four other talks from 2011 to
>
> http://www.smalltalk.org.br/movies/
>
> I also added a link to the Esug channel on Youtube, which has lots of
> stuff from their recent conferences.
>
> Cheers,
> -- Jecel
>
>
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc
>
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread Casey Ransberger 
Inline below.

On Dec 15, 2011, at 2:31 AM, Juan Vuletich  wrote:

> frank wrote:
>> On 12/15/2011 08:02 AM, Casey Ransberger wrote:
>>  
>>> Hypothesis: Mainstream software slows down at a rate slightly less than
>>> mainstream hardware speeds up.
>>>
>> 
>> Hmmm, seems like a more optimistic Version of Wirth's law (yes, Niklaus):
>> "Software is getting slower more rapidly than hardware becomes faster."
>> 
>>  Frank
>>  
> 
> There's also Nathan Myhrvold's four Laws of Software: ( 
> http://www.codinghorror.com/blog/2006/09/software-its-a-gas.html , 
> http://blogs.msdn.com/b/larryosterman/archive/2005/06/17/430215.aspx ).
> 1) Software is a gas: Software always expands to fit whatever container it is 
> stored in.

Good metaphor. Melikes.

> 2) Software grows until it becomes limited by Moore's Law: The initial growth 
> of software is rapid, like gas expanding, but is inevitably limited by the 
> rate of increase in hardware speed.

Too true!

> 3) Software growth makes Moore's Law possible: People buy new hardware 
> because the software requires it.

Funny, but I think Moore's Law happens because around every 18 months, a large 
enough contingent of people want to buy a computer that's orders of magnitude 
faster / has orders of magnitude more storage/memory and faster network more 
pixels etc blah, blah, blah than what they've been getting on with for a number 
of years. 

> 4) Software is only limited by human ambition and expectation: We'll always 
> find new algorithms, new applications, and new users.

It kind of seems like this one should actually help. I think what's really 
happening is: every programmer rediscovers the same algorithm and codes it up, 
not knowing that it's already in the standard library, because the standard 
library is so big that no one wants to read it. 

> These are interesting for several reasons. One is that Nathan doesn't only 
> describe the phenomena, but also a possible explanation for it.

Which makes his arguments fun!

> Besides, now that it seems Moore's Law doesn't hold anymore, what will happen?

I'm not buying it. The economy just sucks. Give it a couple of holiday seasons, 
ARM and Intel will find a way again to sell me a computer that's twice as fast 
as the one I bought a year and a half ago;)

> Will software bloat end? Will we focus again in efficiency and simplicity? 
> Will this make projects like FONC and Cuis relevant to mainstream?

One thing that's clear: people are really into little portable gadgets right 
now. So the shift happened: it's not about how many volts you can push through 
some silicon without melting it right now, it's about how much you can get done 
with as little electricity as possible. 

FWIW, I think this shift is why we aren't seeing performance-doubling. I think 
we're seeing market focus on battery-life-doubling instead. When I really think 
about it, these are two sides of the same coin. Which is why I still doubt that 
Moore was wrong...

> WRT law 3), we already see the change. Some years ago, computers were 
> advertised only in terms of speed. Now they make people want new, slower 
> computers (iPads and such). Regular PCs, even if much faster, are not "fancy" 
> anymore.

Depends on market segment. I want a cheap slow (you know, fast, like my old 
Mac, not slow like that fast AMD thing and Windows, that's just too slow) 
computer that has a battery that lasts for days but still lets me program like 
I could on my desktop (nope, Android, this isn't you. Don't want language 
hurdles. Just let me compile what I want.)

"Devil's Advocate" but I'm mostly with ya:)

> Cheers,
> Juan Vuletich
> 
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread Juan Vuletich 

frank wrote:

On 12/15/2011 08:02 AM, Casey Ransberger wrote:
  

Hypothesis: Mainstream software slows down at a rate slightly less than
mainstream hardware speeds up.



Hmmm, seems like a more optimistic Version of Wirth's law (yes, Niklaus):
"Software is getting slower more rapidly than hardware becomes faster."

  Frank
  


There's also Nathan Myhrvold's four Laws of Software: ( 
http://www.codinghorror.com/blog/2006/09/software-its-a-gas.html , 
http://blogs.msdn.com/b/larryosterman/archive/2005/06/17/430215.aspx ).
1) Software is a gas: Software always expands to fit whatever container 
it is stored in.
2) Software grows until it becomes limited by Moore's Law: The initial 
growth of software is rapid, like gas expanding, but is inevitably 
limited by the rate of increase in hardware speed.
3) Software growth makes Moore's Law possible: People buy new hardware 
because the software requires it.
4) Software is only limited by human ambition and expectation: We'll 
always find new algorithms, new applications, and new users.


These are interesting for several reasons. One is that Nathan doesn't 
only describe the phenomena, but also a possible explanation for it.


Besides, now that it seems Moore's Law doesn't hold anymore, what will 
happen? Will software bloat end? Will we focus again in efficiency and 
simplicity? Will this make projects like FONC and Cuis relevant to 
mainstream?


WRT law 3), we already see the change. Some years ago, computers were 
advertised only in terms of speed. Now they make people want new, slower 
computers (iPads and such). Regular PCs, even if much faster, are not 
"fancy" anymore.


Cheers,
Juan Vuletich

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread Juan Vuletich 

frank wrote:

On 12/15/2011 09:42 AM, frank wrote:
  

On 12/15/2011 08:02 AM, Casey Ransberger wrote:


Hypothesis: Mainstream software slows down at a rate slightly less than
mainstream hardware speeds up.
  

Hmmm, seems like a more optimistic Version of Wirth's law (yes, Niklaus):
"Software is getting slower more rapidly than hardware becomes faster."



Sorry for self-reply, but here is some evidence:

http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins
  


This is great! Thanks.


=)
  


Cheers,
Juan Vuletich

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread Eugen Leitl 
On Wed, Dec 14, 2011 at 10:09:20PM -0300, Jecel Assumpcao Jr. wrote:

> I was at a talk where Intel was showing their new multicore direction
> and the guy kept repeating how the academic people really should be
> changing their courses to teach their students to deal with, for
> example, four cores. At the very end he showed an experimental 80 core
> chip and as he ended the talk and took questions he left that slide up.
> When it was my turn to ask, I pointed to the 80 core chip on the screen
> and asked if programming it was exactly the same as on a quad core. He
> said it was different, so I asked if it wouldn't be better investment to

Of course it's different; globally coherent memories don't scale
with fermionic computers in a relativistic universe. The latest
boondoggle in the let's-keep-investing-into-expensive-illusions
is transactional memory in the mainstream. I was hoping for AMD
to step forward with TSV-stacked memories in their APUs, but that's
probably not going to happen now that's they're fighting for
survivial. Will nVidia do it?

> teach the students to program the 80 core one instead? He said he didn't
> have an answer to that.

It's remarkable how few are using MPI in practice. A lot of code 
is being made multithread-proof, and for what? So that they'll have
to rewrite it for message-passing, again?
 

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread Andre van Delft 

Op 15 dec. 2011, om 08:02 heeft Casey Ransberger het volgende geschreven:

> Hypothesis: Mainstream software slows down at a rate slightly less than 
> mainstream
> hardware speeds up. It's an almost-but-not-quite-inverse Moore's Law. 
> Unless someone else has called this out directly, I'm calling it Joe's Law,
> because I don't want to deal with the backlash!
> 

You are an optimist. Wirth's law says: 
"Software is getting slower more rapidly than hardware becomes faster"
And Gates' law: 
"The speed of software halves every 18 months"
See http://en.wikipedia.org/wiki/Wirth's_law___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread Casey Ransberger 
The article on Wikipedia about Parkinson's law mentions Wirth's law. 

Bucket of win! I think we're onto something, ladies and gentleman. I'll be in 
town all week: try the fish. 

On Dec 15, 2011, at 12:42 AM, frank  wrote:

> On 12/15/2011 08:02 AM, Casey Ransberger wrote:
>> Hypothesis: Mainstream software slows down at a rate slightly less than
>> mainstream hardware speeds up.
> 
> Hmmm, seems like a more optimistic Version of Wirth's law (yes, Niklaus):
> "Software is getting slower more rapidly than hardware becomes faster."
> 
>  Frank
> 
> 
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread Casey Ransberger 
Below. 

On Dec 14, 2011, at 11:14 PM, David Barbour  wrote:

> Hypothesis: Mainstream software slows down at a rate slightly less than 
> mainstream hardware speeds up. It's an almost-but-not-quite-inverse Moore's 
> Law.
> 
> Unless someone else has called this out directly, I'm calling it Joe's Law, 
> because I don't want to deal with the backlash!
> 
> It's a variation on Parkinson's Law. 

Haha! I knew if there was prior art, someone here would set me straight. I'd 
*never* heard of this but it's s true for so many things. Mass 
corollaries!

Thank you so much for putting me onto such a succinct statement of so broadly 
applicable a truism!

(Seriously this is great. Forwarding link to almost everyone I know...)___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread frank 
On 12/15/2011 09:42 AM, frank wrote:
> On 12/15/2011 08:02 AM, Casey Ransberger wrote:
>> Hypothesis: Mainstream software slows down at a rate slightly less than
>> mainstream hardware speeds up.
> 
> Hmmm, seems like a more optimistic Version of Wirth's law (yes, Niklaus):
> "Software is getting slower more rapidly than hardware becomes faster."

Sorry for self-reply, but here is some evidence:

http://hallicino.hubpages.com/hub/_86_Mac_Plus_Vs_07_AMD_DualCore_You_Wont_Believe_Who_Wins

=)

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-15 Thread frank 
On 12/15/2011 08:02 AM, Casey Ransberger wrote:
> Hypothesis: Mainstream software slows down at a rate slightly less than
> mainstream hardware speeds up.

Hmmm, seems like a more optimistic Version of Wirth's law (yes, Niklaus):
"Software is getting slower more rapidly than hardware becomes faster."

  Frank


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-14 Thread David Barbour 
On Wed, Dec 14, 2011 at 11:02 PM, Casey Ransberger  wrote:

> But in general... my computer is only a tiny bit faster than the one I had
> in the early nineties. In terms of day to day stuff, it's only gotten a
> tinsy bit faster. Sometimes I sit there looking at an hourglass or a beach
> ball and think to myself "this only used to happen when I was waiting on a
> disk to spin about. There isn't even a disk in this thing. What the hell?"
>
> Hypothesis: Mainstream software slows down at a rate slightly less than
> mainstream hardware speeds up. It's an almost-but-not-quite-inverse Moore's
> Law.


> Unless someone else has called this out directly, I'm calling it Joe's
> Law, because I don't want to deal with the backlash!
>

It's a variation on Parkinson's Law.
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-14 Thread Casey Ransberger 
Inline and greatly abridged. 

On Dec 14, 2011, at 5:09 PM, "Jecel Assumpcao Jr."  wrote:

> About Joss, we normally like to plot computer improvement on a log
> scale. But if you look at it on a linear scale, you see that many years
> go by initially where we don't see any change. So the relative
> improvement in five years is more or less the same no matter what five
> years you pick, but the absolute improvement is very different. When I
> needed a "serious" computer for software development back in 1985 I
> built an Apple II clone for myself, even though that machine was already
> 8 years old at the time (about five Moore cycles).

That's just so cool. Someday I want to make an Apple IIgs clone because that 
thing rocked and the emulator I have is dog-slow:/ but we've talked about that 
before!

> The state of the art
> in personal computers at the time was the IBM PC AT (6MHz iAPX286) which
> was indeed a few times faster than the Apple II, but not enough to make
> a qualitative difference for me. If I compare a 1992 PC with one from
> 2000, the difference is far more important to me.

Okay so this is where stuff gets funny to me. My computer, if you look at the 
clock and the cores, is blazing fast. You can see it once in awhile: when doing 
something graphically intensive (the GPU is also really fast) or something 
straightforwardly computationally expensive, like compiling C code with all of 
the optimizations on. 

But in general... my computer is only a tiny bit faster than the one I had in 
the early nineties. In terms of day to day stuff, it's only gotten a tinsy bit 
faster. Sometimes I sit there looking at an hourglass or a beach ball and think 
to myself "this only used to happen when I was waiting on a disk to spin about. 
There isn't even a disk in this thing. What the hell?"

Hypothesis: Mainstream software slows down at a rate slightly less than 
mainstream hardware speeds up. It's an almost-but-not-quite-inverse Moore's 
Law. 

Unless someone else has called this out directly, I'm calling it Joe's Law, 
because I don't want to deal with the backlash!

> Cheers,
> -- Jecel
> 
> 
> ___
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/listinfo/fonc

___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-14 Thread Jecel Assumpcao Jr. 
Karl Ramberg wrote:

> One of Alans points in his talk is that students should be using bleeding edge
> hardware, not just regular laptops. I think he is right for some part but he 
> also
> recollected the Joss environment which was done on a machine about to be
> scraped. Some research and development does not need the bleeding edge
> hardware. It can get a long way by using what you have till it's fullest.

You mixed research and development, and they are rather different. One
is building stuff for the computers of 2020, the other for those of
2012.

I was at a talk where Intel was showing their new multicore direction
and the guy kept repeating how the academic people really should be
changing their courses to teach their students to deal with, for
example, four cores. At the very end he showed an experimental 80 core
chip and as he ended the talk and took questions he left that slide up.
When it was my turn to ask, I pointed to the 80 core chip on the screen
and asked if programming it was exactly the same as on a quad core. He
said it was different, so I asked if it wouldn't be better investment to
teach the students to program the 80 core one instead? He said he didn't
have an answer to that.

About Joss, we normally like to plot computer improvement on a log
scale. But if you look at it on a linear scale, you see that many years
go by initially where we don't see any change. So the relative
improvement in five years is more or less the same no matter what five
years you pick, but the absolute improvement is very different. When I
needed a "serious" computer for software development back in 1985 I
built an Apple II clone for myself, even though that machine was already
8 years old at the time (about five Moore cycles). The state of the art
in personal computers at the time was the IBM PC AT (6MHz iAPX286) which
was indeed a few times faster than the Apple II, but not enough to make
a qualitative difference for me. If I compare a 1992 PC with one from
2000, the difference is far more important to me.

> On Tue, Dec 13, 2011 at 9:02 PM, Kim Rose wrote:
> 
> For those of you looking to hear more from Alan Kay -- you'll find a talk from
> him and several other "big names in computer science" here -- thanks to San
> Jose State University.
> 
>  http://www.sjsu.edu/atn/services/webcasting/archives/fall_2011/hist/computing.html

Thanks, Kim, for the link!

I have added this and four other talks from 2011 to

http://www.smalltalk.org.br/movies/

I also added a link to the Esug channel on Youtube, which has lots of
stuff from their recent conferences.

Cheers,
-- Jecel


___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc

Re: [fonc] History of computing talks at SJSU

2011-12-14 Thread karl ramberg 
One of Alans points in his talk is that students should be using bleeding
edge hardware, not just regular laptops. I think he is right for some part
but he also recollected the Joss environment which was done on a machine
about to be scraped. Some research and development does not need the
bleeding edge hardware. It can get a long way by using what you have till
it's fullest.

Karl

On Tue, Dec 13, 2011 at 9:02 PM, Kim Rose  wrote:

> For those of you looking to hear more from Alan Kay -- you'll find a talk
> from him and several other "big names in computer science" here -- thanks
> to San Jose State University.
>
>  http://www.sjsu.edu/atn/**services/webcasting/archives/**
> fall_2011/hist/computing.html
>
>  -- Kim
>
>
> __**_
> fonc mailing list
> [email protected]
> http://vpri.org/mailman/**listinfo/fonc
>
___
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc