----ALT--HltwaY0V1296990756
Content-Type: text/plain; charset=koi8-r
Content-Transfer-Encoding: 8bit

What's the suggested module for perl's threads?
I have been using Perl 5.12 under linux.

Thanks.

----ALT--HltwaY0V1296990756--

From: "terry peng" <terry.peng [at] mail.ru>
> What's the suggested module for perl's threads?
> I have been using Perl 5.12 under linux.
>
> Thanks.



use threads;
use threads::shared;

Octavian



--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-02-06 07:10 AM, Octavian Rasnita wrote:
> From: "terry peng"<terry.peng [at] mail.ru>
>> What's the suggested module for perl's threads?
>> I have been using Perl 5.12 under linux.
>>
>> Thanks.
>
>
>
> use threads;
> use threads::shared;

use Thread::Queue;

This module does the work of threads::shared. It is easier to use.


--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Sun, 06 Feb 2011 08:54:50 -0500 письмо от Shawn H Corey <shawnhcorey [at] gmail.com>:

> On 11-02-06 07:10 AM, Octavian Rasnita wrote:
> > From: "terry peng"<terry.peng [at] mail.ru>
> >> What's the suggested module for perl's threads?
> >> I have been using Perl 5.12 under linux.
> >>
> >> Thanks.
> >
> >
> >
> > use threads;
> > use threads::shared;
>
> use Thread::Queue;
>
> This module does the work of threads::shared. It is easier to use.
>


Thanks for all your helps.
How about the Coro module?
http://search.cpan.org/~mlehmann/Coro-5.25/Coro.pm

I have heard Threads is out of date in modern perl.

Thanks.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2011-02-06 12:12, terry peng wrote:

> What's the suggested module for perl's threads?
> I have been using Perl 5.12 under linux.

Stay away from threads. Design and develop in a way that no internal
resources (but read-only data) are shared.

--
Ruud

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Sun, 06 Feb 2011 16:21:58 +0100 письмо от "Dr.Ruud" <rvtol+usenet [at] isolution.nl>:

> On 2011-02-06 12:12, terry peng wrote:
>
> > What's the suggested module for perl's threads?
> > I have been using Perl 5.12 under linux.
>
> Stay away from threads. Design and develop in a way that no internal
> resources (but read-only data) are shared.
>

why no threads?
I have been using threads in other language (like Java) for long time, I was thinking it's good.

Thanks.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 11-02-06 07:32 PM, terry peng wrote:
> why no threads?
> I have been using threads in other language (like Java) for long time, I was thinking it's good.
>

It depends on what your OS is. *NIX is designed to dispatch and recover
processes. Windows does not fork well since every Windows processes has
a window, whether it needs it or not.

If you're writing for *NIX, use fork. If you're writing for Windows,
threads.

--
Just my 0.00000002 million dollars worth,
Shawn

Confusion is the first step of understanding.

Programming is as much about organization and communication
as it is about coding.

The secret to great software: Fail early & often.

Eliminate software piracy: use only FLOSS.

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

From: "Dr.Ruud" <rvtol+usenet [at] isolution.nl>
> On 2011-02-06 12:12, terry peng wrote:
>
>> What's the suggested module for perl's threads?
>> I have been using Perl 5.12 under linux.
>
> Stay away from threads. Design and develop in a way that no internal
> resources (but read-only data) are shared.



In a program that uses a GUI the threads might be necessary.

Octavian


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Hi Terry,

On Monday 07 Feb 2011 02:32:49 terry peng wrote:
> Sun, 06 Feb 2011 16:21:58 +0100 =D0=C9=D3=D8=CD=CF =CF=D4 "Dr.Ruud"
<rvtol+usenet [at] isolution.nl>:
> > On 2011-02-06 12:12, terry peng wrote:
> > > What's the suggested module for perl's threads?
> > > I have been using Perl 5.12 under linux.
> >
> > Stay away from threads. Design and develop in a way that no internal
> > resources (but read-only data) are shared.
>
> why no threads?
> I have been using threads in other language (like Java) for long time, I
> was thinking it's good.
>

Well, let me quote the perlbot ( on Freenode's #perl ) factoid:

[quote]

<perlbot> Before you start implementing code using Perl's threads,
please remember that Perl's threads are not like other threads. Please see=

http://perldoc.perl.org/perlthrtut.html to learn more; specifically the "Wh=
at
kind of threads are perl threads?" section. Also see:
http://www.perlmonks.org/index.pl?node_id=3D288022

[/quote]

Read these two resources and be enlightened. Threads do not work too well i=
n
any of the P-languages, and I was told that threads in Python with its
notorious Great-Interpreter-Lock (GIL) suck - not "as bad as Perl" but stil=
l
pretty badly. I haven't tried threads in Lisp yet.

Threads work pretty well in C, though they are extremely tricky to get righ=
t
for non-trivial programs, and they should be pretty OK in .NET too (and aga=
in
=2D quite tricky). Java and C++ may support threads nicely, but from what I=

heard and know developing in them is painful and error-prone in itself. See=

for example:

http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who -says-he-knows-=
c/

("-c" there is "C++").

Some people say threads work very well in languages such as Erlang (where
threads are "green threads" and are also used as a kind of cheap abstractio=
n,
and one can often spawn thousands of them on a machine with much fewer core=
s
or processors), Haskell and other purely functional languages, but I don't=

know about that.

In any case, if you want to do multi-tasking in Perl, you should something=

like either forking and multi-processing or the recommendations here such a=
s
POE, Net::Async, IO::Lambda, Reflex, AnyEvent, etc:

http://perl-begin.org/uses/multitasking/

Some people think that threads should be avoided even in languages where th=
ey
have acceptable performance. See for example:

http://www.faqs.org/docs/artu/ch07s03.html#id2923889

=46urthermore, in regards to parallelism, in the Algorithm Design Manual
( http://www.algorist.com/ ) says something that it is a good idea to split=

the task in such ways that processing every task is self-contained and
requires as little interaction from the other tasks (IIRC).

Personally, I've done some simple multi-threading projects, but can imagine=

that more complex ones will be much more error-prone and hard to get right.

Regards,

Shlomi Fish

=2D-
=2D--------------------------------------------------------- -------
Shlomi Fish http://www.shlomifish.org/
Chuck Norris/etc. Facts - http://www.shlomifish.org/humour/bits/facts/

Chuck Norris can make the statement "This statement is false" a true one.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

Thanks Shlomi.
Your statement is a great guide to perl threads to me.
I'm checking the AnyEvent module which looks wonderful.

Thanks again.


Mon, 7 Feb 2011 12:30:32 +0200 письмо от Shlomi Fish <shlomif [at] iglu.org.il>:

>
> Well, let me quote the perlbot ( on Freenode's #perl ) factoid:
>
> [quote]
>
> <perlbot> Before you start implementing code using Perl's threads,
> please remember that Perl's threads are not like other threads. Please see
> http://perldoc.perl.org/perlthrtut.html to learn more; specifically the "What
> kind of threads are perl threads?" section. Also see:
> http://www.perlmonks.org/index.pl?node_id=288022
>
> [/quote]
>
> Read these two resources and be enlightened. Threads do not work too well in
> any of the P-languages, and I was told that threads in Python with its
> notorious Great-Interpreter-Lock (GIL) suck - not "as bad as Perl" but still
> pretty badly. I haven't tried threads in Lisp yet.
>
> Threads work pretty well in C, though they are extremely tricky to get right
> for non-trivial programs, and they should be pretty OK in .NET too (and again
> - quite tricky). Java and C++ may support threads nicely, but from what I
> heard and know developing in them is painful and error-prone in itself. See
> for example:
>
> http://lbrandy.com/blog/2010/03/never-trust-a-programmer-who -says-he-knows-c/
>
> ("-c" there is "C++").
>
> Some people say threads work very well in languages such as Erlang (where
> threads are "green threads" and are also used as a kind of cheap abstraction,
> and one can often spawn thousands of them on a machine with much fewer cores
> or processors), Haskell and other purely functional languages, but I don't
> know about that.
>
> In any case, if you want to do multi-tasking in Perl, you should something
> like either forking and multi-processing or the recommendations here such as
> POE, Net::Async, IO::Lambda, Reflex, AnyEvent, etc:
>
> http://perl-begin.org/uses/multitasking/
>
> Some people think that threads should be avoided even in languages where they
> have acceptable performance. See for example:
>
> http://www.faqs.org/docs/artu/ch07s03.html#id2923889
>
> Furthermore, in regards to parallelism, in the Algorithm Design Manual
> ( http://www.algorist.com/ ) says something that it is a good idea to split
> the task in such ways that processing every task is self-contained and
> requires as little interaction from the other tasks (IIRC).
>
> Personally, I've done some simple multi-threading projects, but can imagine
> that more complex ones will be much more error-prone and hard to get right.
>


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2011-02-07 11:30, Shlomi Fish wrote:

> Threads work pretty well in C, though they are extremely tricky to get right
> for non-trivial programs

That they work "pretty well" is probably about user experience of some
heavily interactive system. But only if the user accepts crashes and
deadlocks now and then.

The "tricky to get right" misses the point that systems based on threads
have no proper math to back them up.

Threads are like the first little pig, who built a house of straw.

--
Ruud

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On 2011-02-07 07:44, Octavian Rasnita wrote:
> From: "Dr.Ruud" <rvtol+usenet [at] isolution.nl>
>> On 2011-02-06 12:12, terry peng wrote:

>>> What's the suggested module for perl's threads?
>>> I have been using Perl 5.12 under linux.
>>
>> Stay away from threads. Design and develop in a way that no internal
>> resources (but read-only data) are shared.
>
> In a program that uses a GUI the threads might be necessary.

Threads are never necessary. Use light processes that don't know about
each other, and some polling.

--
Ruud

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

On Tuesday 08 Feb 2011 10:05:47 Dr.Ruud wrote:
> On 2011-02-07 11:30, Shlomi Fish wrote:
> > Threads work pretty well in C, though they are extremely tricky to get
> > right for non-trivial programs
>
> That they work "pretty well" is probably about user experience of some
> heavily interactive system. But only if the user accepts crashes and
> deadlocks now and then.
>

What I meant by work pretty well, is that they are lightweight, cheap, perform
well, and can often increase performance.

> The "tricky to get right" misses the point that systems based on threads
> have no proper math to back them up.
>

[citation needed]. I believe I've seen some mathematical models of threads,
and you can prove the lack of deadlocks/livelocks/etc. in a model of the
system mathematically. But like you said, if one is going to implement
cooperative threads that work using the same resources, he or she is in for a
lot of trouble.

> Threads are like the first little pig, who built a house of straw.

Possibly, but they are still implemented and perform in C much better than
they do in Perl or similar languages.

In any case, I've done some non-cooperative multi-tasking (or maybe split-
tasking) where I assign different independent tasks to different threads (like
solving a range of Solitaire deals by each thread solving different deals in a
round-robin fashion) and it indeed increased the overall performance of the
range solver on my Pentium 4 2.4GHz machine with two hyperthreads and on my
Dual Core x86-64 laptop. I later on implemented a forking range solver, and in
subsequent benchmarks it did not perform as well (the difference was not very
large, but I'm not willing to throw it away either due to what I said here:
http://en.wikibooks.org/wiki/Optimizing_Code_for_Speed/Facto r_Optimizations
)

On a discussion I raised on Linux-IL (the Israeli Linux mailing list), I was
told that in order to truly benefit from multiple-cores, one has to make sure
the individual tasks execute as closely as possible to one another, which I
believe implies either multiple threads or alternatively a program where you
fork without calling exec/EXECVE later and just continue execution.

Regards,

Shlomi Fish

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
Understand what Open Source is - http://shlom.in/oss-fs

Chuck Norris can make the statement "This statement is false" a true one.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

--0016364d29091b3df2049bd917d3
Content-Type: text/plain; charset=UTF-8

Just adding a little to this discussion then. :-)

Threads regardless of the language are meant to do multiple things in
parallel. For instance I'm at the moment working on a tool that extracts
vast amounts of data from a web service as the calls to that service are
pretty much independent and the data on my side is first stored in a
database before further processing (using separate tables for each of the
calls) there is very little point in doing these actions sequential.
After all both the database and the webservice are fully capable of handling
hundreds or even thousands of requests at a time without fail so why not run
things in parallel?
I found that even with a minimal amount of data I can speed up the process a
lot by simply creating an object that deals with the database and using this
as a base class to build the various API calling objects on. Each object
then is fully self contained deals with the retrieval of its own data
massaging that in a format that fits in its own tables and uses its parents
code to deal with the database insertion.

It depends on your intended usage of threads, if you are thinking along the
lines of a multi threaded process that operates on shared data, where the
threads are constantly sharing outcomes and using the results other threads
have produced to continue their processing so they can supply the yet other
threads with data... think again. Though of course possible in Perl it is
also an very very complex thing to do and the performance will simply not be
there at least not when comparing to other solutions.
But as said for simple parallel and independent actions using threads in
Perl is not such a bad idea.

The idea that threads are always bad regardless of programming language or
are bad i many languages is simply not true. Threads certainly have a place
in programming and in many if not all programing languages. With the many
core processors of to day and tomorrow threads will become a much more
important and useful tool in the programmers arsenal.
The main thing is that for a very long time programmers have had very little
real use for threads as most computers had a single core with 1 or in later
years 2 threads per core. That simple fact has convinced many programmers
that threads are not all that they are hyped up to be. After all you are
still waiting on the hardware to become available and if you run more then 2
threads at a time the time the processor needs for switching between threads
removes many of the performance benefits threads could offer.
Now though that one sees processors that can handle up to 32 threads and
soon even 128 threads at a time multiple threads will prove to be a lot more
useful then most programmers have given them credit for. As the processor
does not need to do all the switching between threads and can simply
continue working on the thread without interruption the additional speed
that literally processing in parallel can bring will be very noticeable. The
main problem that developers will find in terms of raw performance is the
I/O of these systems which will not be able to provide data fast enough to
keep the threads from having to wait for data to become available.
Of course the old monster of how do you deal with multiple threads that do
need to exchange data will be back on the table and certainly if you are
doing funky stuff such as AI where many different inputs are processed at
the same time and all can and should to an extend influence each other then
you will spend many nights waking up screaming in the middle of the night as
you got tangled in the multiple thread nightmare again.

As for Perl the threads implementation on it offers is not to bad and quite
convenient for the simpler parallel run scenario. For serious performance in
the multi threaded arena Perl is simply not the tool for the job, it is as
simple as that.
But any developer that tells you that threads are not worth the trouble they
cause or anything along those lines is clearly an experienced programmer
who unfortunately has not realized yet that the computer world has
changed incredibly over the past few years.



2011/2/9 Shlomi Fish <shlomif [at] iglu.org.il>

> On Tuesday 08 Feb 2011 10:05:47 Dr.Ruud wrote:
> > On 2011-02-07 11:30, Shlomi Fish wrote:
> > > Threads work pretty well in C, though they are extremely tricky to get
> > > right for non-trivial programs
> >
> > That they work "pretty well" is probably about user experience of some
> > heavily interactive system. But only if the user accepts crashes and
> > deadlocks now and then.
> >
>
> What I meant by work pretty well, is that they are lightweight, cheap,
> perform
> well, and can often increase performance.
>
> > The "tricky to get right" misses the point that systems based on threads
> > have no proper math to back them up.
> >
>
> [citation needed]. I believe I've seen some mathematical models of threads,
> and you can prove the lack of deadlocks/livelocks/etc. in a model of the
> system mathematically. But like you said, if one is going to implement
> cooperative threads that work using the same resources, he or she is in for
> a
> lot of trouble.
>
> > Threads are like the first little pig, who built a house of straw.
>
> Possibly, but they are still implemented and perform in C much better than
> they do in Perl or similar languages.
>
> In any case, I've done some non-cooperative multi-tasking (or maybe split-
> tasking) where I assign different independent tasks to different threads
> (like
> solving a range of Solitaire deals by each thread solving different deals
> in a
> round-robin fashion) and it indeed increased the overall performance of the
> range solver on my Pentium 4 2.4GHz machine with two hyperthreads and on my
> Dual Core x86-64 laptop. I later on implemented a forking range solver, and
> in
> subsequent benchmarks it did not perform as well (the difference was not
> very
> large, but I'm not willing to throw it away either due to what I said here:
> http://en.wikibooks.org/wiki/Optimizing_Code_for_Speed/Facto r_Optimizations
> )
>
> On a discussion I raised on Linux-IL (the Israeli Linux mailing list), I
> was
> told that in order to truly benefit from multiple-cores, one has to make
> sure
> the individual tasks execute as closely as possible to one another, which I
> believe implies either multiple threads or alternatively a program where
> you
> fork without calling exec/EXECVE later and just continue execution.
>
> Regards,
>
> Shlomi Fish
>
> --
> ------------------------------------------------------------ -----
> Shlomi Fish http://www.shlomifish.org/
> Understand what Open Source is - http://shlom.in/oss-fs
>
> Chuck Norris can make the statement "This statement is false" a true one.
>
> Please reply to list if it's a mailing list post - http://shlom.in/reply .
>
> --
> To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
> For additional commands, e-mail: beginners-help [at] perl.org
> http://learn.perl.org/
>
>
>

--0016364d29091b3df2049bd917d3--

On 2011-02-09 14:03, Rob Coops wrote:

> But any developer that tells you that threads are not worth the
> trouble they cause or anything along those lines is clearly an
> experienced programmer who unfortunately has not realized yet
> that the computer world has changed incredibly over the past
> few years.

Rob, from your reply I understand that you didn't pick up that it is
about the forking/threading difference. (So it is not about doing things
in parallel or not, as you seem to think.)

This discussion is about why threads are (mostly) wrong, and forks are
(basically) right, when it comes to parallelization.

--
Ruud


--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/

--90e6ba53a7ced02050049bfe099c
Content-Type: text/plain; charset=UTF-8

I have to agree I missed things a bit there :-(

forks are simply a better way of dealing with threads then the default perl
ithreads, the benefits forks offer goes far beyond the minimal drawbacks. By
now the notes about modules that still insist on using threads rather then
forks will for most users just be informative as the better solution has
been available for long enough for most module maintainers to switch.



On Thu, Feb 10, 2011 at 11:05 AM, Dr.Ruud <rvtol+usenet [at] isolution.nl> wrote:

> On 2011-02-09 14:03, Rob Coops wrote:
>
> > But any developer that tells you that threads are not worth the
> > trouble they cause or anything along those lines is clearly an
> > experienced programmer who unfortunately has not realized yet
> > that the computer world has changed incredibly over the past
> > few years.
>
> Rob, from your reply I understand that you didn't pick up that it is about
> the forking/threading difference. (So it is not about doing things in
> parallel or not, as you seem to think.)
>
> This discussion is about why threads are (mostly) wrong, and forks are
> (basically) right, when it comes to parallelization.
>
> --
> Ruud
>
>
> --
> To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
> For additional commands, e-mail: beginners-help [at] perl.org
> http://learn.perl.org/
>
>
>

--90e6ba53a7ced02050049bfe099c--

Hi Rob,

well, if we are already discussing threads in general, and not in Perl in
particular, I might as well contribute to the discussion.

On Wednesday 09 Feb 2011 15:03:04 Rob Coops wrote:
> Just adding a little to this discussion then. :-)
>
> Threads regardless of the language are meant to do multiple things in
> parallel. For instance I'm at the moment working on a tool that extracts
> vast amounts of data from a web service as the calls to that service are
> pretty much independent and the data on my side is first stored in a
> database before further processing (using separate tables for each of the
> calls) there is very little point in doing these actions sequential.
> After all both the database and the webservice are fully capable of
> handling hundreds or even thousands of requests at a time without fail so
> why not run things in parallel?

Well, there are some downsides like overloading the network, CPU, etc. and it
may even get you blocked from the web-service if it's not under your control.
Parallelising like that won't always increase performance like that.

> I found that even with a minimal amount of data I can speed up the process
> a lot by simply creating an object that deals with the database and using
> this as a base class to build the various API calling objects on. Each
> object then is fully self contained deals with the retrieval of its own
> data massaging that in a format that fits in its own tables and uses its
> parents code to deal with the database insertion.
>
> It depends on your intended usage of threads, if you are thinking along the
> lines of a multi threaded process that operates on shared data, where the
> threads are constantly sharing outcomes and using the results other threads
> have produced to continue their processing so they can supply the yet other
> threads with data... think again. Though of course possible in Perl it is
> also an very very complex thing to do and the performance will simply not
> be there at least not when comparing to other solutions.
> But as said for simple parallel and independent actions using threads in
> Perl is not such a bad idea.

Well, what you are describing (which I think is called cooperative multi-
tasking) is tricky to do right with complex software and a mess to debug if
you have bugs (which you'll likely have) or if you try to extend it a little.
What "The Algorithm Design Manual" (a very good book) recommends to do is to
have non-cooperative mult-tasking where each task works on a different set of
results with as little cooperation as possible (possibly in a round robin
fashion).

>
> The idea that threads are always bad regardless of programming language or
> are bad i many languages is simply not true. Threads certainly have a place
> in programming and in many if not all programing languages. With the many
> core processors of to day and tomorrow threads will become a much more
> important and useful tool in the programmers arsenal.
> The main thing is that for a very long time programmers have had very
> little real use for threads as most computers had a single core with 1 or
> in later years 2 threads per core. That simple fact has convinced many
> programmers that threads are not all that they are hyped up to be. After
> all you are still waiting on the hardware to become available and if you
> run more then 2 threads at a time the time the processor needs for
> switching between threads removes many of the performance benefits threads
> could offer.

Well, from what I understood threads were also useful in multi-processor
machines (including many non-clustered super computers), but in that case,
processes are often a good subtitute.

> Now though that one sees processors that can handle up to 32 threads and
> soon even 128 threads at a time multiple threads will prove to be a lot
> more useful then most programmers have given them credit for. As the
> processor does not need to do all the switching between threads and can
> simply continue working on the thread without interruption the additional
> speed that literally processing in parallel can bring will be very
> noticeable.

Agreed. Though it's possible that forked processes that don't EXECVE (e.g:
perldoc -f exec) will still also be a good subtitue.

> The main problem that developers will find in terms of raw
> performance is the I/O of these systems which will not be able to provide
> data fast enough to keep the threads from having to wait for data to
> become available. Of course the old monster of how do you deal with
> multiple threads that do need to exchange data will be back on the table
> and certainly if you are doing funky stuff such as AI where many different
> inputs are processed at the same time and all can and should to an extend
> influence each other then you will spend many nights waking up screaming
> in the middle of the night as you got tangled in the multiple thread
> nightmare again.

Well, this "funky stuff such as AI" is not limited to AI (not that you said it
is), and I've witnessed or read about several complex C or C++ servers (either
UNIX/POSIX or Win32 or both) trying to be implemented using threads and lots
and lots of locks, which often fail.

Regarding AI, I only have some experience (and not a very formal one) in game
AI, which normally involves building graphs (often with directed cycles) of
positions with calculating moves between them, pruning positions and
evaluating them. There are many popular graph traversal algorithms for that,
and normally (if we take a typical game such as Chess or a card Solitaire
variant) you'll have a hard time holding all the states in memory and it will
take some time to traverse them all. Manipulating this graph using several
scans in several threads will be a pretty hard task.

For Freecell Solver ( http://fc-solve.berlios.de/ ) which is currently written
in C for performance reasons, I've implemented a system of "instances" which
manage the entire collection of positions, which have several "hard threads"
which were supposed to be an individual POSIX or Win32 threads and are aimed
at reducing the amount of locking, which in turn have many "soft threads"
which is a fancy name for an individual scan. In turn, what I do is switch-
task between the various soft threads (which can be specified by the user)
until I reach the final state.

Now, I still have not implemented the cooperative multi-threading and the
scheme I figured out to implement it with locks
(see http://groups.yahoo.com/group/fc-solve-discuss/message/377 ) based on an
older version of the code, seems incredibly hard to get right, and very
complex. What I did instead was implement a multi-threaded program that has a
different instance (i.e: a separate collection of states) in every thread and
it solves a range of Freecell deals in a round-robin fashion. This does not
help with a single deal, naturally, which can still be very time consuming,
especially if it cannot be solved (which is the case for many Freecell deals
with fewer than 4 freecells in the waste.).

>
> As for Perl the threads implementation on it offers is not to bad and quite
> convenient for the simpler parallel run scenario. For serious performance
> in the multi threaded arena Perl is simply not the tool for the job, it is
> as simple as that.

Maybe it's true. Of course, Larry Wall commented here -

http://perl.org.il/presentations/larry-wall-present-continuo us-future-
perfect/transcript.html

that:

[quote]
"If I wanted it fast, I'd write it in C" - That's almost a direct quote from
the original awk page.
[/quote]

He said it in the context of several "Irrationalities" in other languages, so
I assume he intended to mean that even the implementation of a high level
language (HLL) should perform fast enough to be usable. On the other hand, my
friend once said "How can you have a programming language that will be good
for anything if you can't even have such a screwdriver?", and perl 5
algorithmic code is an order of magnitude or two slower than C's one, but you
don't normally notice it because either you stick to routines written in C
(regular expressions, XS code, etc.) or because modern computers are so fast
that it doesn't seem too significant, or because you're doing a lot of I/O or
other non-CPU-bound operations.

Nevertheless, you are right that Perl is not the right language for everything
(or for everyone), and neither is likely any other language, from many
reasons.

> But any developer that tells you that threads are not worth the trouble
> they cause or anything along those lines is clearly an experienced
> programmer who unfortunately has not realized yet that the computer world
> has changed incredibly over the past few years.
>

Well, it depends what you want to do. If you have a 4-core machine and without
threads your task will finish in 1 minute, then implementing threads to make
your task 4 times faster *in the best case* [Amdahl], then it is not worth it.
On the other hand if you're going to deploy a simulation that takes days on
end to solve and you have a very high performance machine with many processors
and cores on it, then it's a good idea to look into parallelisation. And if
you're writing or maintaining an OS for servers or a service program, that is
expected to be deployed on very powered machines, then you likely would want
to make it parallelised too.

There's always the case of cost vs. benefit.

Regards,

Shlomi Fish

[Amdahl] - http://en.wikipedia.org/wiki/Amdahl%27s_law

--
------------------------------------------------------------ -----
Shlomi Fish http://www.shlomifish.org/
Why I Love Perl - http://shlom.in/joy-of-perl

Chuck Norris can make the statement "This statement is false" a true one.

Please reply to list if it's a mailing list post - http://shlom.in/reply .

--
To unsubscribe, e-mail: beginners-unsubscribe [at] perl.org
For additional commands, e-mail: beginners-help [at] perl.org
http://learn.perl.org/