Here's an amusing giggle:

http://www.metacard.com/java.html

"Java also supports multithreading, a powerful but extremely rarely 
essential and exceedingly difficult to use programming paradigm. Given a 
sufficiently advanced time-based event scheduler, such as those 
available in MetaCard and Macromedia Director, no application developer 
should even be tempted to try to manage a multi-threaded application."

I wonder when *this* was written, eh? ;-)

"But as it becomes more common for special purpose applications (like 
spreadsheets and word processors) to have Internet connectivity built 
in, the ability to enhance general-purpose WWW browsers with these 
capabilities will become less and less important."

Oh how wrong you are... [Sadly]

"CORBA and ActiveX also will make serious inroads into the areas that 
are Java's forte."

Um...

"By delaying acceptance of CORBA and OpenDoc, Java is probably also 
going to set back the development of the Internet tools we all really 
need by many years."

...oh, OK. They did see that one coming after all.



PS. Oh, it says at the bottom. 1996. Yeah, fast-forward 14 years and see 
how "extremely rarely essential" it is to do multi-threading. ;-)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> PS. Oh, it says at the bottom. 1996. Yeah, fast-forward 14 years and see
> how "extremely rarely essential" it is to do multi-threading. ;-)

Aside from embarassingly parallel tasks like raytracing, most apps still are
essentially single threaded, apart perhaps from another thread for a database
connection and another for GUI events, no matter how many cores keep idle in
your new CPUs.  At least the OS can start processes in different ones...

Coarse grained multiprocessing as represented by threads does that:  its
complexity prevents developers from tapping all that multicore power.  Fine
grained parallelism implicitely implemented by compilers for any chance they see
fit should help there... but not for severely imperative code...

Post a reply to this message

nemesis <nam### [at] gmailcom> wrote:
> Aside from embarassingly parallel tasks like raytracing, most apps still are
> essentially single threaded, apart perhaps from another thread for a database
> connection and another for GUI events, no matter how many cores keep idle in
> your new CPUs.  At least the OS can start processes in different ones...

  Actually a surprisingly large number of GUI applications are multithreaded,
by necessity. Basically any GUI application which performs tasks which take
time to complete (be it because the task is very cpu-intensive and takes
time to calculate, or because the program has to wait for something, eg.
data to be downloaded from the internet) have to be multithreaded: One
thread for the task and another for updating the GUI. Such a GUI app *can*
be single-threaded, but then it becomes completely unresponsive while the
task is being performed (even the app's window will not be repainted, and
the app will be listed as "not responding" in the OS's task manager), which
is quite ugly and user-unfriendly.

  Of course what people *usually* mean by "multithreaded" is that the
*task* itself is performed by multiple threads. The 2-thread gui/task
idiom is not usually what is meant by a "multithreaded application",
even though technically speaking it is. (The difference with the gui/task
2-thread idiom and a truly multi-threaded application in the colloquial
sense is that the latter can make use of multiple processors/cores to
perform the task more quickly, while the former doesn't.)

  One industry where multithreading has been all the rage in later years
is the gaming industry. Every major (and even most minor) game engine has
jumped on the multithreading bandwagon with the raising popularity of
multicore CPUs.

  The problem of multithreading in a game engine is quite a difficult one.
One of the major problems is that a typical game engine needs to perform
hundreds and hundreds of small tasks on each frame, and distributing these
tasks to multiple processors efficiently is hard. Just the mutual exclusion
problem is hard because it needs to be as efficient as possible. Using
hundreds of software-based locks is simply not going to cut it because
software locks are heavy. Software locks are ok when you need the locking
just once per second, or even a dozen of times per second, but they start
being a significant overhead when you need to lock hundreds of times per
frame (and your target framerate is at least 60 frames per second).

  This efficient locking problem is not something that can usually be
solved by using a programming language which has inherent multithreading
support. You usually need very specialized lock-free algorithms and
containers, and high-level languages often make developing them difficult.

-- 
                                                          - Warp

Post a reply to this message

>  Actually a surprisingly large number of GUI applications are 
> multithreaded,
> by necessity. Basically any GUI application which performs tasks which 
> take
> time to complete (be it because the task is very cpu-intensive and takes
> time to calculate, or because the program has to wait for something, eg.
> data to be downloaded from the internet) have to be multithreaded: One
> thread for the task and another for updating the GUI.

IIRC there are some API functions to poll for new data, ie check if any 
bytes have been received.  If you do this at regular intervals then you can 
create a single-threaded application that is still responsive as usual to 
GUI events.

Post a reply to this message

nemesis wrote:
> Aside from embarassingly parallel tasks like raytracing,

That and media encoding are the only programs I've used in a decade that peg 
more than one CPU.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

Warp wrote:
> have to be multithreaded:

They don't *have* to be, but it's certainly a lot easier, especially in 
languages where handling event loops is problematic (like those without 
closures or whatever).

>   This efficient locking problem 

I always wondered why nobody makes a CPU with a non-privileged instruction 
that says something like "turn off interrupts for the next N instructions", 
where N < 8 or so. Then you wouldn't need "test-and-set" or atomic writes or 
any of that sort of specialized instructions.

Of course, I guess the time for that idea has come and gone with the rise of 
multicore machines where interrupts aren't the only thing you have to lock.

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message

On 17/11/2010 06:36 PM, Warp wrote:

>    Actually a surprisingly large number of GUI applications are multithreaded,
> by necessity.

I wish *more* GUI applications were multithreaded. :-S

(For example, closing the CD tray is enough to lock up almost the entire 
Windows Explorer shell until the OS can determine whether there is a CD 
in the drive. Similarly, accidentally clicking on drive A: will do more 
or less the same thing. WTF, people?!)

>    One industry where multithreading has been all the rage in later years
> is the gaming industry.

Really? I haven't been paying attention especially closely. Last time I 
looked, the advice was "don't ever buy a multi-core CPU for a gaming 
machine because no games support it yet". Has that finally changed now?

>    The problem of multithreading in a game engine is quite a difficult one.

The magic problem I found was that when I play games on a dual-core 
system, the game speeds up. As in, like, you can now run 7x faster 
(which is great), and the enemies can shoot back at you 7x faster. And 
the graphics flicker. And the sound gets out of sync. And basically it's 
impossible to play. Setting the task affinity to pin the game to one 
core fixes the problem. (I gather it's to do with the real-time clock 
being per-core or something like that...)

> One of the major problems is that a typical game engine needs to perform
> hundreds and hundreds of small tasks on each frame, and distributing these
> tasks to multiple processors efficiently is hard.

Presumably it's hard to balance work evenly. Then there's the problem of 
cache coherence if you try to do too much balancing. (I.e., if the data 
you want is in the cache on core X, trying to process that data from 
core Y is *slower* than not using an extra thread.)

> Just the mutual exclusion
> problem is hard because it needs to be as efficient as possible.

I guess the solution is to avoid the need for mutual exclusion to the 
maximum extent possible. Even if you can make it efficient, by 
definition it reduces the amount of stuff that can happen at once.

> You usually need very specialized lock-free algorithms and
> containers

Using lock-free systems is one good way of avoiding the problem, yes.

> and high-level languages often make developing them difficult.

I can't say. I haven't tried. It's one of those things that I'd like to 
read about someday though. I have no idea how these algorithms work, and 
it sounds interesting.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:
> I always wondered why nobody makes a CPU with a non-privileged instruction 
> that says something like "turn off interrupts for the next N instructions", 
> where N < 8 or so. Then you wouldn't need "test-and-set" or atomic writes or 
> any of that sort of specialized instructions.

> Of course, I guess the time for that idea has come and gone with the rise of 
> multicore machines where interrupts aren't the only thing you have to lock.

  I think it would cause security problems if a userland program could turn
off interrupts, even if for a limited period of time.

  Besides, most/all CPU designs (especially Intel's) have always supported
multiprocessor setups, so having to support true multitasking has always
been there.

-- 
                                                          - Warp

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> >    One industry where multithreading has been all the rage in later years
> > is the gaming industry.

> Really? I haven't been paying attention especially closely. Last time I 
> looked, the advice was "don't ever buy a multi-core CPU for a gaming 
> machine because no games support it yet". Has that finally changed now?

  Most of the "big" game engines (especially the Unreal Engine) support
multithreading today, so more and more games are automatically supporting
it as well. It's actually becoming increasingly rare for big games to *not*
support multithreading (with the possible exception of games which don't
*need* it, although that is also becoming increasingly rare due to the high
demand of games with more advanced features).

  Of course "supports multithreading" is not a simple and unambiguous thing
to do. There's always room for supporting it better, distributing load among
cores better, and so on. Some game engines might advertise themselves as
supporting multiple cores, but in reality it might be that one core will
be constantly at 100% load while the others will be at 20% or whatever
(and hence the game will not be as fast as it could theoretically be).
As said, it's a difficult problem.

> > Just the mutual exclusion
> > problem is hard because it needs to be as efficient as possible.

> I guess the solution is to avoid the need for mutual exclusion to the 
> maximum extent possible. Even if you can make it efficient, by 
> definition it reduces the amount of stuff that can happen at once.

  But that's precisely what's so problematic with game engines in particular.
If you try to avoid the need for locks as much as possible, you end up
precisely in the situation where you have 100% load on one CPU and 20% on
the others, because the load is not balanced.

  Often this doesn't matter, but othertimes it would be beneficial if the
game could use all the cores fully.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
>   I think it would cause security problems if a userland program could turn
> off interrupts, even if for a limited period of time.

I can't really think what kind of problems it would cause if it was limited 
to a certain number of cycles and the system was written knowing the CPU had 
that capability. I mean, it normally takes dozens if not hundreds of cycles 
to handle an interrupt.

Of course, you'd probably want it to only be able to turn off the lower 
priority interrupts.

>   Besides, most/all CPU designs (especially Intel's) have always supported
> multiprocessor setups, so having to support true multitasking has always
> been there.

I had this thought back when I was working on computers with actual core. 
I'm not even sure Intel existed as a company at that point. :-)

-- 
Darren New, San Diego CA, USA (PST)
   Serving Suggestion:
     "Don't serve this any more. It's awful."

Post a reply to this message