Re: Several Topics - Nov. 19, 2013
El 19/11/13 23:43, glen herrmannsfeldt escribió: And, importantly, the code runs fairly slow. Some years ago, I was working with simple PERL programs that could process data at 1 megabyte per minute. Rewriting in C, I got one megabyte per second. It is not too unusual to run 10 times slower, but 60 was rediculous. -- glen Can you provide more information on the topic? Perl version, method to read/write, etc. Thanks -- https://mail.python.org/mailman/listinfo/python-list
Re: Several Topics - Nov. 19, 2013
On Wed, Nov 20, 2013 at 9:43 AM, glen herrmannsfeldt wrote: > I also used to use a BASIC system that allowed you to stop a program > (or the program stopped itself), change statements (fix bugs) and > continue on from where it stopped. Not all can do that, but pretty > much compilers never do. Ditto, both in GW-BASIC and Q-BASIC, but in each case there were some fairly strict rules about what could be edited. Changing anything to do with control flow quickly got you a "Can't continue" error. And of course, assembly language with DEBUG.EXE lets you do basically anything... rewrite memory (code or data, there's no difference), change the instruction pointer (so execution resumes somewhere else), change other registers, etc, etc. Most languages don't give you quite that much flexibility, because it's really REALLY easy to mess things up and confuse yourself completely. Python kinda will, though; all you have to do is fiddle with sys.modules so it won't be cached, or rename the file to something unique before reimporting it. You can then patch in functions from the new module and start using them. Pike makes this sort of thing much more convenient; it's not hard to write code that smoothly slides to a new version of itself, without losing any sort of state. But the granularity never gets down below the function, meaning the Python and Pike compilers/interpreters are free to fiddle around inside a function (note, for instance, how Python locals basically just become indices into an array; it'd be a bit awkward to tweak a running Python function and add a 'global' declaration). ChrisA (See? I'm posting on topic!) -- https://mail.python.org/mailman/listinfo/python-list
Re: Several Topics - Nov. 19, 2013
In comp.lang.fortran Rainer Weikusat wrote:
> glen herrmannsfeldt writes:
>> In comp.lang.fortran E.D.G. wrote:
> "E.D.G." wrote in message
> news:ro-dnch2dptbrhnpnz2dnuvz_rsdn...@earthlink.com...
>>> Posted by E.D.G. on November 19, 2013
>>> 1. PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN
(snip)
>>> This program translation project has become one of the most
>>> surprisingly successful programming projects I have worked on to date. A
>>> considerable amount of valuable information has been sent to me by E-mail
>>> in
>>> addition to all of the information posted to the Newsgroups.
(snip, I wrote)
>> In general, language processors can be divided into two categories
>> called compilers and interpreters. Compilers generate instructions for
>> the target processors. Interpreters generate (usually) an intermediate
>> representation which is then interpreted by a program to perform the
>> desired operations. That latter tends to be much slower, but more
>> portable.
>> There are a few langauges that allow dynamic generation of code, which
>> often makes compilation impossible, and those languages tend to be
>> called 'interpreted langauges'.
> These two paragraphs use the same terms in conflicting ways and the
> assertions in the second paragraph are wrong: Lisp is presumably the
> oldest language which allows 'dynamic code creation' and implementations
> exist which not only have a compiler but actually don't have an
> interpreter, cf
> http://www.sbcl.org/manual/index.html#Compiler_002donly-Implementation
> The main difference between a compiler and an interpreter is that the
> compiler performs lexical and semantical analysis of 'the source code'
> once and then transforms it into some kind of different 'directly
> executable representation' while an interpreter would analyze some part
> of the source code, execute it, analyze the next, execute that, and so
> forth, possibly performing lexical and semantical analysis steps many
> times for the same bit of 'source code'.
OK, but many intepreters at least do a syntax check on the whole file,
and many also convert the statements to a more convenient internal
representation.
For an example of something that can't be compiled, consider TeX which
allows the category code of characters to be changed dynamically.
I once wrote self-modifying code for Mathematica, where the running code
(on what Mathematica calls the back end) asked the front end (which does
editing of input data) to change the code.
> Some compilers produce 'machine code' which can be executed directly by
> 'a CPU', others generate 'machine code' for some kind of virtual machine
> which is itself implemented as a program. The distinction isn't really
> clear-cut because some CPUs are designed to run 'machine code'
> originally targetted at a virtual machine, eg, what used to be ARM
> Jazelle for executing JVM byte code directly on an ARM CPU, some virtual
> machines are supposed to execute 'machine code' which used to run
> 'directly on a CPU' in former times, eg, used for backwards
> compatibility on Bull Novascale computers.
Yes. There are also systems that do simple processing on each statement,
with no interstatement memory. Converting numerical constants to
internal form, encoding keywords to a single byte, and such.
It is interesting to see the program listing look different than the way
it was entered, such as constants coming out as 1e6 when you entered
it as 100. The HP2000 BASIC system is the one I still remember.
The popular microcomputer BASIC systems, mostly from Microsoft, allowed
things like:
IF I=1 THEN FOR J=1 TO 10
PRINT J
IF I=1 THEN NEXT J
If you left out the IF on the last line, it would fail when it reached
the NEXT J statement if the FOR hadn't been executed. Compare to C:
if(i==1) for(j=1;j<=10;j++) {
printf("%d\n",j);
}
A compiler would match up the FOR and NEXT at compile time. Many
interpreters do it at run time, depending on the current state.
I also used to use a BASIC system that allowed you to stop a program
(or the program stopped itself), change statements (fix bugs) and
continue on from where it stopped. Not all can do that, but pretty
much compilers never do.
> Prior to execution, Perl source code is compiled to 'machine code' for a
> (stack-based) virtual machine. Both the compiler and the VM are provided
> by the perl program. There were some attempts to create a standalone
> Perl compiler in the past but these never gained much traction.
And, importantly, the code runs fairly slow. Some years ago, I was
working with simple PERL programs that could process data at 1 megabyte
per minute. Rewriting in C, I got one megabyte per second. It is not too
unusual to run 10 times slower, but 60 was rediculous.
-- glen
--
https://mail.python.org/mailman/listinfo/python-list
Re: Several Topics - Nov. 19, 2013
glen herrmannsfeldt writes: > In comp.lang.fortran E.D.G. wrote: "E.D.G." wrote in message news:ro-dnch2dptbrhnpnz2dnuvz_rsdn...@earthlink.com... >> Posted by E.D.G. on November 19, 2013 > >> 1. PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN > > (snip) > >> This program translation project has become one of the most >> surprisingly successful programming projects I have worked on to date. A >> considerable amount of valuable information has been sent to me by E-mail in >> addition to all of the information posted to the Newsgroups. > >> The original posts actually discussed calculation speed matters >> involving Perl and Python. And responses indicated that there were ways to >> develop routines that could dramatically accelerate Python calculations. >> But it did not sound like there were any for Perl. > > In general, language processors can be divided into two categories > called compilers and interpreters. Compilers generate instructions for > the target processors. Interpreters generate (usually) an intermediate > representation which is then interpreted by a program to perform the > desired operations. That latter tends to be much slower, but more > portable. > > There are a few langauges that allow dynamic generation of code, which > often makes compilation impossible, and those languages tend to be > called 'interpreted langauges'. These two paragraphs use the same terms in conflicting ways and the assertions in the second paragraph are wrong: Lisp is presumably the oldest language which allows 'dynamic code creation' and implementations exist which not only have a compiler but actually don't have an interpreter, cf http://www.sbcl.org/manual/index.html#Compiler_002donly-Implementation The main difference between a compiler and an interpreter is that the compiler performs lexical and semantical analysis of 'the source code' once and then transforms it into some kind of different 'directly executable representation' while an interpreter would analyze some part of the source code, execute it, analyze the next, execute that, and so forth, possibly performing lexical and semantical analysis steps many times for the same bit of 'source code'. Some compilers produce 'machine code' which can be executed directly by 'a CPU', others generate 'machine code' for some kind of virtual machine which is itself implemented as a program. The distinction isn't really clear-cut because some CPUs are designed to run 'machine code' originally targetted at a virtual machine, eg, what used to be ARM Jazelle for executing JVM byte code directly on an ARM CPU, some virtual machines are supposed to execute 'machine code' which used to run 'directly on a CPU' in former times, eg, used for backwards compatibility on Bull Novascale computers. Prior to execution, Perl source code is compiled to 'machine code' for a (stack-based) virtual machine. Both the compiler and the VM are provided by the perl program. There were some attempts to create a standalone Perl compiler in the past but these never gained much traction. -- https://mail.python.org/mailman/listinfo/python-list
Re: Several Topics - Nov. 19, 2013
2013/11/19 glen herrmannsfeldt : > More recently, there are JIT systems which generate the intermediate > code, but then at the appropriate time (Just In Time) compile that to > machine code and execute it. This is common for Java, and more recently > for languages like Matlab. Is there a particular reason why you didn't mention PyPy? -- http://ysar.net/ -- https://mail.python.org/mailman/listinfo/python-list
Re: Several Topics - Nov. 19, 2013
In comp.lang.fortran E.D.G. wrote: >>> "E.D.G." wrote in message >>> news:ro-dnch2dptbrhnpnz2dnuvz_rsdn...@earthlink.com... > Posted by E.D.G. on November 19, 2013 > 1. PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN (snip) > This program translation project has become one of the most > surprisingly successful programming projects I have worked on to date. A > considerable amount of valuable information has been sent to me by E-mail in > addition to all of the information posted to the Newsgroups. > The original posts actually discussed calculation speed matters > involving Perl and Python. And responses indicated that there were ways to > develop routines that could dramatically accelerate Python calculations. > But it did not sound like there were any for Perl. In general, language processors can be divided into two categories called compilers and interpreters. Compilers generate instructions for the target processors. Interpreters generate (usually) an intermediate representation which is then interpreted by a program to perform the desired operations. That latter tends to be much slower, but more portable. There are a few langauges that allow dynamic generation of code, which often makes compilation impossible, and those languages tend to be called 'interpreted langauges'. Some years ago when working with perl programs that ran too slow, we found a perl to C translator. Surprisingly, the result ran just as slow! It turns out that the perl to C translator generates a C program containing the intermediate code and the interpreter, and so runs just the same speed. More recently, there are JIT systems which generate the intermediate code, but then at the appropriate time (Just In Time) compile that to machine code and execute it. This is common for Java, and more recently for languages like Matlab. -- glen -- https://mail.python.org/mailman/listinfo/python-list
Several Topics - Nov. 19, 2013
"E.D.G." wrote in message news:ro-dnch2dptbrhnpnz2dnuvz_rsdn...@earthlink.com... Posted by E.D.G. on November 19, 2013 1. PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN 2. COMPUTER PROGRAMMING PROJECTS PERL PDL CALCULATION SPEED VERSUS PYTHON AND FORTRAN This program translation project has become one of the most surprisingly successful programming projects I have worked on to date. A considerable amount of valuable information has been sent to me by E-mail in addition to all of the information posted to the Newsgroups. The original posts actually discussed calculation speed matters involving Perl and Python. And responses indicated that there were ways to develop routines that could dramatically accelerate Python calculations. But it did not sound like there were any for Perl. However, a kind soul sent me the following references: http://pdl.perl.org/ http://www.youtube.com/watch?v=IE-vnnRWiOg http://www.youtube.com/watch?v=rf1yfZ2yUFo From what I can see, PDL represents a group of modules that can be linked with Perl to do faster calculations and to generate charts. I gather that it converts calculations directly to the C language so that they run faster. And now I am wondering how those calculations would compare with Python and Fortran and the other programs listed on the following Web page: http://julialang.org/ As soon as possible I am planning to give the PDL modules a try myself and see if they help with my present Perl calculation speed limitations. Does anyone have any comments they can add regarding PDL (for posting in the Perl Newsgroup)? Would those PDL modules be available on Internet Servers that let users develop and run Perl CGI programs? Or would they need to be specially installed? COMPUTER PROGRAMMING PROJECTS As most people visiting these Newsgroups probably know, computers run our world. And therefore, computer programmers at least indirectly run our world. As an experienced scientist who does some programming work I myself am fully aware of that. But relatively few other scientists are. And almost no government officials appear to be. And they are the ones who have all of the money. As an experienced scientist I regularly send free technical advice to governments and nongovernmental organizations (NGOs) around the world regarding humanitarian projects. Some of my past efforts have been highly successful. And because I am so aware of the importance of computer programming to the success of most efforts I can be especially effective when discussing proposed projects. I know enough about computer programming, electronics, and machine shop usage that I can provide the government officials with exact instructions for how they should proceed with developing some project. For example, sometimes the best way to get something done is with a specially designed electronic circuit. At other times it is more efficient to use a microprocessor to do the data processing. There are several highly important computer programming intensive projects that I have been attempting to get our governments to develop for some time. They are in my opinion needed by people around the world. I have several Web sites that were created so that information could be easily circulated regarding those projects. And as time permits I plan to start discussing them in various computer language Newsgroups. An effort is also in progress to get some modifications made to the U.S. Government Petitions Web Site so that it works a little better and is of more use to people. https://petitions.whitehouse.gov/ It has been my personal experience that our government officials who decide which projects should get funding and how many computer programmers etc. need to be hired for this or that effort usually know so little about the work that computer programmers and even scientists do that they often don't have any idea regarding how to solve various problems and also often don't even know that certain problems exist. These are personal opinions. -- https://mail.python.org/mailman/listinfo/python-list
