··········@mailandnews.com (Software Scavenger) writes:
> The following code disassembles to the code shown after it. Can
> anyone suggest ways to reduce it?
why should that be changed?
> I just want a simple call to a
> foreign function with no checking or any other overhead.
Why are you using Lisp than? Use Assembler.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> wrote in message news:<··············@frown.here>...
> why should that be changed?
In a tight loop in Lisp I want to be able to invoke a foreign function
as fast as a Lisp function, because the overhead of invoking it can be
a bottleneck, making the program many times slower than it should be.
> Why are you using Lisp than? Use Assembler.
How do I use assembler from Lisp? If I use the FFI to invoke it, I
will have the same problem.
In some programs 99% of the time consumption is in 1% of the code.
Such a program might be very sophisticated overall, such that a high
level language is needed to implement it well. But the 1% that
consumes 99% of the time might be very unsophisticated, and just need
to reduce overhead to make the whole program much faster.
··········@mailandnews.com (Software Scavenger) writes:
> Friedrich Dominicus <·····@q-software-solutions.com> wrote in message news:<··············@frown.here>...
>
> > why should that be changed?
>
> In a tight loop in Lisp I want to be able to invoke a foreign function
> as fast as a Lisp function, because the overhead of invoking it can be
> a bottleneck, making the program many times slower than it should
be.
Well you wrote can be. Is it? If not why do you care?
>
> > Why are you using Lisp than? Use Assembler.
>
> How do I use assembler from Lisp?
Now at least Corman Lisp can cope with inline assembly.
>
> In some programs 99% of the time consumption is in 1% of the code.
> Such a program might be very sophisticated overall, such that a high
> level language is needed to implement it well. But the 1% that
> consumes 99% of the time might be very unsophisticated, and just need
> to reduce overhead to make the whole program much faster.
Well have you profiled it is it really a bottleneck? Must it be solved
with Assembler?
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> wrote in message news:<··············@frown.here>...
> Well have you profiled it is it really a bottleneck? Must it be solved
> with Assembler?
I've done extensive profiling and testing. The purpose is to write a
document for people who think Lispworks is too slow. The purpose of
the document is to show that any time a bottleneck happens because of
any slowness of Lispworks, it can be worked around easily. The
document has to have a general workaround which can be applied to
not-yet-discovered instances of slowness in Lispworks.
I thought I could use the FFI for this purpose. The document would
explain how to use the FFI as a workaround. But I can't do that if
the FFI is too slow.
What's at stake is not necessarily speed. What's really at stake
might turn out to be whether Lispworks is used at all.
··········@mailandnews.com (Software Scavenger) writes:
> Friedrich Dominicus <·····@q-software-solutions.com>
>
> > Well have you profiled it is it really a bottleneck? Must it be solved
> > with Assembler?
>
> I thought I could use the FFI for this purpose. The document would
> explain how to use the FFI as a workaround. But I can't do that if
> the FFI is too slow.
Well is it to slow in that form? What optimizations have you turned on
or off? Have you contacted Xanalys?
>
> What's at stake is not necessarily speed. What's really at stake
> might turn out to be whether Lispworks is used at all.
Well you did not tell if it's really too slow. You pick out some
assembler output from LispWorks and say this is slow by just looking
at it? Why have you care about a possbile bottleneck but not idea if
that's really a problem? What customer asks for speed consideretions
before the program is running?
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> wrote in message news:<··············@frown.here>...
> Well is it to slow in that form? What optimizations have you turned on
This kind of testing is easy if you have a C compiler that can create
a DLL. It can be done with the free version of Lispworks. Here is an
example one-line file of C source code for Windows:
__declspec(dllexport) void __cdecl testdll() {}
A typical command line for the Microsoft compiler to generate a DLL
from the above is cl /LD testdll.c
The kinds of questions you have, to make sure I'm doing everything
right, etc., are answered much faster and more easily by running the
test yourself. Even if I gave you the exact answers you were looking
for, how would you know if they were correct? Communication about
programming problems works much better when both parties are doing the
same testing.
I would also appreciate some hints from other people who have done the
same things. It seems to me there must be lots of them. Where are
they?
Note: You really _must_ go to your lisp vendor to get definitive answers
for these questions.
··········@mailandnews.com (Software Scavenger) writes:
> Friedrich Dominicus <·····@q-software-solutions.com> wrote in
> message news:<··············@frown.here>...
>
> > Well is it to slow in that form? What optimizations have you turned on
>
> This kind of testing is easy if you have a C compiler that can create
> a DLL. It can be done with the free version of Lispworks. Here is an
> example one-line file of C source code for Windows:
>
> __declspec(dllexport) void __cdecl testdll() {}
>
> A typical command line for the Microsoft compiler to generate a DLL
> from the above is cl /LD testdll.c
And a typical declaration for a call to such a function might
be:
Dllexport void testdll();
However, this is not the most efficient declaration available, because it
does not tell the compiler how many arguments are being passed to the
function. Instead, declare it as
Dllexport void testdll(void);
which states that precisely zero arguments are going to be sent
to the function. The compiler might be able to optimize for that
situation (though usually, it is really the argument types that are
important, as to whether to place an argument into a general register,
a floating-point location, or the stack).
> The kinds of questions you have, to make sure I'm doing everything
> right, etc., are answered much faster and more easily by running the
> test yourself. Even if I gave you the exact answers you were looking
> for, how would you know if they were correct? Communication about
> programming problems works much better when both parties are doing the
> same testing.
>
> I would also appreciate some hints from other people who have done the
> same things. It seems to me there must be lots of them. Where are
> they?
1. In your original article, you give a definition:
(fli:define-foreign-function (testdll "testdll" :source) () :language
=========================================================^^
:ansi-c :no-check t)
I don't know LispWorks's foreign interface, but a quick check of their
documentation showed me that the above flagged argument list could be
enhanced to specify how many arguments are being passed and of what
type. This extra specification might make a difference in the way
the wrapper is built.
2. You are apparently disassembling the wrapper function itself. How
do you know that such code is actually being called in compiled code?
Some CL implementations allow a direct-call optimization, such that if
conditions are right and an apparent call is made to the wrapper function,
the call point will be expanded to more direct code, bypassing the
wrapper entirely. Thus, the wrapper is only present in case of an
interpreted call to the foreign function. Ask your vendor if this is
possible, and under what circumstances.
As Roger Corman stated in another article, the lisp-to-C transition
need not be very large; it is mostly an issue of marking the stack
for the GC and for interrupt handlers. This should only take a few
instructions.
--
Duane Rettig Franz Inc. http://www.franz.com/ (www)
1995 University Ave Suite 275 Berkeley, CA 94704
Phone: (510) 548-3600; FAX: (510) 548-8253 ·····@Franz.COM (internet)
"Software Scavenger" <··········@mailandnews.com> wrote in message
·································@posting.google.com...
>
> This kind of testing is easy if you have a C compiler that can create
> a DLL. It can be done with the free version of Lispworks. Here is an
> example one-line file of C source code for Windows:
>
> __declspec(dllexport) void __cdecl testdll() {}
>
> A typical command line for the Microsoft compiler to generate a DLL
> from the above is cl /LD testdll.c
>
This kind of test is worse than useless. In any language a link
to a foreign call creates overhead and that needs to be accounted
for, granted. The point behind using this mechanism is either
to get access to functionality unavailable in the language,
or to get a performance gain over the compiler generated code.
As an analogy, if you have a long drive to work the wait to
get on the expressway may be worth it for the time saved over
driving the backroads route, but if you live 2 blocks from
work it probably isn't. Your test is definitely in the latter
category because it only concentrates only on the cost of
the on-ramp.
Besides, with Lisp the speed limit on the backroads
isn't that bad. :-)
Geoff
"Geoff Summerhayes" <·············@hNoOtSmPaAiMl.com> wrote in message news:<··············@corp.supernews.com>...
> As an analogy, if you have a long drive to work the wait to
> get on the expressway may be worth it for the time saved over
I did mention something like putting the whole inner loop in C code as
one alternative, in one of my previous messages. However, for the
purposes of the document I'm writing, I would prefer to be able to
optimize at very fine granularity. It would make the document more
useful for its real purpose, which is to convince skeptics that the
speed quirks of Lispworks are never going to be a problem.
What I basically want is to find a shortcut onto the expressway, so I
can use it for short hops at high speed. Or maybe retrofit my vehicle
with an expressway fence hopping and cop evasion mechanism.
I believe the overhead of calling a foreign function will probably always be
somewhat greater than calling a lisp function. The register usage conventions
are typically different between lisp code (which the compiler writer has control
over) and foreign code (which he doesn't). A certain amount of regsiter saving
or shuffling, and possibly thunking, must occur on a foreign call. In Corman
Lisp, some stack record keeping is done so if the garbage collector kicks in
during a foreign call (it can happen--either by using multiple threads or if the
foriegn code calls back into lisp) then the collector knows a section of the
stack is "unmanaged" by the lisp system (and don't check for lisp pointers
there).
So, one should be very careful trying to code direct foreign calls--they are
likely to screw up the system. It is unlikely you can, without full sources and
a lot of time, come up with a better solution the the compiler implementors.
You just have to understand the overhead of the FFI, which varies from one
system to another, and make sure the benefits of any foreign calls outweigh the
costs.
Roger
-----------------------------------
On Thu, 30 Aug 2001 10:51:35 -0400, "Geoff Summerhayes"
<·············@hNoOtSmPaAiMl.com> wrote:
>
>"Software Scavenger" <··········@mailandnews.com> wrote in message
>·································@posting.google.com...
>>
>> This kind of testing is easy if you have a C compiler that can create
>> a DLL. It can be done with the free version of Lispworks. Here is an
>> example one-line file of C source code for Windows:
>>
>> __declspec(dllexport) void __cdecl testdll() {}
>>
>> A typical command line for the Microsoft compiler to generate a DLL
>> from the above is cl /LD testdll.c
>>
>
>This kind of test is worse than useless. In any language a link
>to a foreign call creates overhead and that needs to be accounted
>for, granted. The point behind using this mechanism is either
>to get access to functionality unavailable in the language,
>or to get a performance gain over the compiler generated code.
>
>As an analogy, if you have a long drive to work the wait to
>get on the expressway may be worth it for the time saved over
>driving the backroads route, but if you live 2 blocks from
>work it probably isn't. Your test is definitely in the latter
>category because it only concentrates only on the cost of
>the on-ramp.
>
>Besides, with Lisp the speed limit on the backroads
>isn't that bad. :-)
>
>Geoff
>
>
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> > What's at stake is not necessarily speed. What's really at stake
> > might turn out to be whether Lispworks is used at all.
> Well you did not tell if it's really too slow. You pick out some
> assembler output from LispWorks and say this is slow by just looking
> at it? Why have you care about a possbile bottleneck but not idea if
> that's really a problem? What customer asks for speed consideretions
> before the program is running?
What's the alternative? Not to care about speed considerations until
the program is running then find that it's impossible to make it any
faster and you have to start again in C? That doesn't sound like a win.
Performance is an acceptance criterion just like any other. If a risk
has been identified that the program may be too slow, then it's
entirely reasonable to address that risk early in the development
process using a prototype. This appears to be what the original
poster is asking. This is not the same thing as requiring that the
program be kept perpetually speed-optimized throughout its development
cycle, which I agree is stupid.
Unfortunately, I can't help with LispWorks. If you'd said SBCL then I
could tell you all I've learnt recently about VOPs, but I doubt very
much that the experience carries over directly.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> What's the alternative? Not to care about speed considerations until
> the program is running then find that it's impossible to make it any
> faster and you have to start again in C? That doesn't sound like a win.
>
I think the issue was that a large chunk of assembler was being shown
without any real evidence that profiling (perhaps of a small prototype
of the program) showed that there was actually a problem and it was
this. People tend to be *very* bad at working out where performance
problems are by inspection of code.
It did seem to me that the solution (using the FFI in a loop to avoid
slowness) was a bit naive: it's not at all clear to me that a
non-trivial foreign call will be faster than a lisp call (I'm talking
about the function call overhead here, not the speed of the function
body code), and I can see a lot of reasons why it might be a lot
slower - representation conversion of all sorts of things, argument
copying and so on. So a foreign call inside an inner loop might be
quite bad in terms of performance. Much better would be to move the
whole inner loop into a foreign call, so you make one call rather than
n. Of course whether foreign calls are unavoidably slow is
implementation dependent - perhaps one of the implementors could say
if my guess is right?
But what I find much more strange than any of this is that this
question is being asked on c.l.l at all! This is a commercial Lisp
with good support, *surely* the place to ask this kind of thing is by
asking the support people: they will know the characteristics of the
system and tricks that can be played better than anyone. If the aim
is to write a document which will encourage use of their system than
I'm quite sure they will be anxious to help: they're not stupid!
--tim
Tim Bradshaw <···@tfeb.org> writes:
> I think the issue was that a large chunk of assembler was being shown
> without any real evidence that profiling (perhaps of a small prototype
> of the program) showed that there was actually a problem and it was
> this. People tend to be *very* bad at working out where performance
> problems are by inspection of code.
>
> It did seem to me that the solution (using the FFI in a loop to avoid
> slowness) was a bit naive: it's not at all clear to me that a
The chunk of assembler being shown was as I understood it the FFI glue
that LispWorks had generated around the foreign function call. (If
I'm wrong, my whole argument is bogus and I must withdraw it). So, you can
"see a lot of reasons why it might be slower", and the original poster
has looked at the assembler and decided that he can also see a lot of
reasons it might be slow
> non-trivial foreign call will be faster than a lisp call (I'm talking
> about the function call overhead here, not the speed of the function
> body code), and I can see a lot of reasons why it might be a lot
> slower - representation conversion of all sorts of things, argument
> copying and so on. So a foreign call inside an inner loop might be
Well, that was the question, I believe. Foreign calls are slow if you
have to do all the copying/checking/marshalling/conversion; how can we
make them faster? Making fewer of them is one approach, the other is
to do less copying/checking/marshalling/conversion, so how much of
that can be turned off?
(Only marginally related to the original poster's point, but worth
bringing up anyway: suppose the reason you need to do a foreign call
is not in itself speed-related but is to access a facility that Lisp
doesn't provide - e.g. access to the x86 IO port space. If you know
the call convention for your Lisp, wouldn't it be easier to write
(outb) and (inb) as Lisp-compatible functions in assembler than to
write them in C and use the full FFI)
> But what I find much more strange than any of this is that this
> question is being asked on c.l.l at all! This is a commercial Lisp
> with good support, *surely* the place to ask this kind of thing is by
> asking the support people: they will know the characteristics of the
> system and tricks that can be played better than anyone. If the aim
> is to write a document which will encourage use of their system than
> I'm quite sure they will be anxious to help: they're not stupid!
Quite right.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
> Well, that was the question, I believe. Foreign calls are slow if you
> have to do all the copying/checking/marshalling/conversion; how can we
> make them faster? Making fewer of them is one approach, the other is
> to do less copying/checking/marshalling/conversion, so how much of
> that can be turned off?
I think that's what the OP should ask the vendor.
Kind of semi-relatedly but not really: does anyone here know the real
story about Franz Lisp (?) and function-call performance on the VAX?
I've heard it several times (and it actually sort-of is to do with
foreign call performance) but I don't want to repeat my
half-remembered version. Someone at Franz must have the definititive
version, I guess, (or Jeff?).
--tim
>>>>> On 30 Aug 2001 16:48:37 +0100, Tim Bradshaw ("Tim") writes:
Tim> I think that's what the OP should ask the vendor.
I think it's perfectly reasonable to ask the newsgroup about an issue
such as this one, and I wish you would stop trying to discourage people
from doing so. I think they should also ask the vendor, just as it
goes without saying that they should also read the documentation.
Asking about performance optimizations or implementation-specific
features or even hacks is different than reporting a bug in an
implementation; the latter being most usefully addressed to the vendor.
(I would still like to see people mention known bugs, though.)
You also seem to take issue with the fact that the question is about
speed considerations. Execution speed is a perfectly legitimate concern,
and berating someone in some vague way for not first profiling their
program is not a positive approach. There is a body of stock advice
on the general subject of performance profiling, the primary idea
being that it's a good idea to use profiling to identify performance
bottlenecks before investing in needless or false optimizations or
contorting designs around them. But there's a lot more too it than that.
If a more experienced person on this newsgroup is too personally weary to
provide the kind of help that the person is asking for, even so much as a
clear explanation or pointer to the stock advice, just staying out of it
would waste less bandwidth and be seen as much friendlier for everybody
But this person has raised an interesting and specific issue.
FFIs are sometimes offered as a way to offload computations that might be
more inefficient in Lisp. Investigating this, the guy produced a small
program to see the overhead of the foreign calling interface. He was
surprised at the size, probably due to a lack of understanding of what
that sort of thing might entail. Moreover, he was thinking of calling
it in a tight loop, which might or might not be appropriate.
While I am probably a lot more familiar with Lisp and system internals
and related design issues than than the guy who asked this question,
it just so happens that I am also thinking about some similar problems
for a program I'm working on, and would be interested in the general
discussion. While I might exploit the information very differently,
if there's a discussion of the actual issues (rather than exclusively
meta comments about whether it's an appropriate topic) this other guy
might learn a lot of things he really needs to know along the way, too.
FFIs are a valid point of discussion, and since it is not a standard,
there are only particular implementations to consider and compare.
This also provides an opening to the topic in general, which could
lead to some interesting discussions about future standards.
So please stop telling him to shut up.
Christopher Stacy <······@spacy.Boston.MA.US> writes:
>
> So please stop telling him to shut up.
Just for the record: I didn't, please don't confuse what I said with
what you think (wrongly) I might have meant.
--tim
Daniel Barlow <···@telent.net> writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > > What's at stake is not necessarily speed. What's really at stake
> > > might turn out to be whether Lispworks is used at all.
> > Well you did not tell if it's really too slow. You pick out some
> > assembler output from LispWorks and say this is slow by just looking
> > at it? Why have you care about a possbile bottleneck but not idea if
> > that's really a problem? What customer asks for speed consideretions
> > before the program is running?
>
> What's the alternative? Not to care about speed considerations until
> the program is running then find that it's impossible to make it any
> faster and you have to start again in C?
How likely is that going to happen. You can screw up so much during
development that knowing how to optimise one tight loop is totally
useless. It wasts time for now gain. First make it run, does it?
Than make it fast. Usually the second is long forgotten if it just
works.
>
> Performance is an acceptance criterion just like any other. If a risk
> has been identified that the program may be too slow, then it's
> entirely reasonable to address that risk early in the development
> process using a prototype.
Well it's hard to believe that you know before really having it
running that it will have to fall back to FFI stuff. And with just
theoretical consideretations it's IMHO simply useless.
>This appears to be what the original
> poster is asking.
Well he should first read the documentation, as e.g Duane Rettig
does. Provide the other side with as much information as one can. This
will definitly help. He had to keep in mind what Roger Cormans said. I
guess if you know his Common Lisp you definitly can know what's where
and how to put it to it's limits. The only ones really knowing
LispWorks are Xanalys. I'm sure if that is really a problem they will
come up with a good suggestion.
Now it's obviously that I find the questin inacceptable. It's the
wrong time to ask for it. I do not know any example even in literature
where this is the real showstopper.
Regards
Friedrich
Friedrich Dominicus <·····@q-software-solutions.com> writes:
> Daniel Barlow <···@telent.net> writes:
> > What's the alternative? Not to care about speed considerations until
> > the program is running then find that it's impossible to make it any
> > faster and you have to start again in C?
>
> How likely is that going to happen. You can screw up so much during
> development that knowing how to optimise one tight loop is totally
> useless. It wasts time for now gain. First make it run, does it?
> Than make it fast. Usually the second is long forgotten if it just
> works.
Usually, yes. But sometimes you know perfectly well that it's *vital*
how micro-optimized your inner loops are. Say, for example, the
garbage collector I'm (very slowly) working on. Firstly, I'm
concerned with correctness. Secondly, I'm concerned with
algorithmic-level and higher-level optimizations. Finally, I will
then concern myself with making quite a few parts of it as blazingly
fast as possible. I hope that the compiler serves me well enough to
generate (with my help) very fast code for most of it. But I can say
with 99% certainty that there are parts I *will* need to rewrite in
highly hand-optimized assembly. All the cool features of my GC will
be moot if I can't make certain parts blazingly fast. It's in the
nature of the problem. If I knew ahead of time that it was not
possible to make these sorts of optimizations in the necessary parts
of my code, I would switch development environments. I might not know
*exactly* where I need to do the hand coding, but I can probably make
a good guess as to generally what sort of code I'll be
hand-optimizing.
People often forget that speed usually doesn't matter, but sometimes
people go off in the wrong direction and forget that sometimes speed
is *as* important as correctness.
"Thomas F. Burdick" <···@apocalypse.OCF.Berkeley.EDU> wrote in message
····················@apocalypse.OCF.Berkeley.EDU...
> People often forget that speed usually doesn't matter, but sometimes
> people go off in the wrong direction and forget that sometimes speed
> is *as* important as correctness.
>
Indeed. Of course it is a discipline of its own, but Real-Time programming
comes to mind. In this case the speed of execution is an integral part of
the codes correctness. The right answer is not enough, you must have the
right answer at the right time.
Coby
···@apocalypse.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> Friedrich Dominicus <·····@q-software-solutions.com> writes:
>
> > Daniel Barlow <···@telent.net> writes:
>
> > > What's the alternative? Not to care about speed considerations until
> > > the program is running then find that it's impossible to make it any
> > > faster and you have to start again in C?
> >
> > How likely is that going to happen. You can screw up so much during
> > development that knowing how to optimise one tight loop is totally
> > useless. It wasts time for now gain. First make it run, does it?
> > Than make it fast. Usually the second is long forgotten if it just
> > works.
>
> Usually, yes. But sometimes you know perfectly well that it's *vital*
> how micro-optimized your inner loops are. Say, for example, the
> garbage collector I'm (very slowly) working on. Firstly, I'm
> concerned with correctness. Secondly, I'm concerned with
> algorithmic-level and higher-level optimizations. Finally, I will
> then concern myself with making quite a few parts of it as blazingly
> fast as possible.
Well I asked if there is really a bottleneck. That is still
unanswered. The OP does not mention any other constraints, shows a
piece of assembler and asked how to it up. That is as if I see a seat
from a car and aske how fast it can run. It was pointed out to him
that his FFI code does not provide most of the information, and it was
too pointed out that a natie Lisp function call does not have to
hamper with register savings and the like, and it was pointed out that
knowing to shortcut means knowing the innerst of the used Lisp.
Friedrich
Forgive me for finding some humor in this discusion
about the "slowness" of LispWorks.
I usually have to use Java (I am a Java consultant)
and as good as Java is for quickly banging out
network and server side code, I always look forward
to the times when I get to use LispWorks because
both the programming environment and applications
run fast, even on an old PC.
I question how often it is worth the greatly increased
development time to code in C/C++ over Lisp or
Java. It is a free world, so please go and enjoy
VisualC++ :-) Seriously, I used C++ for years
(and wrote 5 C++ books), but except for some
work on a few Nintendo Video games, nothing else
that I have every worked on required that last few percent
of speed - usually minimizing development costs is
more important than having to buy a little more compute power.
-Mark
--Mark Watson -- Java consulting, Open Source and Content:
www.markwatson.com
"Mark Watson" <·····@NOSPAM_markwatson.com> writes:
> I usually have to use Java (I am a Java consultant)
> and as good as Java is for quickly banging out
> network and server side code, I always look forward
> to the times when I get to use LispWorks because
> both the programming environment and applications
> run fast, even on an old PC.
>
> I question how often it is worth the greatly increased
> development time to code in C/C++ over Lisp or
> Java. It is a free world, so please go and enjoy
> VisualC++ :-) Seriously, I used C++ for years
> (and wrote 5 C++ books), but except for some
> work on a few Nintendo Video games, nothing else
> that I have every worked on required that last few percent
> of speed - usually minimizing development costs is
> more important than having to buy a little more compute power.
>
Shhh. They've been trying to conceal this for years. You'll find
yourself getting abducted by black helicopters if you post stuff like
this (I know, I did).
--tim
··········@mailandnews.com (Software Scavenger) writes:
> The following code disassembles to the code shown after it. Can
> anyone suggest ways to reduce it? I just want a simple call to a
> foreign function with no checking or any other overhead.
>
Evaluating the code with safety=0 reduces it by 24 bytes.
Clive Tong <··········@scientia.com> writes:
> ··········@mailandnews.com (Software Scavenger) writes:
>
> > The following code disassembles to the code shown after it. Can
> > anyone suggest ways to reduce it? I just want a simple call to a
> > foreign function with no checking or any other overhead.
> >
>
> Evaluating the code with safety=0 reduces it by 24 bytes.
Seems to me that LW uses safety=0 to do some very radical things (like
not checking for stack overflow) and I would be VERY careful to bound
the safety=0 lexically to exactly the thing I wanted to do (using a
LOCALLY around the exact form of intereset) rather than proclaim it
globally or even declare it locally to one function. I often wrap
such things into macros so I don't forget and so I do it correctly.
Under ordinary circumstances, I would not use less than SAFETY=1
and feel comfortable about it in LW.
Just my personal feeling.
··········@mailandnews.com (Software Scavenger) writes:
> The following code disassembles to the code shown after it. Can
> anyone suggest ways to reduce it? I just want a simple call to a
> foreign function with no checking or any other overhead.
>
I would have thought this is a good example of something that the
vendor should be able to answer questions on, and it might be better
to ask them directly. Apart from anything else there may be hacky
ways of making things faster which they're not really willing to
suggest in public because there are a lot of caveats involved or the
information is version-specific or something...
--tim
Tim Bradshaw <···@tfeb.org> wrote in message news:<···············@davros.tardis.ed.ac.uk>...
> I would have thought this is a good example of something that the
> vendor should be able to answer questions on, and it might be better
Is anyone from Xanalys reading this? I'm curious how many Lisp
programmers they have and how often this forum gets visited by one or
more of them.
Software Scavenger wrote:
> Is anyone from Xanalys reading this? I'm curious how many Lisp
> programmers they have and how often this forum gets visited by one or
> more of them.
And out of those how many would want to publically announce this. I'm
not sure I would.
:)w
>>>>> "will" == will deakin <··········@hotmail.com> writes:
will> Software Scavenger wrote:
>> Is anyone from Xanalys reading this? I'm curious how many Lisp
>> programmers they have and how often this forum gets visited by one or
>> more of them.
will> And out of those how many would want to publically announce this. I'm
will> not sure I would.
I know there's at least one person who reads c.l.l at least once in a
while because he's posted messages.
Ray