Herman Rubin wrote:
>
> In article <·········@hawk.le.ac.uk>, Clive Page <···@le.ac.uk> wrote:
> >In article <···········@b.stat.purdue.edu>,
> >Herman Rubin <······@b.stat.purdue.edu> wrote:
>
> >>This is correct, but what is needed is a versatile macro
> >>processor, in effect a mini-compiler, to enable the user
> >>to use his or her desired notation instead of the highly
> >>contorted and variable assembly language.
>
> >But that was done many years ago, and the language is called C. I'm
> >surprised that you haven't heard of it. Unfortunately it doesn't always
> >mean that code written in C is more efficient than Fortran, because C
> >allows the use of pointers (in fact it's almost impossible to avoid them)
> >and the resulting aliasing makes it very hard for code optimisers to work
> >properly.
>
> I am quite familiar with C, and in fact I prefer it to Fortran for
> many purposes. It does NOT come close to what I am asking for. Much
> of what I want to do can at best be written clumsily in C, if it can
> be done at all. Also, I wish to be able to use the architecture of
> the particular machine.
>
> What I am asking for is a macro processor in which the programmer can
> easily translate to other machine instructions or other macros without
> having to use the mnemonics or other syntactically difficult notation
> beloved of the language people. The simplest use of it would be to
> allow the user to produce "assembler" statements by constructing each
> translation process ONCE.
>
> The programmer knows far more about optimizing the choice of procedure
> than the compiler, and this is, and should be, machine dependent. The
> place for a complicated gadget is an optimizing assembler, although
> here as well the programmer should often be consulted by the software.
> In fact, it is often the case that "standard" optimizing procedures
> do exactly the opposite.
A lisp with built-in assembly or 'code procedures' facility would
work well for this sort of thing. Compiler assertions and directives
fit naturally into the framework of the language. Lisps in
general have very strong macro-facilities, are good for
source-to-source transformations, and current lisp compilers
are pretty good with numeric code. Lisp implementors, however,
don't get their money from people who do a lot of flops, so there's
not much incentive to press the issue.
There are other advantages in using (and extending) lisp as well.
Perhaps a lisp on top of forth?
(Here I mean lisp in general, including scheme.)
--
Mike Rilee NASA/GSFC Mailstop 930.0 Greenbelt, MD 20771
······@hannibal.gsfc.nasa.gov Ph. (301)286-4743 Fx. (301)286-1777
--
Composed using Oberon. http://www-cs.inf.ethz.ch/Oberon.html
From: Herman Rubin
Subject: Re: Most efficient language for floating-point computations
Date:
Message-ID: <5n77b9$kft@b.stat.purdue.edu>
In article <·············@hannibal.gsfc.nasa.gov>,
Mike Rilee <······@hannibal.gsfc.nasa.gov> wrote:
:Herman Rubin wrote:
:> In article <·········@hawk.le.ac.uk>, Clive Page <···@le.ac.uk> wrote:
:> >In article <···········@b.stat.purdue.edu>,
:> >Herman Rubin <······@b.stat.purdue.edu> wrote:
:> >>This is correct, but what is needed is a versatile macro
:> >>processor, in effect a mini-compiler, to enable the user
:> >>to use his or her desired notation instead of the highly
:> >>contorted and variable assembly language.
>> >But that was done many years ago, and the language is called C. I'm
>> >surprised that you haven't heard of it. Unfortunately it doesn't always
>> >mean that code written in C is more efficient than Fortran, because C
>> >allows the use of pointers (in fact it's almost impossible to avoid them)
>> >and the resulting aliasing makes it very hard for code optimisers to work
>> >properly.
>> I am quite familiar with C, and in fact I prefer it to Fortran for
>> many purposes. It does NOT come close to what I am asking for. Much
>> of what I want to do can at best be written clumsily in C, if it can
>> be done at all. Also, I wish to be able to use the architecture of
>> the particular machine.
>> What I am asking for is a macro processor in which the programmer can
>> easily translate to other machine instructions or other macros without
>> having to use the mnemonics or other syntactically difficult notation
>> beloved of the language people. The simplest use of it would be to
>> allow the user to produce "assembler" statements by constructing each
>> translation process ONCE.
>> The programmer knows far more about optimizing the choice of procedure
>> than the compiler, and this is, and should be, machine dependent. The
>> place for a complicated gadget is an optimizing assembler, although
>> here as well the programmer should often be consulted by the software.
>> In fact, it is often the case that "standard" optimizing procedures
>> do exactly the opposite.
>A lisp with built-in assembly or 'code procedures' facility would
>work well for this sort of thing. Compiler assertions and directives
>fit naturally into the framework of the language. Lisps in
>general have very strong macro-facilities, are good for
>source-to-source transformations, and current lisp compilers
>are pretty good with numeric code. Lisp implementors, however,
>don't get their money from people who do a lot of flops, so there's
>not much incentive to press the issue.
>There are other advantages in using (and extending) lisp as well.
>Perhaps a lisp on top of forth?
>(Here I mean lisp in general, including scheme.)
The main need for these macro procedures is that the different syntax
of languages like Lisp can be avoided. The idea is that the user
can write, in a simple manner, macros which translate "normal" notation
into what such "abnormal" notations as lisp and assembler require.
It is necessary to include machine instructions. Far too many useful
instructions have disappeared, or became very clumsy, because the
languages did not support them. Many compilers seem to barf at
optimizing if low level language is included. But much optimization
should be done by the slotting of machine instructions, no matter
where they come from.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
······@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558
In article <··········@b.stat.purdue.edu> ······@b.stat.purdue.edu (Herman Rubin) writes:
From: ······@b.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.lang.fortran,sci.math.num-analysis,comp.lang.lisp
Date: 5 Jun 1997 15:25:13 -0500
Organization: Purdue University Statistics Department
Lines: 72
Distribution: inet
In article <·············@hannibal.gsfc.nasa.gov>,
Mike Rilee <······@hannibal.gsfc.nasa.gov> wrote:
:Herman Rubin wrote:
:> In article <·········@hawk.le.ac.uk>, Clive Page <···@le.ac.uk> wrote:
:> >In article <···········@b.stat.purdue.edu>,
:> >Herman Rubin <······@b.stat.purdue.edu> wrote:
:> >>This is correct, but what is needed is a versatile macro
:> >>processor, in effect a mini-compiler, to enable the user
:> >>to use his or her desired notation instead of the highly
:> >>contorted and variable assembly language.
>> >But that was done many years ago, and the language is called C. I'm
...
>(Here I mean lisp in general, including scheme.)
The main need for these macro procedures is that the different syntax
of languages like Lisp can be avoided. The idea is that the user
can write, in a simple manner, macros which translate "normal" notation
into what such "abnormal" notations as lisp and assembler require.
Mathematica(TM) is such a case. Unless they changed the internal
represenatation, they take their "abnormal" syntax and translate it
into a "normal" form, which is pretty much Lisp.
Common Lisp and Scheme Macros take a "normal" syntax and translate it
into another "normal" syntax, i.e. S-expressions. Doing this with any
other language (apart from Dylan) requires much more sophisticated and
complex machinery, like operators in Prolog (where by messing around
with precedence levels you end up risking using up more parenthesis
than in Lisp) or full fledged parsers produced by YACC et similia.
BTW. Common Lisp is powerful enough to be able to write an "infix"
reader within the language. E.g. you can write
(defun binomial-approx (k n p)
"Binomial function when N >> 1, P << 1 and N*P = A constant."
(let ((a (* n p)))
#I( exp(-a) * (a^^k / fact(k)) )
))
Again this is my recurrent message about infix notation in CL. Check
out the AI.Repository at CMU for the source code.
http://www.cs.cmu.edu/afs/cs.cmu.edu/project/ai-repository/ai/html/air.html
Cheers
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
From: Super-User
Subject: Re: Most efficient language for floating-point computations
Date:
Message-ID: <3399AC30.41C6@alice.urbanet.ch>
Marco Antoniotti wrote:
>
> In article <··········@b.stat.purdue.edu> ······@b.stat.purdue.edu (Herman Rubin) writes:
> The main need for these macro procedures is that the different syntax
> of languages like Lisp can be avoided. The idea is that the user
> can write, in a simple manner, macros which translate "normal" notation
> into what such "abnormal" notations as lisp and assembler require.
>
> Mathematica(TM) is such a case. Unless they changed the internal
> represenatation, they take their "abnormal" syntax and translate it
> into a "normal" form, which is pretty much Lisp.
>
And there's thousands of architects and engineers for whom
doing some work in Lisp is very natural, and many of them
don't know how to program in another language.
The CAD world is a Lisp world
--
Fernando D. Mato Mira http://ligwww.epfl.ch/matomira.html
R&D Manager ········@vrai.ch
VRAI http://www.vrai.ch/
From: Herman Rubin
Subject: Re: Most efficient language for floating-point computations
Date:
Message-ID: <5nbm88$2met@b.stat.purdue.edu>
In article <·············@alice.urbanet.ch>,
Super-User <····@alice.urbanet.ch> wrote:
>Marco Antoniotti wrote:
>> In article <··········@b.stat.purdue.edu> ······@b.stat.purdue.edu (Herman Rubin) writes:
>> The main need for these macro procedures is that the different syntax
>> of languages like Lisp can be avoided. The idea is that the user
>> can write, in a simple manner, macros which translate "normal" notation
>> into what such "abnormal" notations as lisp and assembler require.
>> Mathematica(TM) is such a case. Unless they changed the internal
>> represenatation, they take their "abnormal" syntax and translate it
>> into a "normal" form, which is pretty much Lisp.
>And there's thousands of architects and engineers for whom
>doing some work in Lisp is very natural, and many of them
>don't know how to program in another language.
>The CAD world is a Lisp world
Much of the time, efficient code is not important. In that case,
use what you are used to. But you should be able to use what you
are used to even if efficiency is important.
What I at least meant to state is that there should be a versatile
macro package which allows anyone to EASILY produce the macros to
translate his or her syntax to that of some other language. I have no
problems with the semantics, but using what is to me utterly clumsy
syntax is the problem. I would prefer to write the translator once
than to fight with the syntax every time.
Also, there are constructs which are at best even semantically
clumsy in Lisp, and which should be done in machine language.
Really good code must take into account the machine architecture,
and I believe that to understand computation, one must understand
what are the basic instructions and their timing and scheduling
problems. These change more often than the one who only knows
high level languages would think.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
······@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558
I normally would not post anything on this group, as I'm just a
recreational mathematician :), but programming is my schtick.
Unless efficiency was of the utmost import, I'd be inclined to use
something like Mathematica, or pick a compiler (language doesn't much
matter) which met my requirements for floating point size.
Keep in mind that doing fancy math (floating point, etc) on a computer
can be tricky - those round-offs can be fatal in a hurry.
If you really really really (get the point) need to be efficient, and
need to be portable, why not look at getting a good cross-compiler and
build your own 'language' (really just a set of macros)? Just make sure
that your programmer is a darn good assembly programmer.
LL&P
Jeff
Jeffrey Williams <········@magmacom.com> writes:
> If you really really really (get the point) need to be efficient, and
> need to be portable, why not look at getting a good cross-compiler and
> build your own 'language' (really just a set of macros)? Just make sure
> that your programmer is a darn good assembly programmer.
We've been through this discussion already. People that "really really"
need to be efficient use state-of-the-art optimizing compilers. Even the
best assembly programmers cannot usually match the efficiency of today's
best compilers.
Some people who have small compute-intensive kernals use a disassembler to
let them see what their compiler has done, and further tune this by hand.
I guarantee that the best commercial compilers will beat your own
home-grown macro compiler on any non-trivial code.
-Israel Gale
····@hpc.pko.dec.com
Herman Rubin wrote:
>
> In article <·············@hannibal.gsfc.nasa.gov>,
> Mike Rilee <······@hannibal.gsfc.nasa.gov> wrote:
> :Herman Rubin wrote:
>
> >A lisp with built-in assembly or 'code procedures' facility would
> >work well for this sort of thing. Compiler assertions and directives
> >fit naturally into the framework of the language. Lisps in
> >general have very strong macro-facilities, are good for
> >source-to-source transformations, and current lisp compilers
> >are pretty good with numeric code. Lisp implementors, however,
> >don't get their money from people who do a lot of flops, so there's
> >not much incentive to press the issue.
>
> >There are other advantages in using (and extending) lisp as well.
>
> >Perhaps a lisp on top of forth?
>
> >(Here I mean lisp in general, including scheme.)
>
> The main need for these macro procedures is that the different syntax
> of languages like Lisp can be avoided. The idea is that the user
> can write, in a simple manner, macros which translate "normal" notation
> into what such "abnormal" notations as lisp and assembler require.
Lisp's syntax is quite simple: many translators from more complicated
syntaxes to lisp-like ones have been done. (The intermediate languages
for Sun's f77 and Gnu's gcc are lisp-like if I recall correctly. In
syntax, if not semantics.)
>
> It is necessary to include machine instructions. Far too many useful
> instructions have disappeared, or became very clumsy, because the
> languages did not support them. Many compilers seem to barf at
> optimizing if low level language is included. But much optimization
> should be done by the slotting of machine instructions, no matter
> where they come from.
>
Which points out that we are programming compilers, not computers.
--
Mike Rilee NASA/GSFC Mailstop 930.0 Greenbelt, MD 20771
······@hannibal.gsfc.nasa.gov Ph. (301)286-4743 Fx. (301)286-1777
--
Composed using Oberon. http://www-cs.inf.ethz.ch/Oberon.html
From: Herman Rubin
Subject: Re: Most efficient language for floating-point computations
Date:
Message-ID: <5na16m$2jt6@b.stat.purdue.edu>
In article <·············@hannibal.gsfc.nasa.gov>,
Mike Rilee <······@hannibal.gsfc.nasa.gov> wrote:
>Herman Rubin wrote:
>> In article <·············@hannibal.gsfc.nasa.gov>,
>> Mike Rilee <······@hannibal.gsfc.nasa.gov> wrote:
>> :Herman Rubin wrote:
>> >A lisp with built-in assembly or 'code procedures' facility would
>> >work well for this sort of thing. Compiler assertions and directives
>> >fit naturally into the framework of the language. Lisps in
>> >general have very strong macro-facilities, are good for
>> >source-to-source transformations, and current lisp compilers
>> >are pretty good with numeric code. Lisp implementors, however,
>> >don't get their money from people who do a lot of flops, so there's
>> >not much incentive to press the issue.
>> >There are other advantages in using (and extending) lisp as well.
>> >Perhaps a lisp on top of forth?
>> >(Here I mean lisp in general, including scheme.)
<> The main need for these macro procedures is that the different syntax
<> of languages like Lisp can be avoided. The idea is that the user
<> can write, in a simple manner, macros which translate "normal" notation
<> into what such "abnormal" notations as lisp and assembler require.
>Lisp's syntax is quite simple: many translators from more complicated
>syntaxes to lisp-like ones have been done. (The intermediate languages
>for Sun's f77 and Gnu's gcc are lisp-like if I recall correctly. In
>syntax, if not semantics.)
<> It is necessary to include machine instructions. Far too many useful
<> instructions have disappeared, or became very clumsy, because the
<> languages did not support them. Many compilers seem to barf at
<> optimizing if low level language is included. But much optimization
<> should be done by the slotting of machine instructions, no matter
<> where they come from.
>Which points out that we are programming compilers, not computers.
The main purpose of languages should be to produce a relatively easy
and efficient way to program computers. Compilers are the constructs
to translate the language into computer code.
If we are to write efficient code, we must have access to the features
of the particular machine. Mathematicians can use instructions which
do not occur to the compiler writers or language designers, and can
use operations which occur to them in manners which do not.
Even the "optimizations" of the languages may not be such.
--
This address is for information only. I do not claim that these views
are those of the Statistics Department or of Purdue University.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
······@stat.purdue.edu Phone: (765)494-6054 FAX: (765)494-0558