Hello everyone. Honestly, I don't know how to throw in the question,
but here it goes:
Will learning Assembly make me a better Lisp programmer?
Thanks.
ebzzry wrote:
> Hello everyone. Honestly, I don't know how to throw in the question,
> but here it goes:
>
> Will learning Assembly make me a better Lisp programmer?
>
> Thanks.
>
>
Certainly. The more languages you know, the more ways you should be able
to think about solving a problem. Lisp is rather docile and allows you
to solve problems in many different ways so you may be able to profit
from various insights. Learning assembly-level coding might cause you to
concentrate on data flow strategies, issues of precision, and data
representations and layout. It is often possible (depends a lot on the
assembler) to write assembly code that is as highly modularized and well
organized as code in a higher level language. The advantage of Lisp is
that it allows you many ways to modularize and organize using built-in
capabilities. However, we all need fresh sources of ideas of how we
might structure our codes to advantage.
-- Jeff Barnett
(message (Hello 'ebzzry)
(you :wrote :on '(Sat, 07 Jul 2007 13:23:36 -0000))
(
e> Hello everyone. Honestly, I don't know how to throw in the question,
e> but here it goes:
e> Will learning Assembly make me a better Lisp programmer?
hmm, you mean x86 assembly language?
it can help you understand output of Lisp's DISASSEMBLE function output :)
may be good for optimizing code, or if you're involed into Common Lisp
implementation development..
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"scorn")
"Alex Mizrahi" <········@users.sourceforge.net> writes:
> (message (Hello 'ebzzry)
> (you :wrote :on '(Sat, 07 Jul 2007 13:23:36 -0000))
> (
>
> e> Hello everyone. Honestly, I don't know how to throw in the question,
> e> but here it goes:
>
> e> Will learning Assembly make me a better Lisp programmer?
>
> hmm, you mean x86 assembly language?
>
> it can help you understand output of Lisp's DISASSEMBLE function output :)
> may be good for optimizing code, or if you're involed into Common Lisp
> implementation development..
Since I am working with numerical code and need to optimize
frequently, I have been meaning to ask this question: is it possible
(or beneficial) to learn "enough" asm to understand the output of
disassemble? What would be a good place to start?
Thanks,
Tamas
Tamas Papp <······@gmail.com> writes:
> "Alex Mizrahi" <········@users.sourceforge.net> writes:
>
>> (message (Hello 'ebzzry)
>> (you :wrote :on '(Sat, 07 Jul 2007 13:23:36 -0000))
>> (
>>
>> e> Hello everyone. Honestly, I don't know how to throw in the question,
>> e> but here it goes:
>>
>> e> Will learning Assembly make me a better Lisp programmer?
>>
>> hmm, you mean x86 assembly language?
>>
>> it can help you understand output of Lisp's DISASSEMBLE function output :)
>> may be good for optimizing code, or if you're involed into Common Lisp
>> implementation development..
>
> Since I am working with numerical code and need to optimize
> frequently, I have been meaning to ask this question: is it possible
> (or beneficial) to learn "enough" asm to understand the output of
> disassemble? What would be a good place to start?
This is a more directed question than the original poster's, and has a
"yes" answer (I don't know how to answer the original question,
because it calls for a subjective analysis).
If you have Allegro CL, and can use the Runtime Analyzer (it is a
statistical profiler, as opposed to a call-counting profiler), you can
then learn enough assembler to help you understand where your program
is spending all of its time. Several rules to follow:
1. Be sure all of the code is compiled. Many people make the mistake
of doing something like (prof:with-profiling () (dotimes (i 1000000) ...))
and scratch their heads when they can't figure out what the profiler
is saying (it's telling them that they are spending all of their time
in the interpreter, because Allegro CL does not compile code unless
you ask it to). Instead do something like this:
(compile
(defun test (n)
(dotimes (i n) ... )))
(prof:with-profiling () (test 1000000))
2. Get both the flat profiles and the call-graphs - they both have
their uses. (prof:show-flat-profile) for the first, and
(prof:show-call-graph) for the second. The flat profile will tell you
what functions are high on the list, and the call-graph will show you
what functions call what others. Note that the call-graph is arranged
by "frames", where each frame is a function (unindented) preceded by
its callers (if any) and succeeded by its callees (if any), in the
order in which they are found to be calling or called-by the function.
And you can ask for an individual frame from the call-graph by asking
it by name - so if function bas is called by foo twice as often as it
is called by function bar, and if bas calls bam for 60% of its time
and bleep for 20%, then you can see that by saying
(prof:show-call-graph :name 'bas) and it will show you bas's frame
with foo at the top and bleep at the bottom.
3. Note that some names in the output are symbols, some are list
structures, and some are strings. The symbols are simple function
names, the lists are what we call "function specs" [(setf foo) is an
example; see
http://www.franz.com/support/documentation/8.0/doc/implementation.htm#function-specs-1
for more details], and the strings are functions in the lisp's symbol
table - either C functions (like "printf") or "runtime system" functions
(like "qcons"). All of these names can be used in most Runtime
Analyzer functionality - e.g. as the :name argument of
prof:show-call-graph. Just prepend a ' before the symbol or list (you
can do so for the string but it isn't needed).
4. Finally, as the target of this response, you can call a function
called prof:disassemble-profile. d-p is like disassemble, except that
it moves the output over to the right, and in the left-hand column it
inserts two items: an integer representing the number of "hits" for
this instruction (the number of times the program counter was at this
instruction when the sampler stopped to take a measurement), and the
percentage of all hits in this function that this instruction
represents. Note that since this is a statistical profiler, the
accuracy is better as the number of samples increases. If you get
enough samples, you can see by the distribution how much time is being
spent in each instruction (it is usually the instruction before the
hit that causes the delay). Also, be aware that when a hit is just
after a call instruction (its name is "call" on x86 and x86-64, "jmpl"
on sparcs, "jsr" on alpha, etc), it is likely that the actual hit
occurred further "up" the stack (closer to the stack frontier, where
the stack pointer is) and this function was simply recorded as one of
the functions on the stack at the time of the hit. In other words,
the real action is happening in functions that this function has
called, at the top of the stack.
I believe that by following these steps you will have a good incentive
to learn what assembler/architecture you need in order to optimize
your programs. Of course, you will have to use manuals for the
architecure(s) you want to learn, but since our runtime analyzer is
consistent across platforms in the way it deals with hits, you should
be able to recognize patterns by it on each archiecture you try.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Tamas Papp wrote:
> Since I am working with numerical code and need to optimize
> frequently, I have been meaning to ask this question: is it possible
> (or beneficial) to learn "enough" asm to understand the output of
> disassemble? What would be a good place to start?
I don't think that learning assembler helps you very much to optimize Lisp
code, because it is difficult to predict which changes causes faster output
and it is difficult to predict the speed of a given program, because it
depends on memory usage, cache, CPU type etc. Just profile the code and if
you need faster code, implement it in C, or use some of the extensions of
your Lisp implementation, e.g. the optimized int32* functions in LispWorks,
or use SBCL, which produces fast code, too.
If you really want to learn assembly, it depends on the architecture. E.g.
ARM and x86 instruction sets are very different. Try to ask in the
appropriate newsgroup or http://www.google.com/search?q=x86+tutorial
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
Frank Buss <··@frank-buss.de> writes:
I broke up this paragraph to illustrate a point. I implied this point
to the same person you answered, but it bears repeating and expanding
here by itself:
> I don't think that learning assembler helps you very much to optimize Lisp
> code, because it is difficult to predict which changes causes faster output
> and it is difficult to predict the speed of a given program, because it
> depends on memory usage, cache, CPU type etc.
> Just profile the code and if
> you need faster code, implement it in C, or use some of the extensions of
> your Lisp implementation, e.g. the optimized int32* functions in LispWorks,
> or use SBCL, which produces fast code, too.
These two statements only go together if you don't have a statistical
profiler. It is one of the reasons why we renamed our profiler and
now call it a "runtime analyzer". It distinguishes this kind of
profiling from the typical call-counting that occurs in many lisps - I
know that some lisps do indeed have statistical profilers, but usually
when someone talks about profiling, they are referring to a
call-counting profiler, or if they are referring to a statistical profiler
which cannot merge its output with its disassembler, then there is no
way to measure instruction latencies empirically, and your statements
follow. But when you _do_ have a statistical profiler, and can get
enough samples to be statistically significant, then the picture the
profiler paints does indeed show instruction latencies and cache
effects, etc. It takes some getting used to the reading of it, and
you have to understand how statistical sampling works (and its
limitations) but it is amazing how much you can understand of a
program's inherent interaction with the architecture it is running on
when these tools are available, _and_ because one of these tools
involves reading assembler code, it does indeed make sense to
undertand assembler to a certain extent.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> These two statements only go together if you don't have a statistical
> profiler.
you are right, I had a simple (time (loop repeat 10000 do (foo))) in mind.
With a statistical profiler, which maybe annotates individual assembly
lines, it might help to understand the assembly code :-)
--
Frank Buss, ··@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
(message (Hello 'Tamas)
(you :wrote :on '(Sat, 07 Jul 2007 16:13:22 +0200))
(
TP> Since I am working with numerical code and need to optimize
TP> frequently, I have been meaning to ask this question: is it possible
TP> (or beneficial) to learn "enough" asm to understand the output of
TP> disassemble?
yes, i think i know asm that way -- i've wrote only few programs in pure
assembly, i've wrote a little more procedures in pure assembly for speed,
but i mainly use it to learn what does compiler do to optimize code, etc.
(although i was mostly dealing with C/C++, do not have much Common Lisp
optimization experience yet).
as Duane has wrote, this typically makes sense with a statistical profiler
displaying low-level information. and not only assembly code semantics
should be taken in account, but also architecture detals -- cache sizes etc.
TP> What would be a good place to start?
i was learning this by small bits, so can't help much here.. i think you can
start getting disassembly and googling for assembler mnemonics you see
there.
as for architecture details, Wikipedia can be used as a start for getting
infromation -- it has both some processor specs and explanations of terms.
)
(With-best-regards '(Alex Mizrahi) :aka 'killer_storm)
"scorn")
Alex Mizrahi <········@users.sourceforge.net> wrote on Sunday 08 July 2007
05:31 in comp.lang.lisp <·························@news.sunsite.dk>:
> i was learning this by small bits, so can't help much here.. i think you
> can start getting disassembly and googling for assembler mnemonics you see
> there.
Assuming you are using an x86 chip, the documentation that comes with NASM
has a /very/ large appendix that contains somewhat detailed descriptions of
a large number of opcodes implemented by x86 chips from the 8088 to the
modern Pentiums and Pentium clones. I find it more concise and more
readable than Intel's documentation, particularly since it isn't concerned
with any of the more bizarre semantics most people will never need to know.
<http://nasm.sourceforge.net/>
<http://sourceforge.net/docman/display_doc.php?docid=47259&group_id=6208>
or
<http://tinyurl.com/2sfsuj>
--
My address happens to be com (dot) gmail (at) usenet (plus) chbarts,
wardsback and translated.
It's in my header if you need a spoiler.
On Jul 7, 8:23 am, ebzzry <······@gmail.com> wrote:
> Hello everyone. Honestly, I don't know how to throw in the question,
> but here it goes:
>
> Will learning Assembly make me a better Lisp programmer?
>
> Thanks.
God. I hope not.