"Joe Marshall" <·············@attbi.com> writes:
> "Barry Margolin" <······@genuity.net> wrote in message ······················@paloalto-snr1.gtei.net...
> > In article <···············@sindri.juniper.net>,
> > Joel Ray Holveck <·····@juniper.net> wrote:
> > >Assuming that X is not special, in the following function:
> > >
> > >(defun foo (x)
> > > x)
> > >
> > >Is the extent for this binding of X said to have ended after FOO
> > >exits? That is to say, does the extent of a binding terminate simply
> > >because the binding is no longer reachable?
> >
> > Yes. The extent of a binding is the period of time during which references
> > may occur. Since it's not possible to refer to that binding after FOO has
> > returned, the extent ends then. If FOO had created a closure that
> > referenced X, e.g.
> >
> > (defun foo (x)
> > (setq *x-getter* #'(lambda () x))
> > x)
> >
> > then its extent would last as long as any of those closures are still
> > around.
>
> I don't want to contradict Barry (he is correct), but another way to
> view this is that the variable X has `indefinite' extent. That is
> to say that binding `lasts forever'. Now it is trivial (in this case)
> for the compiler to prove that there is no way to refer to X after
> the function exits, so it can arrange for the binding to be
> discarded. If a closure over the binding is made (and that closure
> `escapes' the dynamic context), then the compiler will have to arrange
> for the garbage collector to discard the binding.
I think this is a good point, and one I've had such hassles with people
about over the years.
There was a MASSIVE fuss within the design of ANSI CL about the question
of whether I was to be allowed to say that the function and value cell
of symbols were "slots", something I claim should have been a pure editorial
decision.
There were a number of people who worried (I think unnecessarily) that had
I said "slot" that it would have (a) forced allocation of the thing even
if it were not needed and (b) required disclosure of the thing.
I claimed that (a) was not needed because implementations can always get
rid of things that have no consequence, and (b) was not an issue because
symbols are metaclass built-in-class, and so you really don't know whether
any of the reflective tools would find them. For example, one doesn't know
if with-slots will work on structs (it does in some implementations and
not in others) because structure-class doesn't define it.
There was even a concern (c) that it would force "contiguous"
allocation which was even weirder to me because I'm not sure what
"contiguous" even means in modern memory architectures, where you
really don't know what bits are "side-by-side" and what are drawn from
cache and what are drawn from parellel disks rather than same
disk... virtual memory means data can be coming from all over anyway, and
there is no way to test memory address, so the idea that somehow a symbol
would be "all on a page" is an issue for implementors to fuss over, but
not something that users can control in any way.
I recall stories of FORTRAN benchmarks that ran in 0 time and when checked
were found to do so because they contained no I/O statements and FORTRAN
had optimized away the entire program as uninteresting as a result. Who
can really blame them?
Kent M Pitman <······@world.std.com> writes:
> I recall stories of FORTRAN benchmarks that ran in 0 time and when checked
> were found to do so because they contained no I/O statements and FORTRAN
> had optimized away the entire program as uninteresting as a result. Who
> can really blame them?
gcc does the same. In a performance test for BLAS operations I had to
add the result of a dot product (which was 0.0d0) to the resulting
MFLOPS number to avoid the routine to be "optimized" away. I did not
like that at all. And I am happy that I did not yet meet this
kind of optimization with Lisp.
Nicolas.
Nicolas Neuss <·············@iwr.uni-heidelberg.de> writes:
> Kent M Pitman <······@world.std.com> writes:
>
> > I recall stories of FORTRAN benchmarks that ran in 0 time and when checked
> > were found to do so because they contained no I/O statements and FORTRAN
> > had optimized away the entire program as uninteresting as a result. Who
> > can really blame them?
>
> gcc does the same. In a performance test for BLAS operations I had to
> add the result of a dot product (which was 0.0d0) to the resulting
> MFLOPS number to avoid the routine to be "optimized" away. I did not
> like that at all. And I am happy that I did not yet meet this
> kind of optimization with Lisp.
I've seen CMUCL do it. It can be annoying when you're trying to write
a benchmark, but Python is written with production code in mind, not
benchmarks -- which is a good choice, IMNSHO.
--
/|_ .-----------------------.
,' .\ / | No to Imperialist war |
,--' _,' | Wage class war! |
/ / `-----------------------'
( -. |
| ) |
(`-. '--.)
`. )----'
From: Tim Bradshaw
Subject: Re: A theoretical question about extent
Date:
Message-ID: <ey3fzxlqmke.fsf@cley.com>
* Thomas F Burdick wrote:
> I've seen CMUCL do it. It can be annoying when you're trying to write
> a benchmark, but Python is written with production code in mind, not
> benchmarks -- which is a good choice, IMNSHO.
If a compiler can optimize a benchmark away it probably isn't a very
good benchmark.
--tim