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

Warp wrote:
>   Most of the "big" game engines (especially the Unreal Engine) support
> multithreading today, 

Heck, even XNA supports it on the xbox. It's a bit funky to get it set up - 
you have to create a thread, assign the thread to a core (some of which are 
reserved), and then run the thread, and that thread never changes cores. But 
it's supported if you want to do (say) physics on one core and rendering on 
another.

-- 
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 11:55 PM, Darren New wrote:
> 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.

How about stuff like web servers and database engines? Granted that 
tends to be limited more by I/O then computer power, but don't those 
routinely use multiple cores? (Obviously these are not usually *desktop* 
applications...)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Invisible wrote:
> 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.)

Not only cache. With increasing numbers of cores, you will have that problem 
with main memory too; read up on NUMA.

Post a reply to this message

Orchid XP v8 wrote:
> On 17/11/2010 11:55 PM, Darren New wrote:
>> 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.
> 
> How about stuff like web servers and database engines? 

Web servers usually use multiple processes. Database engines I suppose if 
your entire database is in RAM would peg the CPUs if you thrashed at it hard 
enough, sure.  I never pegged a database that hard, tho.

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

Post a reply to this message

nemesis wrote:
> essentially single threaded,

How about photoshop(TM)? The cheap photo manipulation programs are 
single-threaded, but does photoshop use all four cores when you do something 
where that makes sense (like smoothing or contrast adjust or something 
highly parallelizable)?  I don't own a copy, so I can't tell.


-- 
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 19/11/2010 02:22 AM, Nicolas Alvarez wrote:
> Invisible wrote:
>> 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.)
>
> Not only cache. With increasing numbers of cores, you will have that problem
> with main memory too; read up on NUMA.

Well, yes, with multiple cores and multiple levels of caching, your 
computer system basically ends up being NUMA in all but name anyway. The 
difference is, in a real NUMA system, the system doesn't *pretend* that 
it offers uniform access time. And that means you can control where 
stuff gets put to optimise access speed.

Now, optimising data placement is a seriously hard problem, I would 
imagine. (Somebody once wrote "a supercomputer is a device for turning a 
compute-bound problem into an I/O-bound problem".)

Post a reply to this message

Darren New escreveu:
> nemesis wrote:
>> essentially single threaded,
> 
> How about photoshop(TM)? The cheap photo manipulation programs are 
> single-threaded, but does photoshop use all four cores when you do 
> something where that makes sense (like smoothing or contrast adjust or 
> something highly parallelizable)?  I don't own a copy, so I can't tell.

I don't own a copy either.  In fact, I don't see why any image 
manipulation program wouldn't do their turf on many GPU cores instead...

-- 
a game sig: http://tinyurl.com/d3rxz9

Post a reply to this message

nemesis wrote:
> I don't own a copy either.  In fact, I don't see why any image 
> manipulation program wouldn't do their turf on many GPU cores instead...

That too, assuming you *have* a GPU.  Do laptops have decent GPUs these 
days?  I know there are a lot of machines with Intel built-in graphics type 
stuff using normal system memory for the graphics memory, but I don't know 
if that means they're not 3D-accelerated ornot.

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

Post a reply to this message

>> I don't own a copy either. In fact, I don't see why any image
>> manipulation program wouldn't do their turf on many GPU cores instead...
>
> That too, assuming you *have* a GPU. Do laptops have decent GPUs these
> days? I know there are a lot of machines with Intel built-in graphics
> type stuff using normal system memory for the graphics memory, but I
> don't know if that means they're not 3D-accelerated ornot.

My laptop has a "nVidia GeForce 8200 Mobile GPU".

Key phrase being "mobile"... It does play CounterStrike: Source, however.

Post a reply to this message

Invisible wrote:
>>> I don't own a copy either. In fact, I don't see why any image
>>> manipulation program wouldn't do their turf on many GPU cores instead...
>>
>> That too, assuming you *have* a GPU. Do laptops have decent GPUs these
>> days? I know there are a lot of machines with Intel built-in graphics
>> type stuff using normal system memory for the graphics memory, but I
>> don't know if that means they're not 3D-accelerated ornot.
> 
> My laptop has a "nVidia GeForce 8200 Mobile GPU".
> 
> Key phrase being "mobile"... It does play CounterStrike: Source, however.


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

It looks like even the cheap integrated graphics chips do DirectX9, so I 
guess you could pretty much rely on pixel shaders for photoshop.

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

Post a reply to this message