

Next year's computers same speed but more cores/cpus: developer challenge - wglb
http://www.tbray.org/ongoing/When/200x/2009/09/27/Concur-dot-next

======
wglb
As painful as it is, I found dealing with an interrupt-rich environment much
easier in assembler than in other languages. The ability to use coroutines
significantly reduced our efforts in building interrupt-based programs. Plus
the ability to segregate tasks by interrupt level, this helped a bit.

Besides the yield statement in Python, very few other higher-level languages
seem to have anything resembling a coroutine. Bliss/36 had it, but one could
argue about how high-level it is.

~~~
joechung
What is special about Python's yield statement compared to the ones in Ruby,
C#, and other languages?

~~~
camccann
More significantly, continuations are a strict superset of coroutines, so
standard Python is actually less powerful in this regard than languages with
full continuation support, which if memory serves me includes Ruby, Smalltalk,
and Scheme among others.

~~~
m0th87
Python has coroutines as of 2.5: <http://www.python.org/dev/peps/pep-0342/>

------
10ren
It's been said before: old apps on old hardware are a similar speed to today's
apps on today's hardware. Often, they're snappier.

Faster hardware makes software slower. Partly it's because they're doing more;
partly it's due to inefficiency: _Work expands to fill the available time_ \-
Parkinson's Law

1\. Apps are already fast enough.

2\. If we need extra speed to do extra things, we can draw on the reservoir of
inefficiencies. Examples: Flash's ActionScript became many times faster in ver
3 (on the order of Javascript to Java). Google improved plain Javascript
performance by up to x10 in its Chrome browser. Apple's iPhone is very snappy.

3\. We seem to have overshot the _need_ for performance (making it ripe for
disruption), and that people value things other than performance, like
mobility, size, weight, battery life - as in netbooks and smartphones.

~~~
fauigerzigerk
_old apps on old hardware are a similar speed to today's apps on today's
hardware._

Maybe, but very often they don't do the same thing, which makes the comparison
useless.

I don't remember being able to search and rank billions of documents in sub
second time back in the 90s or mine terrabytes of data to find cures for
cancer. We now do predictive analytics where we did quarterly reporting in the
80s and 90s.

Let's not view computing primarily as word processing with 500MB of bloat
added in each new version :-)

------
miked
I'm surprised I haven't seen anyone mention Clojure yet. It was designed
specifically to deal with multiple cores in an elegant fashion thru atoms,
agents, and software transactional memory. It might just be the answer to the
challenge. Check it out, if you haven't already.

~~~
wglb
I have heard very good things about it including Dan Weinreb, long time lisp
guy, who is very excited about it.

I would be inclined to work with clojure if I had any java projects or
seriously threaded projects.

My multi-core stuff these days is done the easy way--separate long-running
processes, loosely coupled.

------
jsankey
A mitigating factor is that not much software is CPU-bound: many desktop apps
spend most of their time idly waiting for input, and most web apps have
already been dealing with concurrency by handling multiple users (and scaling
out).

~~~
jrockway
The reason people have such trouble scaling web apps is that they think the
above is true.

~~~
jsankey
Could you elaborate? Are you saying that apps are CPU bound or that web apps
have not been dealing with concurrency even before multi-core? Perhaps you
mean that web app authors care about CPU usage too little, which may be true,
but I still don't think that multi-core marks a huge change for them.

~~~
dagw
The thing to remember is that there are two sides to a web-app. The client and
the server. The web-app I'm currently working on uses very little CPU client
side, but on the server side the number of simultaneous users I can handle
scales more or less linearly with the number of cores the server has (assuming
enough memory). So personally multiple cores (and using the correctly) makes
huge difference to me and the web-app I'm working on.

~~~
jsankey
I apologise for not being clear: certainly multi-core makes a difference to
the performance of web apps. My point is that most web apps don't need a
drastic change in the way they are written to take advantage of this: they are
already multithread or multiprocess to handle concurrent users. Contrast this
to single-user desktop apps which have simpler threading models and are less
likely to be "naturally" parallelised to take advantage of multi-core.

------
wheaties
This is one of the reasons Microsoft came out with F#. Now if only Ocaml could
get its act together and give me true multi-core support. Ah well. We all have
our pet languages, don't we?

