Return to the
comp.compilers page.
Search the
comp.compilers archives again.
| From: | gah4 <gah4@u.washington.edu> |
| Newsgroups: | comp.compilers |
| Date: | Wed, 29 Mar 2023 11:27:49 -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 |
| Injection-Info: | gal.iecc.com; posting-host="news.iecc.com:2001:470:1f07:1126:0:676f:7373:6970"; logging-data="34049"; mail-complaints-to="abuse@iecc.com" |
| Keywords: | interpreter |
| Posted-Date: | 30 Mar 2023 20:21:32 EDT |
| In-Reply-To: | 23-03-034 |
On Wednesday, March 29, 2023 at 1:52:41 AM UTC-7, George Neuner wrote:
> Right. When you work on a popular "managed" platform (e.g., JVM or
> CLR), then its JIT compiler and CPU specific libraries gain you any
> CPU specific optimizations that may be available, essentially for
> free.
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.
You could write a whole matrix inversion algorithm in Matlab
or Python, but no reason to do that. That is the convenience
of matrix operations, and gets better as they get bigger.
In earlier days, there were Linpack and Eispack, and other
Fortran callable math libraries. And one could write a
small Fortran program to call them.
But now we have so many different (more or less) interpreted
math oriented languages, that it is hard to keep track of them,
and hard to know which one to use.
Return to the
comp.compilers page.
Search the
comp.compilers archives again.