Re: Portable Software (was: fledgling assembler programmer)

On Friday, March 31, 2023 at 4:42:14 AM UTC-7, Thomas Koenig wrote:
> gah4 <ga...@u.washington.edu> 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
      ret


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.


(snip)


> 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
languages.


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]

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