[32807] in Perl-Users-Digest

home help back first fref pref prev next nref lref last post

Perl-Users Digest, Issue: 4071 Volume: 11

daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Nov 5 16:14:35 2013

Date: Tue, 5 Nov 2013 13:14:10 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)

Perl-Users Digest           Tue, 5 Nov 2013     Volume: 11 Number: 4071

Today's topics:
        Several Perl Questions - Nov. 5, 2013 <edgrsprj@ix.netcom.com>
    Re: Several Perl Questions - Nov. 5, 2013 <news@lawshouse.org>
    Re: Several Perl Questions - Nov. 5, 2013 <cwilbur@chromatico.net>
    Re: Several Perl Questions - Nov. 5, 2013 <news@lawshouse.org>
    Re: Several Perl Questions - Nov. 5, 2013 <ben@morrow.me.uk>
    Re: Several Perl Questions - Nov. 5, 2013 <ben@morrow.me.uk>
    Re: Several Perl Questions - Nov. 5, 2013 <news@lawshouse.org>
    Re: Several Perl Questions - Nov. 5, 2013 <hjp-usenet3@hjp.at>
    Re: Several Perl Questions - Nov. 5, 2013 <jblack@nospam.com>
    Re: Several Perl Questions - Nov. 5, 2013 <hjp-usenet3@hjp.at>
    Re: Several Perl Questions - Nov. 5, 2013 <hjp-usenet3@hjp.at>
    Re: Several Perl Questions - Nov. 5, 2013 <hjp-usenet3@hjp.at>
    Re: Several Perl Questions - Nov. 5, 2013 (Tim McDaniel)
    Re: use MCE; <rweikusat@mobileactivedefense.com>
    Re: use MCE; <gamo@telecable.es>
        Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)

----------------------------------------------------------------------

Date: Tue, 5 Nov 2013 00:16:15 -0600
From: "E.D.G." <edgrsprj@ix.netcom.com>
Subject: Several Perl Questions - Nov. 5, 2013
Message-Id: <oI2dnS9mDsW7EOXPnZ2dnUVZ_vadnZ2d@earthlink.com>

Posted by E.D.G. on November 5, 2013

       ActiveState Perl 5.10 is the primary version I am using because a 
variety of specialized modules are in use.  Some might not work with newer 
versions or Perl.

       There are a number of computer programmers who are involved with what 
is being discussed here.


Question 1

       Are there modules for any Perl versions that enable Perl to do faster 
calculations?

       At the present time the standard math and "use Math::Trig" options 
are being used.  And I am running into problems with how long it can take 
Perl to do large numbers of relatively simple calculations.

       If there isn't a faster way to do things then the plan is to have my 
Perl programs call external programs such as a Basic or Fortran programs, 
have them do the calculations and then store the results in a file that the 
Perl program will read.


Question 2

       Can a 64 bit Perl version be run on a computer that is using a 32 bit 
Windows operating system if the computer has a 64 bit processor?

       My guess is that this is not possible.  And I am aware that 32 bit 
Windows can be upgraded to a 64 bit version.


Question 3

       For Perl CGI programs, ones running on an Internet server,

       What is the best way to go with graphics so that png files can be 
generated by a CGI program and stored on the Web site for display.

       I have been using Gnuplot with Perl to generate png charts on my PC. 
And I understand that Gnuplot will run on an Internet Server.  But I don't 
see where it is available on my own server.  There is probably a way to get 
it to run in spite of that.  But I asked about that in the Gnuplot Newsgroup 
and did not get an answer other than a statement that it is possible.



------------------------------

Date: Tue, 05 Nov 2013 08:03:11 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <2a-dnXgtLfGiO-XPnZ2dnUVZ8vWdnZ2d@giganews.com>

On 05/11/13 06:16, E.D.G. wrote:
>        There are a number of computer programmers who are involved with
> what is being discussed here.

Are they experienced Perl users? Have you asked them these questions? 
What was their response?

>        Are there modules for any Perl versions that enable Perl to do
> faster calculations?

I looked at your code a while back; start by completely re-writing it.

>        Can a 64 bit Perl version be run on a computer that is using a 32
> bit Windows operating system if the computer has a 64 bit processor?

This is not a Perl question.  But the answer is "no": if a computer runs 
a 32-bit operating system it's a 32-bit computer, irrespective of the 
processor architecture.

>        I have been using Gnuplot with Perl to generate png charts on my
> PC. And I understand that Gnuplot will run on an Internet Server.  But I
> don't see where it is available on my own server.

This isn't a Perl question; it's to do with server setup.  Nobody here 
knows how your server is set up.

-- 

Henry Law            Manchester, England


------------------------------

Date: Tue, 05 Nov 2013 09:53:55 -0500
From: Charlton Wilbur <cwilbur@chromatico.net>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <874n7q7vcs.fsf@new.chromatico.net>

>>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:

    EDG>       Are there modules for any Perl versions that enable Perl
    EDG> to do faster calculations?

No.  Perl does calculations as quickly as it can.  

    EDG>       At the present time the standard math and "use
    EDG> Math::Trig" options are being used.  And I am running into
    EDG> problems with how long it can take Perl to do large numbers of
    EDG> relatively simple calculations.

    EDG>       If there isn't a faster way to do things then the plan is
    EDG> to have my Perl programs call external programs such as a Basic
    EDG> or Fortran programs, have them do the calculations and then
    EDG> store the results in a file that the Perl program will read.

This is almost certainly ass-backwards; even without seeing your code,
I'd wager that your problem is not the speed of individual calculations
but a poor choice of algorithm and a wasteful use of resources.

    EDG>       What is the best way to go with graphics so that png
    EDG> files can be generated by a CGI program and stored on the Web
    EDG> site for display.

"Best" depends on what constraints you have and what you consider most
important.  The best way for you to go with graphics, is, in my
professional opinion, to hire a competent programmer with experience
building web software and leave it to him or her.  

Charlton



-- 
Charlton Wilbur
cwilbur@chromatico.net


------------------------------

Date: Tue, 05 Nov 2013 15:15:15 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <Y_2dnZo4L4celuTPnZ2dnUVZ8kadnZ2d@giganews.com>

On 05/11/13 14:53, Charlton Wilbur wrote:
> The best way for you to go with graphics, is, in my
> professional opinion, to hire a competent programmer with experience
> building web software and leave it to him or her.

Quite so; but quoth EDG in his original post ...
> There are a number of computer programmers who are involved with what is being discussed here.

-- 

Henry Law            Manchester, England


------------------------------

Date: Tue, 5 Nov 2013 15:05:26 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <m2enka-10e.ln1@anubis.morrow.me.uk>


Quoth Henry Law <news@lawshouse.org>:
> On 05/11/13 06:16, E.D.G. wrote:
> 
> >        Can a 64 bit Perl version be run on a computer that is using a 32
> > bit Windows operating system if the computer has a 64 bit processor?
> 
> This is not a Perl question.  But the answer is "no": if a computer runs 
> a 32-bit operating system it's a 32-bit computer, irrespective of the 
> processor architecture.

That's not actually true, though it is true that 32bit Windows won't run
64bit executables. 16bit Windows used to run 32bit executables just
fine, and Mac OS X for quite a long time had a 32bit kernel that was
capable of running 64bit user processes.

Ben



------------------------------

Date: Tue, 5 Nov 2013 17:42:30 +0000
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <69nnka-tkf.ln1@anubis.morrow.me.uk>


Quoth Charlton Wilbur <cwilbur@chromatico.net>:
> >>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:
> 
>     EDG>       Are there modules for any Perl versions that enable Perl
>     EDG> to do faster calculations?
[reordered...]
>     EDG>       At the present time the standard math and "use
>     EDG> Math::Trig" options are being used.  And I am running into
>     EDG> problems with how long it can take Perl to do large numbers of
>     EDG> relatively simple calculations.
> 
> No.  Perl does calculations as quickly as it can.  

This is not true. Perl's core numerical ops are written to preserve
accuracy rather than for speed, and any significant calculation will
have to run round the Perl op loop many times, which is also rather
slow. Math::Trig (and Math::Complex) are pure-Perl OO-based
implementations; I would expect these to be even slower.

C-based math is always going to be faster, especially when you're doing
a lot of it. There are a lot of Perl bindings to existing fast math
libraries; see for instance PDL, Math::GSL, Math::Cephes, Math::Pari,
Math::GMP*, and so on.

Ben



------------------------------

Date: Tue, 05 Nov 2013 18:43:08 +0000
From: Henry Law <news@lawshouse.org>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <cLCdnah5cpChoeTPnZ2dnUVZ7sednZ2d@giganews.com>

On 05/11/13 06:16, E.D.G. wrote:
> Are there modules for any Perl versions that enable Perl to do faster
> calculations?

The version of your code that I looked at makes repeated calls to "pi", 
like this (for example):

> $sunlatrads = $sunlat*2*pi/360;
> $sunlonrads = $sunlon*2*pi/360;
> $moonlatrads = $moonlat*2*pi/360;
> $moonlonrads = $moonlon*2*pi/360;

Pi is evaluated (presumably each time) within Math::Complex using the 
atan() function.  As Ben points out, these functions are coded in pure 
Perl and will be much slower than libraries coded in C with Perl 
bindings.  You _could_ start there, assuming you know how.

Other than pi (and asin() once and atan() twice) you're not calling any 
module code, unless you've radically changed the code from the version 
I'm looking at; so swapping to some other module isn't going to help.

(This has to be by far the worst Perl code I've ever seen in my life).

-- 

Henry Law            Manchester, England


------------------------------

Date: Tue, 5 Nov 2013 21:02:41 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <slrnl7ijn1.fh7.hjp-usenet3@hrunkner.hjp.at>

On 2013-11-05 17:42, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Charlton Wilbur <cwilbur@chromatico.net>:
>> >>>>> "EDG" == E D G <edgrsprj@ix.netcom.com> writes:
>> 
>>     EDG>       Are there modules for any Perl versions that enable Perl
>>     EDG> to do faster calculations?
> [reordered...]
>>     EDG>       At the present time the standard math and "use
>>     EDG> Math::Trig" options are being used.  And I am running into
>>     EDG> problems with how long it can take Perl to do large numbers of
>>     EDG> relatively simple calculations.
>> 
>> No.  Perl does calculations as quickly as it can.  
>
> This is not true. Perl's core numerical ops are written to preserve
> accuracy rather than for speed,

Which is almost certainly irrelevant. The numerical op itself is a
single CPU (FPU) instruction and that's always done in extended
precision on x86. (Unless the compiler uses SSE instructions or
something similar, but AIUI that's only worthwhile if you are using many
instructions).

> and any significant calculation will have to run round the Perl op
> loop many times, which is also rather slow.

Much, much slower than any math operation built into the CPU. The perl
interpreter overhead is rather large and unfortunately there seems to be
no one who works on speeding it up.


> Math::Trig (and Math::Complex) are pure-Perl OO-based
> implementations; I would expect these to be even slower.

What's object oriented about Math::Trig? That seems to me a rather
simple collection of convenience functions.


> C-based math is always going to be faster, especially when you're doing
> a lot of it. There are a lot of Perl bindings to existing fast math
> libraries; see for instance PDL, Math::GSL, Math::Cephes, Math::Pari,
> Math::GMP*, and so on.

Yes.

	hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

Date: Tue, 5 Nov 2013 14:02:51 -0600
From: John Black <jblack@nospam.com>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <MPG.2ce30ae58e302bb7989799@news.eternal-september.org>

In article <cLCdnah5cpChoeTPnZ2dnUVZ7sednZ2d@giganews.com>, news@lawshouse.org says...
> (This has to be by far the worst Perl code I've ever seen in my life).

That's a bold statement...  :-)

John Black


------------------------------

Date: Tue, 5 Nov 2013 21:04:08 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <slrnl7ijpo.fh7.hjp-usenet3@hrunkner.hjp.at>

On 2013-11-05 15:15, Henry Law <news@lawshouse.org> wrote:
> On 05/11/13 14:53, Charlton Wilbur wrote:
>> The best way for you to go with graphics, is, in my
>> professional opinion, to hire a competent programmer with experience
>> building web software and leave it to him or her.
>
> Quite so; but quoth EDG in his original post ...
>> There are a number of computer programmers who are involved with what
>> is being discussed here.

We've all known EDG's claims for years. 

	hp


-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

Date: Tue, 5 Nov 2013 21:31:32 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <slrnl7ild4.fh7.hjp-usenet3@hrunkner.hjp.at>

On 2013-11-05 15:05, Ben Morrow <ben@morrow.me.uk> wrote:
> Quoth Henry Law <news@lawshouse.org>:
>> On 05/11/13 06:16, E.D.G. wrote:
>> >        Can a 64 bit Perl version be run on a computer that is using a 32
>> > bit Windows operating system if the computer has a 64 bit processor?
>> 
>> This is not a Perl question.  But the answer is "no": if a computer runs 
>> a 32-bit operating system it's a 32-bit computer, irrespective of the 
>> processor architecture.
>
> That's not actually true, though it is true that 32bit Windows won't run
> 64bit executables. 16bit Windows used to run 32bit executables just
> fine, and Mac OS X for quite a long time had a 32bit kernel that was
> capable of running 64bit user processes.

There is always the question what "16 bit", "32 bit" and "64 bit" means.
On some architectures, there were just additional instructions to access
the longer registers. On others (like x86) there is no binary
compatibility: You could compile a program to access EAX in 16-bit mode
or in 32-bit mode, but the machine code would be different, and I think
the same is true for 32/64bit x86 code. On MS-DOS that mattered little
because there was no hardware protection anyway, so any executable could
just switch to 32-bit protected mode (and back into real mode[1] before
exit), but any real OS (starting with Xenix-286 or protected mode
Windows) needed to be able to set up 32-bit segments to run "real" 32
bit executables, but without that it could of course run programs which
just accessed the 32 bit integer registers (but only for computation,
not as pointers). I'd hesitate to call Win95 with the Win32 subsystem a
"16 bit OS": While large parts of it were (AIUI) still running in 16 bit
protected mode, some parts (especially those dealing with 32 bit
processes) were running in 32 bit mode (the segmented x86 architecture
made stuff like that almost natural). I don't know about MacOS, but I
guess you are talking about x86 here, too (AFAIK, Apple never sold
machines with 64 bit POWER chips).

	hp

[1] Although the original 386 needed a hardware reset for that

PS: I'm currently running a 64bit Linux kernel beneath a 32bit Linux
    userland. Debian is supposedly multi-architecture capable, so I
    should be able to do a gradual upgrade to a 64 bit userland, too.

-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

Date: Tue, 5 Nov 2013 21:51:32 +0100
From: "Peter J. Holzer" <hjp-usenet3@hjp.at>
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <slrnl7imik.fh7.hjp-usenet3@hrunkner.hjp.at>

On 2013-11-05 18:43, Henry Law <news@lawshouse.org> wrote:
> On 05/11/13 06:16, E.D.G. wrote:
>> Are there modules for any Perl versions that enable Perl to do faster
>> calculations?
>
> The version of your code that I looked at makes repeated calls to "pi", 
> like this (for example):
>
>> $sunlatrads = $sunlat*2*pi/360;
>> $sunlonrads = $sunlon*2*pi/360;
>> $moonlatrads = $moonlat*2*pi/360;
>> $moonlonrads = $moonlon*2*pi/360;
>
> Pi is evaluated (presumably each time) within Math::Complex using the 
> atan() function.

No, 

    use Math::Trig;
    my $pi = pi;

compiles to:

    use Math::Trig;
    my $pi = 3.1415926535897931;

While technically this is a function call, the compiler is smart enough
to notice that it evaluates to a constant value and can be inlined.

(However, the compiler won't optimize “$sunlatrads = $sunlat*2*pi/360â€
to “$sunlatrads = $sunlat*(2*pi/360)â€: You have to set the parentheses
explicitely if you want that (and it will save you two ops at runtime).

	hp

-- 
   _  | Peter J. Holzer    | Fluch der elektronischen Textverarbeitung:
|_|_) |                    | Man feilt solange an seinen Text um, bis
| |   | hjp@hjp.at         | die Satzbestandteile des Satzes nicht mehr
__/   | http://www.hjp.at/ | zusammenpaßt. -- Ralph Babel


------------------------------

Date: Tue, 5 Nov 2013 20:56:42 +0000 (UTC)
From: tmcd@panix.com (Tim McDaniel)
Subject: Re: Several Perl Questions - Nov. 5, 2013
Message-Id: <l5bm2a$2jj$1@reader1.panix.com>

In article <cLCdnah5cpChoeTPnZ2dnUVZ7sednZ2d@giganews.com>,
Henry Law  <news@lawshouse.org> wrote:
>Pi is evaluated (presumably each time) within Math::Complex using the 
>atan() function.

*boggle* They weren't willing to cache *pi*?  Were they afraid it
would change at runtime?

"Sir, the pi meter is going crazy!  Triangles are up to 192 degrees!"
"Cap'n, the dihedral crystals canna take it any more!"

-- 
Tim McDaniel, tmcd@panix.com


------------------------------

Date: Mon, 04 Nov 2013 12:37:18 +0000
From: Rainer Weikusat <rweikusat@mobileactivedefense.com>
Subject: Re: use MCE;
Message-Id: <87zjpkqr5t.fsf@sable.mobileactivedefense.com>

gamo <gamo@telecable.es> writes:

[...]

> Are there somebody wich could guide me in the parallelization of
> something like
>
>
> $var = 1;
> $foo = 2;
> $bar = 3;
>
> while (1) {
>
> 	$r = rand();
>
> 	$result = $r * ($var+$foo+$bar);
>
> 	$anothervar = sqrt($var+$foo+$bar);
>
> 	last if ($result < $anothervar+0.001 && $result > $anothervar-0.001);
>
> }
>
> print "$r -> $result\n";
>
> exit ;

It is somewhat unclear what is supposed to be parallelized how here, eg,
are the $(bar|foo|var) really compile-time constant and if they're not,
how often to they change? And what's the point of this algorithm,
anyway? From the above, it follows that 

$r == sqrt($var + $foo + bar) / ($var + $foo + $bar)

means

$result == $another_var

in general and that the solution for your specific case is

[rw@sable]~#perl -e 'print sqrt(6)/6, "\n";'
0.408248290463863




------------------------------

Date: Mon, 04 Nov 2013 14:37:00 +0100
From: gamo <gamo@telecable.es>
Subject: Re: use MCE;
Message-Id: <l587u9$kmq$1@speranza.aioe.org>

El 04/11/13 13:37, Rainer Weikusat escribió:
> gamo <gamo@telecable.es> writes:
>
> [...]
>
>> Are there somebody wich could guide me in the parallelization of
>> something like
>>
>>
>> $var = 1;
>> $foo = 2;
>> $bar = 3;
>>
>> while (1) {
>>
>> 	$r = rand();
>>
>> 	$result = $r * ($var+$foo+$bar);
>>
>> 	$anothervar = sqrt($var+$foo+$bar);
>>
>> 	last if ($result < $anothervar+0.001 && $result > $anothervar-0.001);
>>
>> }
>>
>> print "$r -> $result\n";
>>
>> exit ;
>
> It is somewhat unclear what is supposed to be parallelized how here, eg,
> are the $(bar|foo|var) really compile-time constant and if they're not,
> how often to they change? And what's the point of this algorithm,
> anyway? From the above, it follows that
>
> $r == sqrt($var + $foo + bar) / ($var + $foo + $bar)
>
> means
>
> $result == $another_var
>
> in general and that the solution for your specific case is
>
> [rw@sable]~#perl -e 'print sqrt(6)/6, "\n";'
> 0.408248290463863
>
>

It's only an example. Suppose I have common variables ($var, $foo, $bar) 
to be used in an algorithm. The algorithm takes these and a
random input ($r), and knows when to stop its calculations (comparison 
with $anothervar). Then it has a result ($result).

What I want to do is parallelize the algorithm (could be a sub), and
get the best $r and/or $result. This gather of information, and the need
to share input vars is difficult. AFAIK the most independent the
algorithm is, the easyest parallelization could be done.

I tought in threads, too, but there are limitations: a random is not
thread-safe or the creation of each thread need to be by hand via
create, as is by hand the finish of a thread. Last but not least after
all I want to reach better performance, in speed or precision.

Thanks for your help






------------------------------

Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin) 
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>


Administrivia:

To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.

Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests. 

#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.


------------------------------
End of Perl-Users Digest V11 Issue 4071
***************************************


home help back first fref pref prev next nref lref last post