assert or sqAssert? [was: Re: Source Forge Changes for 3.2.1]
Stephan Rudlof
sr at evolgo.de
Thu Jan 3 15:43:41 UTC 2002
Andrew,
you are correct (as far as I've gotten your mail, see below), but...
Besides that I've posted a changeset
TIPlugin-cleanup-sr.1.cs.gz
in mail subjected
[ENH] TestInterpreterPlugin-cleanup-sr
recently (triggered by this discussion), which simplifies the >>sqAssert:
and therefore...
"Andrew C. Greenberg" wrote:
>
> On Wednesday, January 2, 2002, at 02:11 AM, John M McIntosh wrote:
>
> > LargeIntegersPlugin>>assert: aBool
> > self
> > debugCode:
> > [aBool ifFalse:
> > [self msg: 'Assertion failed!'.
> > self cCode: 'exit(1)'
> > inSmalltalk:
> > [interpreterProxy primitiveFail.
> > self halt]].
> > ^ true]
>
> Well, even as a compromise, this ignores that the code, as written, is
> broken! I suggest eliminating it altogether as used here. Because of
> the
>
> #self cCode:inSmalltalk
>
> message, this method will not be inlined to the caller, even though the
> #debugCode inlines the generated code of #assert: to blank! This is
> what appears to be happening in the generated code for
> LargeIntegerPlugin.
>
> Thus, the generated code for the production version contains calls like:
>
> assert(limit < lenFrom);
>
> which are evaluated for an empty procedure, I don't know how many
> optimizing compilers are smart enough to pick this one up, but with less
> than careful optimiztion, this means that all your assertion expressions
> are evaluated.
... avoids this problem:
- the current production LargeIntegersPlugin>>assert: is used very rarely;
- I've thought that compilers are able to optimize this call away (in
production code generated by default), since then
- C assert() is an empty function,
- there is no function call in the arguments of the generated C assert()
calls,
- there is no side effect while evaluating the arguments of the generated
C assert() calls;
- in the worst case (stupid compiler) these very few to be evaluated boolean
expressions should have negligable impact on performance.
Resumee: There is a better solution, but there is no reason to make panic:
the LargeIntegersPlugin is fast with or without these assert()'s!
Greetings,
Stephan
>
> This is particularly egregious for LargeIntegersPlugin, since that code
> tends to live inside many inner loops for computation-intensive work.
> The microseconds wasted for such computations -- which are unnecessary
> if this were done differently -- add up.
>
> Thus, in addition to the decidedly annoying problems with some important
> platform development systems and the like, this structure is also highly
> inefficient, because
PS: Here your mail has been truncated for me...
--
Stephan Rudlof (sr at evolgo.de)
"Genius doesn't work on an assembly line basis.
You can't simply say, 'Today I will be brilliant.'"
-- Kirk, "The Ultimate Computer", stardate 4731.3
More information about the Squeak-dev
mailing list
|