Re: Portable Software (was: fledgling assembler programmer)

gah4 <>
Fri, 31 Mar 2023 12:41:32 -0700 (PDT)

          From comp.compilers

Related articles
[10 earlier articles]
Re: Portable Software (was: fledgling assembler programmer) (gah4) (2023-03-28)
Re: Portable Software (was: fledgling assembler programmer) (George Neuner) (2023-03-28)
Re: Portable Software (was: fledgling assembler programmer) (gah4) (2023-03-29)
Re: Portable Software (was: fledgling assembler programmer) (Kaz Kylheku) (2023-03-29)
Re: Portable Software (was: fledgling assembler programmer) (Thomas Koenig) (2023-03-31)
Re: Portable Software (was: fledgling assembler programmer) (2023-03-31)
Re: Portable Software (was: fledgling assembler programmer) (gah4) (2023-03-31)
| List of all articles for this month |

From: gah4 <>
Newsgroups: comp.compilers
Date: Fri, 31 Mar 2023 12:41:32 -0700 (PDT)
Organization: Compilers Central
References: 23-03-001 23-03-002 23-03-003 23-03-007 23-03-008 23-03-012 23-03-017 23-03-022 23-03-029 23-03-034 23-03-036 23-03-041
Injection-Info:; posting-host=""; logging-data="47315"; mail-complaints-to=""
Keywords: interpreter, tools, comment
Posted-Date: 01 Apr 2023 04:29:39 EDT
In-Reply-To: 23-03-041

On Friday, March 31, 2023 at 4:42:14 AM UTC-7, Thomas Koenig wrote:
> gah4 <> schrieb:
> > For system like Matlab and Octave, and I believe also for Python,
> > or one of many higher math languages, programs should spend
> > most of the time in the internal compiled library routines.

> They should, but sometimes they don't.

> If you run into things not covered by compiled libraries, but which
> are compute-intensive, then Matlab and (interpreted) Python run
> as slow as molasses, orders of magnitude slower than compiled code.

But then there is dynamic linking.

I have done it in R, but I believe it also works for Matlab and
Python, and is the way many packages are implemented. You write a
small C or Fortran program that does the slow part, and call it from
interpreted code.

And back to my favorite x86 assembler program:

rdtsc: rdtsc

which allows high resolution timing, to find where the program
is spending too much time. Some years ago, I did this on a program
written by someone else, so I mostly didn't know the structure.
Track down which subroutines used too much time, and fix
just those.

In that case, one big time sink is building up a large matrix one
row or one column at a time, which requires a new allocation and
copy for each time. Preallocating to the final (if known) size fixes that.

But then there were some very simple operations that, as you note,
are not included and slow. Small C programs fixed those.
There are complications for memory allocation, which I avoid
by writing mine to assume (require) that all is already allocated.


> At the company I work for, I'm told each Python project will only
> use a certain specified version of Python will never be changed for
> fear of incompatibilities - they treat each version as a new
> programming language :-|

> To bring this back a bit towards compilers - a language definition
> is an integral part of compiler writing. If

I have heard about that one.

It seems that there are non-backward compatible changes
from Python 2.x to 3.x. That is, they pretty much are different

Tradition on updating a language standard is to maintain, as much
as possible, backward compatibility. It isn't always 100%, but often
close enough. You can run Fortran 66 program on new Fortran 2018
compilers without all that much trouble. (Much of the actual problem
comes with extensions used by the old programs.)
[Python's rapid development cycle definitely has its drawbacks. Python 3
is not backward compatible with python 2 (that's why they bumped the major
version number) and they ended support for python 2 way too soon. -John]

Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.