Although I am not a good student, I got a scholarship from a grant to
study global warming. The principal scientist, Mrs Magda Lombardo, is
a geographer, and has no deep understanding of Computer Science.
Therefore, people asked me to evaluate Common Lisp compilers for
Windows. The task is number crunching, and most programs are ready to
go. The programs have large arrays with atmospheric radiative transfer
models. The idea is to collect ground truth data of temperature (from
volunteers), and use them together with radiative transfer models to
obtain temperature maps from satellite infrared images.
I tested the programs with a Rama toy example. For people who are not
familiar with the field, let me explain what I mean. Rama is a giant
spacecraft from a novel by Arthur C. Clark. It has the shape of a
cilinder that turns around its axis in order to create artificial
gravity. People use Rama toy models as benchmarks in meteorology and
radiative transfer.
My results are the following:
1 --- SBCL is very fast, and produces the answer in a few seconds.
C:\ACL81-~1\testes\project1>sbcl --noinform
* (load "sec.lisp")
T
* (rama)
Evaluation took:
31.781 seconds of real time
31.781250 seconds of total run time (22.296875 user, 9.484375
system)
[ Run times consist of 5.850 seconds GC time, and 25.932 seconds non-
GC time.
]
100.00% CPU
76,281,960,024 processor cycles
6,400,024,088 bytes consed
2 --- Clozure is about 40% slower than SBCL.
C:\clozure>wx86cl.exe
Welcome to Clozure Common Lisp Version 1.3-dev-r11537M-trunk
(WindowsX8632)!
? (compile-file "sec.lisp")
#P"C:/clozure/sec.wx32fsl"
NIL
NIL
? (load "sec.wx32fsl")
#P"C:/clozure/sec.wx32fsl"
? (rama)
(DOTIMES (I 2000) (RADIATIVE-TRANSFER)) took 52,000 milliseconds
(52.000 seconds
) to run
with 4 available CPU cores.
During that period, 51,828 milliseconds (51.828 seconds) were spent in
user mode
219 milliseconds (0.219 seconds) were spent in
system mode
34,109 milliseconds (34.109 seconds) was spent in GC.
2,105,032,704 bytes of memory allocated.
NIL
3 --- My question is about Allegro Common Lisp. I still do not have
one, but I requested two copies of Allegro CL. However, I am using a
free copy that one of the scientists of the group downloaded. The free
copy has the following behavior:
[1] REGEXP(1): (COMMON-LISP-USER::RAMA)
8430480 bytes have been tenured, next gc will be global.
See the documentation for variable *GLOBAL-GC-BEHAVIOR* for more
information.
8430480 bytes have been tenured, next gc will be global.
... SNIP ...
; cpu time (non-gc) 37,420 msec user, 47 msec system
; cpu time (gc) 161,548 msec (00:02:41.548) user, 125 msec system
; cpu time (total) 198,968 msec (00:03:18.968) user, 172 msec system
; real time 203,406 msec (00:03:23.406)
; space allocation:
; 57,544 cons cells, 1,010,408,000 other bytes, 0 static bytes
NIL
[Current process: Initial Lisp Listener]
[1] REGEXP(2):
I suppose that this bad behavior is due to my using a trial version.
Once I get the unrestricted copy, it will be as fast as fast as SBCL.
Is it true? There is another problem. In order to run Rama toy, it
was necessary to fix the code for Allegro. Allegro does not accept
proclaim, and constants the way it is declared for other lisps. The
problem is that I am not allowed to modify the real code (for Earth).
Does the unrestricted version accepts normal Common Lisp code? By
normal, I mean CL of SBCL, CMUCL and Clozure.
On Mar 11, 8:37 am, "comp.lang.scheme" <········@yahoo.ca> wrote:
> Although I am not a good student, I got a scholarship from a grant to
> study global warming.
Lucky you! ;)
Now seriously, it would be fair you give LispWorks a try and
-if you don't need threads- also CLISP.
Of course, always compiling your code (which is unnecessary in both
sbcl and ccl).
If you do, please post the performance achieved.
NOTE: Try also using Linux instead of slower operating systems.
On Mar 11, 5:05 am, ·······@eurogaran.com wrote:
> On Mar 11, 8:37 am, "comp.lang.scheme" <········@yahoo.ca> wrote:> Although I am not a good student, I got a scholarship from a grant to
> > study global warming.
>
> Lucky you! ;)
> Now seriously, it would be fair you give LispWorks a try and
The 64-bit version of LispWorks is reputed to be significantly faster
than the 32-bit version, so try the 64-bit version for a fair
comparison. You may need to talk to the lispworks people for a trial
license as the free version may only be 32-bit.
I'll note in advance that I expect that sbcl will show the all-around
fastest times for number crunching without optimization. However, all
of allegro, lispworks and clozure can be just as fast or faster with
the appropriate optimiztion declarations. If you can, you may want to
post some of your test code here for optimization, just to double
check you have the necessary declarations.
And as has been mentioned, make sure you put your test code in a file,
and then compile-file and load the fasl.
Finally, I'll mention the GUI issue. If you need now, or may possibly
need in the future, a lisp that can quickly put together a nice
graphical interface around your simulation code, the you definitely
want to look very seriously at LispWorks and Franz Allegro Common
Lisp. Both have GUI builders on Windows, and LispWorks GUI code is
portable across Windows, Mac OS X, and Linux. This means you could
develop code and a GUI on Windows and have it run unchanged on Mac OS
X and Linux if the need ever arises. Nice option to have.
On 11 mar, 10:43, Raffael Cavallaro <················@gmail.com>
wrote:
> On Mar 11, 5:05 am, ·······@eurogaran.com wrote:
>
> > On Mar 11, 8:37 am, "comp.lang.scheme" <········@yahoo.ca> wrote:> Although I am not a good student, I got a scholarship from a grant to
> > > study global warming.
>
> > Lucky you! ;)
> > Now seriously, it would be fair you give LispWorks a try and
>
> The 64-bit version of LispWorks is reputed to be significantly faster
> than the 32-bit version, so try the 64-bit version for a fair
> comparison. You may need to talk to the lispworks people for a trial
> license as the free version may only be 32-bit.
>
> I'll note in advance that I expect that sbcl will show the all-around
> fastest times for number crunching without optimization. However, all
> of allegro, lispworks and clozure can be just as fast or faster with
> the appropriate optimiztion declarations. If you can, you may want to
> post some of your test code here for optimization, just to double
> check you have the necessary declarations.
>
> And as has been mentioned, make sure you put your test code in a file,
> and then compile-file and load the fasl.
>
> Finally, I'll mention the GUI issue. If you need now, or may possibly
> need in the future, a lisp that can quickly put together a nice
> graphical interface around your simulation code, the you definitely
> want to look very seriously at LispWorks and Franz Allegro Common
> Lisp. Both have GUI builders on Windows, and LispWorks GUI code is
> portable across Windows, Mac OS X, and Linux. This means you could
> develop code and a GUI on Windows and have it run unchanged on Mac OS
> X and Linux if the need ever arises. Nice option to have.
In fact, I have access to a portable GUI for SBCL, that is working
very well. The project needs a GUI. The reason: To show infrared
images. Most people who will use the results of heat island studies
are not computer scientists. BTW, I believe that computer scientists
don't even know what is a heat island. I didn't until January 2009.
Would you like to take a look at the GUI for SBCL? It is for Windows,
but it works on Linux too. If you can take a look at the GUI for me,
and explain what will be the advantage of using LispWorks or ACL, I
will be greatful.
On 11 mar, 06:05, ·······@eurogaran.com wrote:
> On Mar 11, 8:37 am, "comp.lang.scheme" <········@yahoo.ca> wrote:> Although I am not a good student, I got a scholarship from a grant to
> > study global warming.
>
> Lucky you! ;)
> Now seriously, it would be fair you give LispWorks a try and
> -if you don't need threads- also CLISP.
> Of course, always compiling your code (which is unnecessary in both
> sbcl and ccl).
> If you do, please post the performance achieved.
> NOTE: Try also using Linux instead of slower operating systems.
Hi,
Kodi.
I always compile my code. I am very careful about it. Without
compilation, even a toy program like Rama takes minutes to run. I
tried CLISP, but it is very slow, but I use it to do my AI projects. I
will ask Dr. Lombardo to buy a copy os LispWorks (I am not sure
whether she will).
"comp.lang.scheme" <········@yahoo.ca> writes:
> 3 --- My question is about Allegro Common Lisp. I still do not have
> one, but I requested two copies of Allegro CL. However, I am using a
> free copy that one of the scientists of the group downloaded. The free
> copy has the following behavior:
>
> [1] REGEXP(1): (COMMON-LISP-USER::RAMA)
> 8430480 bytes have been tenured, next gc will be global.
> See the documentation for variable *GLOBAL-GC-BEHAVIOR* for more
> information.
> 8430480 bytes have been tenured, next gc will be global.
> ... SNIP ...
> ; cpu time (non-gc) 37,420 msec user, 47 msec system
> ; cpu time (gc) 161,548 msec (00:02:41.548) user, 125 msec system
> ; cpu time (total) 198,968 msec (00:03:18.968) user, 172 msec system
> ; real time 203,406 msec (00:03:23.406)
> ; space allocation:
> ; 57,544 cons cells, 1,010,408,000 other bytes, 0 static bytes
> NIL
> [Current process: Initial Lisp Listener]
> [1] REGEXP(2):
>
> I suppose that this bad behavior is due to my using a trial version.
I don't see where you compiled the code.
Perhaps Allegro just interprets your code.
> Once I get the unrestricted copy, it will be as fast as fast as SBCL.
> Is it true?
I'd think that indeed, when compiled, Allegro will be as fast or
faster than SBCL.
> There is another problem. In order to run Rama toy, it
> was necessary to fix the code for Allegro. Allegro does not accept
> proclaim, and constants the way it is declared for other lisps. The
> problem is that I am not allowed to modify the real code (for Earth).
> Does the unrestricted version accepts normal Common Lisp code? By
> normal, I mean CL of SBCL, CMUCL and Clozure.
You should give us the actual error message. Perhaps there's a
PROCLAIM for an undeclared declaration?
--
__Pascal Bourguignon__
On 11 mar, 05:43, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> "comp.lang.scheme" <········@yahoo.ca> writes:
> > 3 --- My question is about Allegro Common Lisp. I still do not have
> > one, but I requested two copies of Allegro CL. However, I am using a
> > free copy that one of the scientists of the group downloaded. The free
> > copy has the following behavior:
>
> > [1] REGEXP(1): (COMMON-LISP-USER::RAMA)
> > 8430480 bytes have been tenured, next gc will be global.
> > See the documentation for variable *GLOBAL-GC-BEHAVIOR* for more
> > information.
> > 8430480 bytes have been tenured, next gc will be global.
> > ... SNIP ...
> > ; cpu time (non-gc) 37,420 msec user, 47 msec system
> > ; cpu time (gc) 161,548 msec (00:02:41.548) user, 125 msec system
> > ; cpu time (total) 198,968 msec (00:03:18.968) user, 172 msec system
> > ; real time 203,406 msec (00:03:23.406)
> > ; space allocation:
> > ; 57,544 cons cells, 1,010,408,000 other bytes, 0 static bytes
> > NIL
> > [Current process: Initial Lisp Listener]
> > [1] REGEXP(2):
>
> > I suppose that this bad behavior is due to my using a trial version.
>
> I don't see where you compiled the code.
> Perhaps Allegro just interprets your code.
>
> > Once I get the unrestricted copy, it will be as fast as fast as SBCL.
> > Is it true?
>
> I'd think that indeed, when compiled, Allegro will be as fast or
> faster than SBCL.
>
> > There is another problem. In order to run Rama toy, it
> > was necessary to fix the code for Allegro. Allegro does not accept
> > proclaim, and constants the way it is declared for other lisps. The
> > problem is that I am not allowed to modify the real code (for Earth).
> > Does the unrestricted version accepts normal Common Lisp code? By
> > normal, I mean CL of SBCL, CMUCL and Clozure.
>
> You should give us the actual error message. Perhaps there's a
> PROCLAIM for an undeclared declaration?
>
> --
> __Pascal Bourguignon__
Hi, Pascal.
In the case of 'proclaim' an error message pops up with the following
message (the name of the Rama toy is sec.lisp):
(TOP-LEVEL-FORM sec.lisp 64) in C:\acl81-express\toyrama
\project1\sec.lisp
compile-file found "PROCLAIM" at the top level -- see the
documentation for
comp:*cltl1-compile-file-toplevel-compatibility-p*
All errors are warnings. If I ignore them, the compiler generates
code, but the code becomes slow. Allegro is very fast if I do not
ignore the warnings.
"comp.lang.scheme" <········@yahoo.ca> writes:
> [...]
> In the case of 'proclaim' an error message pops up with the following
> message (the name of the Rama toy is sec.lisp):
>
> (TOP-LEVEL-FORM sec.lisp 64) in C:\acl81-express\toyrama
> \project1\sec.lisp
> compile-file found "PROCLAIM" at the top level -- see the
> documentation for
> comp:*cltl1-compile-file-toplevel-compatibility-p*
>
> All errors are warnings. If I ignore them, the compiler generates
> code, but the code becomes slow. Allegro is very fast if I do not
> ignore the warnings.
So have you read the documentation for
comp:*cltl1-compile-file-toplevel-compatibility-p* ?
--
__Pascal Bourguignon__
On 12 mar, 04:03, ····@informatimago.com (Pascal J. Bourguignon)
wrote:
> "comp.lang.scheme" <········@yahoo.ca> writes:
> > [...]
> > In the case of 'proclaim' an error message pops up with the following
> > message (the name of the Rama toy is sec.lisp):
>
> > (TOP-LEVEL-FORM sec.lisp 64) in C:\acl81-express\toyrama
> > \project1\sec.lisp
> > compile-file found "PROCLAIM" at the top level -- see the
> > documentation for
> > comp:*cltl1-compile-file-toplevel-compatibility-p*
>
> > All errors are warnings. If I ignore them, the compiler generates
> > code, but the code becomes slow. Allegro is very fast if I do not
> > ignore the warnings.
>
> So have you read the documentation for
> comp:*cltl1-compile-file-toplevel-compatibility-p* ?
>
> --
> __Pascal Bourguignon__
Hi, Pascal.
Sorry, but I didn't read the documentation. As people know in this
list, and in Scheme list, I am a lazy student. I never read
documentation. I like to read books, like Winston's book, Successful
Lisp, Practical Common Lisp, On Lisp, etc. As for documentation, I
think it is boring. In any case, since I have two versions of Lisp
that are working properly for the kind of problem I am dealing with
(SBCL and Clozure), I belive that I can pospone the documentation for
a few months. I ordered Allegro just in case... As for LispWork, I
think I will do without it, since it is very expensive.
On Fri, 13 Mar 2009 20:21:17 -0700 (PDT), "comp.lang.scheme"
<········@yahoo.ca> wrote:
>>[...]
>
>Hi, Pascal.
>Sorry, but I didn't read the documentation. As people know in this
>list, and in Scheme list, I am a lazy student. I never read
>documentation. I like to read books, like Winston's book, Successful
>Lisp, Practical Common Lisp, On Lisp, etc. As for documentation, I
>think it is boring....
You need to read Documentation In Small Pieces ;) .
-- Benjamin L. Russell
--
Benjamin L. Russell / DekuDekuplex at Yahoo dot com
http://dekudekuplex.wordpress.com/
Translator/Interpreter / Mobile: +011 81 80-3603-6725
"Furuike ya, kawazu tobikomu mizu no oto."
-- Matsuo Basho^
Hi,
Can you post link to the source code, if it's okay for public to view.
I'm willing to help you speeding it out (I do have AllegroCL and
Lispworks commercial license - though only for 32-bit).
One thing that ACL does not have for example is function inlining, which
is actually okay in most cases. It really could be something that was
not specialized, or bad case usage.
Thanks,
Dimiter "malkia" Stanev.
comp.lang.scheme wrote:
> Although I am not a good student, I got a scholarship from a grant to
> study global warming. The principal scientist, Mrs Magda Lombardo, is
> a geographer, and has no deep understanding of Computer Science.
> Therefore, people asked me to evaluate Common Lisp compilers for
> Windows. The task is number crunching, and most programs are ready to
> go. The programs have large arrays with atmospheric radiative transfer
> models. The idea is to collect ground truth data of temperature (from
> volunteers), and use them together with radiative transfer models to
> obtain temperature maps from satellite infrared images.
>
> I tested the programs with a Rama toy example. For people who are not
> familiar with the field, let me explain what I mean. Rama is a giant
> spacecraft from a novel by Arthur C. Clark. It has the shape of a
> cilinder that turns around its axis in order to create artificial
> gravity. People use Rama toy models as benchmarks in meteorology and
> radiative transfer.
>
> My results are the following:
>
> 1 --- SBCL is very fast, and produces the answer in a few seconds.
>
> C:\ACL81-~1\testes\project1>sbcl --noinform
> * (load "sec.lisp")
>
> T
> * (rama)
>
> Evaluation took:
> 31.781 seconds of real time
> 31.781250 seconds of total run time (22.296875 user, 9.484375
> system)
> [ Run times consist of 5.850 seconds GC time, and 25.932 seconds non-
> GC time.
> ]
> 100.00% CPU
> 76,281,960,024 processor cycles
> 6,400,024,088 bytes consed
>
>
> 2 --- Clozure is about 40% slower than SBCL.
>
> C:\clozure>wx86cl.exe
> Welcome to Clozure Common Lisp Version 1.3-dev-r11537M-trunk
> (WindowsX8632)!
> ? (compile-file "sec.lisp")
> #P"C:/clozure/sec.wx32fsl"
> NIL
> NIL
> ? (load "sec.wx32fsl")
> #P"C:/clozure/sec.wx32fsl"
> ? (rama)
> (DOTIMES (I 2000) (RADIATIVE-TRANSFER)) took 52,000 milliseconds
> (52.000 seconds
> ) to run
> with 4 available CPU cores.
> During that period, 51,828 milliseconds (51.828 seconds) were spent in
> user mode
>
> 219 milliseconds (0.219 seconds) were spent in
> system mode
> 34,109 milliseconds (34.109 seconds) was spent in GC.
> 2,105,032,704 bytes of memory allocated.
> NIL
>
> 3 --- My question is about Allegro Common Lisp. I still do not have
> one, but I requested two copies of Allegro CL. However, I am using a
> free copy that one of the scientists of the group downloaded. The free
> copy has the following behavior:
>
> [1] REGEXP(1): (COMMON-LISP-USER::RAMA)
> 8430480 bytes have been tenured, next gc will be global.
> See the documentation for variable *GLOBAL-GC-BEHAVIOR* for more
> information.
> 8430480 bytes have been tenured, next gc will be global.
> ... SNIP ...
> ; cpu time (non-gc) 37,420 msec user, 47 msec system
> ; cpu time (gc) 161,548 msec (00:02:41.548) user, 125 msec system
> ; cpu time (total) 198,968 msec (00:03:18.968) user, 172 msec system
> ; real time 203,406 msec (00:03:23.406)
> ; space allocation:
> ; 57,544 cons cells, 1,010,408,000 other bytes, 0 static bytes
> NIL
> [Current process: Initial Lisp Listener]
> [1] REGEXP(2):
>
> I suppose that this bad behavior is due to my using a trial version.
> Once I get the unrestricted copy, it will be as fast as fast as SBCL.
> Is it true? There is another problem. In order to run Rama toy, it
> was necessary to fix the code for Allegro. Allegro does not accept
> proclaim, and constants the way it is declared for other lisps. The
> problem is that I am not allowed to modify the real code (for Earth).
> Does the unrestricted version accepts normal Common Lisp code? By
> normal, I mean CL of SBCL, CMUCL and Clozure.
On 11 mar, 14:48, "Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
> Hi,
>
> Can you post link to the source code, if it's okay for public to view.
>
> I'm willing to help you speeding it out (I do have AllegroCL and
> Lispworks commercial license - though only for 32-bit).
>
> One thing that ACL does not have for example is function inlining, which
> is actually okay in most cases. It really could be something that was
> not specialized, or bad case usage.
>
> Thanks,
> Dimiter "malkia" Stanev.
>
> comp.lang.scheme wrote:
> > Although I am not a good student, I got a scholarship from a grant to
> > study global warming. The principal scientist, Mrs Magda Lombardo, is
> > a geographer, and has no deep understanding of Computer Science.
> > Therefore, people asked me to evaluate Common Lisp compilers for
> > Windows. The task is number crunching, and most programs are ready to
> > go. The programs have large arrays with atmospheric radiative transfer
> > models. The idea is to collect ground truth data of temperature (from
> > volunteers), and use them together with radiative transfer models to
> > obtain temperature maps from satellite infrared images.
>
> > I tested the programs with a Rama toy example. For people who are not
> > familiar with the field, let me explain what I mean. Rama is a giant
> > spacecraft from a novel by Arthur C. Clark. It has the shape of a
> > cilinder that turns around its axis in order to create artificial
> > gravity. People use Rama toy models as benchmarks in meteorology and
> > radiative transfer.
>
> > My results are the following:
>
> > 1 --- SBCL is very fast, and produces the answer in a few seconds.
>
> > C:\ACL81-~1\testes\project1>sbcl --noinform
> > * (load "sec.lisp")
>
> > T
> > * (rama)
>
> > Evaluation took:
> > 31.781 seconds of real time
> > 31.781250 seconds of total run time (22.296875 user, 9.484375
> > system)
> > [ Run times consist of 5.850 seconds GC time, and 25.932 seconds non-
> > GC time.
> > ]
> > 100.00% CPU
> > 76,281,960,024 processor cycles
> > 6,400,024,088 bytes consed
>
> > 2 --- Clozure is about 40% slower than SBCL.
>
> > C:\clozure>wx86cl.exe
> > Welcome to Clozure Common Lisp Version 1.3-dev-r11537M-trunk
> > (WindowsX8632)!
> > ? (compile-file "sec.lisp")
> > #P"C:/clozure/sec.wx32fsl"
> > NIL
> > NIL
> > ? (load "sec.wx32fsl")
> > #P"C:/clozure/sec.wx32fsl"
> > ? (rama)
> > (DOTIMES (I 2000) (RADIATIVE-TRANSFER)) took 52,000 milliseconds
> > (52.000 seconds
> > ) to run
> > with 4 available CPU cores.
> > During that period, 51,828 milliseconds (51.828 seconds) were spent in
> > user mode
>
> > 219 milliseconds (0.219 seconds) were spent in
> > system mode
> > 34,109 milliseconds (34.109 seconds) was spent in GC.
> > 2,105,032,704 bytes of memory allocated.
> > NIL
>
> > 3 --- My question is about Allegro Common Lisp. I still do not have
> > one, but I requested two copies of Allegro CL. However, I am using a
> > free copy that one of the scientists of the group downloaded. The free
> > copy has the following behavior:
>
> > [1] REGEXP(1): (COMMON-LISP-USER::RAMA)
> > 8430480 bytes have been tenured, next gc will be global.
> > See the documentation for variable *GLOBAL-GC-BEHAVIOR* for more
> > information.
> > 8430480 bytes have been tenured, next gc will be global.
> > ... SNIP ...
> > ; cpu time (non-gc) 37,420 msec user, 47 msec system
> > ; cpu time (gc) 161,548 msec (00:02:41.548) user, 125 msec system
> > ; cpu time (total) 198,968 msec (00:03:18.968) user, 172 msec system
> > ; real time 203,406 msec (00:03:23.406)
> > ; space allocation:
> > ; 57,544 cons cells, 1,010,408,000 other bytes, 0 static bytes
> > NIL
> > [Current process: Initial Lisp Listener]
> > [1] REGEXP(2):
>
> > I suppose that this bad behavior is due to my using a trial version.
> > Once I get the unrestricted copy, it will be as fast as fast as SBCL.
> > Is it true? There is another problem. In order to run Rama toy, it
> > was necessary to fix the code for Allegro. Allegro does not accept
> > proclaim, and constants the way it is declared for other lisps. The
> > problem is that I am not allowed to modify the real code (for Earth).
> > Does the unrestricted version accepts normal Common Lisp code? By
> > normal, I mean CL of SBCL, CMUCL and Clozure.
>
>
Hi, Dimiter.
The code is gigantic, and I do not know how to get it from the
Internet. However, most of it is data. There is very litle real code.
Therefore, I belive that I can filter the code out of it. This will be
for the fun of it, of course. I cannot use the modified code. Since I
will learn a lot from you, I am ready to do this kind of work. The
Model is designed to eliminate atmospheric effects with respect to
thermal infrared, visible and near infrared bands. Sensor errors are
due to noises roughly classified into 3 categories: (1) noises derived
from ability of a sensor, (2) geometrical distortions, and (3)
atmospheric effects. We are interested in atmospheric effects.
After small terms of Chandra's equation, one needs to resolve the
following double integral ( will give it in LaTeX; compile it and you
will get the equation):
$$I_{obs}= \int_{\phi 1}^{\phi 2}
\int_{\mu 1}^{\mu 2}\int_{\nu 1}^{\nu 2}
R{\nu}\left[\varepsilon_{earth\nu}B_{\nu}
T_{earth}e^{-\eta/\mu}+\int_0^{t1}\varepsilon_{air\nu}
B_{\nu}(T_{air}e^{-t/\mu}/\mu dt\right]d\mu d\nu d\phi$$
The model is passed as parameter to the integration function. It is
interesting that Lisp is very good at this kind of number crunching,
since it is necessary to pass a function as parameter to another.
Anyway, if you want to play with this kind of code, and teach me how
to optimize it, I will be glad. I will isolate the working code from
the data, and send it to you with bogus data.
Hi,
> Hi, Dimiter.
> The code is gigantic, and I do not know how to get it from the
> Internet. However, most of it is data. There is very litle real code.
> Therefore, I belive that I can filter the code out of it. This will be
> for the fun of it, of course. I cannot use the modified code. Since I
> will learn a lot from you, I am ready to do this kind of work. The
> Model is designed to eliminate atmospheric effects with respect to
> thermal infrared, visible and near infrared bands. Sensor errors are
> due to noises roughly classified into 3 categories: (1) noises derived
> from ability of a sensor, (2) geometrical distortions, and (3)
> atmospheric effects. We are interested in atmospheric effects.
> After small terms of Chandra's equation, one needs to resolve the
> following double integral ( will give it in LaTeX; compile it and you
> will get the equation):
>
> $$I_{obs}= \int_{\phi 1}^{\phi 2}
> \int_{\mu 1}^{\mu 2}\int_{\nu 1}^{\nu 2}
> R{\nu}\left[\varepsilon_{earth\nu}B_{\nu}
> T_{earth}e^{-\eta/\mu}+\int_0^{t1}\varepsilon_{air\nu}
> B_{\nu}(T_{air}e^{-t/\mu}/\mu dt\right]d\mu d\nu d\phi$$
>
> The model is passed as parameter to the integration function. It is
> interesting that Lisp is very good at this kind of number crunching,
> since it is necessary to pass a function as parameter to another.
> Anyway, if you want to play with this kind of code, and teach me how
> to optimize it, I will be glad. I will isolate the working code from
> the data, and send it to you with bogus data.
If you provide me with even minimal working code that need
optimizations, I'll gladly help.
I still consider myself newbie in Common Lisp, but have been dabbling
with how various implementations generate code underneath, and have
gathered some knowledge. I do know relatively well assembly (x86, and
some mips/risc) so that helps a bit, but I haven't activelly coded in
assembly for a couple of years (even tiny bit of inline assembly).
The way I'll approach your problem is mainly by disassembling, and
profiling.
Sometimes just making sure the lisp compiler doesn't cons would speed up
the things significantly (for example returning floating-point values),
in this case reusing arrays where the results is returned in the first
element of array would be prefferable (although the code would look even
more imperative - almost like assembly :)).
I won't be able to help much if the bottleneck is in the the algorithm,
and I'm not familiar with. For example I lack understanding of heavy
floating-point mathematical code that needs stability. Most of the stuff
I'm doing is really simple 3D geometry stuff (so no big sparse matrices,
etc.). People like Tamas are more experienced there.
So I can't promise anything though :) But it'll be interresting to try!
If you want send me email directly: malkia <at> gmail <dot> com
Thanks,
Dimiter "malkia" Stanev.
On 12 mar, 15:39, "Dimiter \"malkia\" Stanev" <······@mac.com> wrote:
> Hi,
>
>
>
> > Hi, Dimiter.
> > The code is gigantic, and I do not know how to get it from the
> > Internet. However, most of it is data. There is very litle real code.
> > Therefore, I belive that I can filter the code out of it. This will be
> > for the fun of it, of course. I cannot use the modified code. Since I
> > will learn a lot from you, I am ready to do this kind of work. The
> > Model is designed to eliminate atmospheric effects with respect to
> > thermal infrared, visible and near infrared bands. Sensor errors are
> > due to noises roughly classified into 3 categories: (1) noises derived
> > from ability of a sensor, (2) geometrical distortions, and (3)
> > atmospheric effects. We are interested in atmospheric effects.
> > After small terms of Chandra's equation, one needs to resolve the
> > following double integral ( will give it in LaTeX; compile it and you
> > will get the equation):
>
> > $$I_{obs}= \int_{\phi 1}^{\phi 2}
> > \int_{\mu 1}^{\mu 2}\int_{\nu 1}^{\nu 2}
> > R{\nu}\left[\varepsilon_{earth\nu}B_{\nu}
> > T_{earth}e^{-\eta/\mu}+\int_0^{t1}\varepsilon_{air\nu}
> > B_{\nu}(T_{air}e^{-t/\mu}/\mu dt\right]d\mu d\nu d\phi$$
>
> > The model is passed as parameter to the integration function. It is
> > interesting that Lisp is very good at this kind of number crunching,
> > since it is necessary to pass a function as parameter to another.
> > Anyway, if you want to play with this kind of code, and teach me how
> > to optimize it, I will be glad. I will isolate the working code from
> > the data, and send it to you with bogus data.
>
> If you provide me with even minimal working code that need
> optimizations, I'll gladly help.
>
> I still consider myself newbie in Common Lisp, but have been dabbling
> with how various implementations generate code underneath, and have
> gathered some knowledge. I do know relatively well assembly (x86, and
> some mips/risc) so that helps a bit, but I haven't activelly coded in
> assembly for a couple of years (even tiny bit of inline assembly).
>
> The way I'll approach your problem is mainly by disassembling, and
> profiling.
>
> Sometimes just making sure the lisp compiler doesn't cons would speed up
> the things significantly (for example returning floating-point values),
> in this case reusing arrays where the results is returned in the first
> element of array would be prefferable (although the code would look even
> more imperative - almost like assembly :)).
>
> I won't be able to help much if the bottleneck is in the the algorithm,
> and I'm not familiar with. For example I lack understanding of heavy
> floating-point mathematical code that needs stability. Most of the stuff
> I'm doing is really simple 3D geometry stuff (so no big sparse matrices,
> etc.). People like Tamas are more experienced there.
>
> So I can't promise anything though :) But it'll be interresting to try!
>
> If you want send me email directly: malkia <at> gmail <dot> com
>
> Thanks,
> Dimiter "malkia" Stanev.
Hi, Dimiter.
Dr. Lombardo did not ask me to write algorithms. I just need to pick a
good Lisp compiler, compile the programs, and make them ready for her
using. However, I am delighted by the prospect of learning how to
write algorithms. I believe that a good starting point is to make the
basic integration algorithm to work well in Allegro, I mean, produce
the right result. Therefore, I will send you a very basic -- and
small -- algorithm that is working well in Scheme, and my Common Lisp
version of it. You will tell me what I did wrong.
I have another problem that it I would like you to take a look. In
order to calibrate the satellite radiometers, one need to collect
temperature readings from many spots around a city. For this task,
people around here have built small meters connected to computers. The
meters send their readings to a central computer, that calibrates the
satellite. Each meter uses a microcontroller called PIC. I can send
the schematics, pictures, and everything else about this piece of
hardware. I can even put one of them online, so you can read their
outputs from where you are. Reading is performed by a Lisp program,
whose source I will send you.
The code of the microcontroller is generated by a Lisp program. I
would like to learn how to write such a program, and also how to build
the equipment, and how to connect it to the lisp program. Since you
told that you know a lot about assembly, I think you have a lot to
tell me on the subject. I am doing it for fun. There is scanty chance
that Dr. Lombardo will use anything I am likely to build.
As for the equipment, there is two ways we can work with it. I can put
one of them on line for you to test it from your lab. I will send you
a copy of a scheme program, and instructions on how to compile it. I
can even send you the binaries. However, I am sure that you can easily
write an Allegro program that match my Scheme program. Dr. Caparelli
(yes, they are all Italians around here, or have Italian names; I am
the only one with a Greek name :-) have built a very simple and
inexpensive prototype of the temperature reader. I can send you the
schematics, and the Lisp program to make it work. If you have any
difficulty in building the hardware, I can ship you one of the
prototypes.
BTW, I am not a scientist or engineer in the main team. I am just a
student who want to learn. I mean, I am literally an undergrad. I am
not an expert on global warming, or heat islands. I am telling you
this to prevent misunderstandings. I will contact you soon through
your private email address.
On Mar 12, 12:20 am, "comp.lang.scheme" <········@yahoo.ca> wrote:
> I will isolate the working code from
> the data, and send it to you with bogus data.
Just post the working code and the bogus test data here and you'll get
any number of suggestions for optimization both for portable common
lisp code, and for specific implementations.
P� Thu, 12 Mar 2009 05:20:33 +0100, skrev comp.lang.scheme
<········@yahoo.ca>:
>
> Hi, Dimiter.
> The code is gigantic, and I do not know how to get it from the
> Internet. However, most of it is data. There is very litle real code.
> Therefore, I belive that I can filter the code out of it. This will be
> for the fun of it, of course. I cannot use the modified code. Since I
> will learn a lot from you, I am ready to do this kind of work. The
> Model is designed to eliminate atmospheric effects with respect to
> thermal infrared, visible and near infrared bands. Sensor errors are
> due to noises roughly classified into 3 categories: (1) noises derived
> from ability of a sensor, (2) geometrical distortions, and (3)
> atmospheric effects. We are interested in atmospheric effects.
> After small terms of Chandra's equation, one needs to resolve the
> following double integral ( will give it in LaTeX; compile it and you
> will get the equation):
>
> $$I_{obs}= \int_{\phi 1}^{\phi 2}
> \int_{\mu 1}^{\mu 2}\int_{\nu 1}^{\nu 2}
> R{\nu}\left[\varepsilon_{earth\nu}B_{\nu}
> T_{earth}e^{-\eta/\mu}+\int_0^{t1}\varepsilon_{air\nu}
> B_{\nu}(T_{air}e^{-t/\mu}/\mu dt\right]d\mu d\nu d\phi$$
>
> The model is passed as parameter to the integration function. It is
> interesting that Lisp is very good at this kind of number crunching,
> since it is necessary to pass a function as parameter to another.
> Anyway, if you want to play with this kind of code, and teach me how
> to optimize it, I will be glad. I will isolate the working code from
> the data, and send it to you with bogus data.
Well for one there is a error in the posted formulate (a missing #\) ).
Second the formulae itself seems inefficient. Perhaps consulting a basic
book on numerical analysis first will be more enlightening than optimizing
the actual code. I am just guessing, of cource, since I haven't seen the
actual code.
--------------
John Thingstad
On 13 mar, 01:04, "John Thingstad" <·······@online.no> wrote:
> På Thu, 12 Mar 2009 05:20:33 +0100, skrev comp.lang.scheme
> <········@yahoo.ca>:
>
>
>
>
>
> > Hi, Dimiter.
> > The code is gigantic, and I do not know how to get it from the
> > Internet. However, most of it is data. There is very litle real code.
> > Therefore, I belive that I can filter the code out of it. This will be
> > for the fun of it, of course. I cannot use the modified code. Since I
> > will learn a lot from you, I am ready to do this kind of work. The
> > Model is designed to eliminate atmospheric effects with respect to
> > thermal infrared, visible and near infrared bands. Sensor errors are
> > due to noises roughly classified into 3 categories: (1) noises derived
> > from ability of a sensor, (2) geometrical distortions, and (3)
> > atmospheric effects. We are interested in atmospheric effects.
> > After small terms of Chandra's equation, one needs to resolve the
> > following double integral ( will give it in LaTeX; compile it and you
> > will get the equation):
>
> > $$I_{obs}= \int_{\phi 1}^{\phi 2}
> > \int_{\mu 1}^{\mu 2}\int_{\nu 1}^{\nu 2}
> > R{\nu}\left[\varepsilon_{earth\nu}B_{\nu}
> > T_{earth}e^{-\eta/\mu}+\int_0^{t1}\varepsilon_{air\nu}
> > B_{\nu}(T_{air}e^{-t/\mu}/\mu dt\right]d\mu d\nu d\phi$$
>
> > The model is passed as parameter to the integration function. It is
> > interesting that Lisp is very good at this kind of number crunching,
> > since it is necessary to pass a function as parameter to another.
> > Anyway, if you want to play with this kind of code, and teach me how
> > to optimize it, I will be glad. I will isolate the working code from
> > the data, and send it to you with bogus data.
>
> Well for one there is a error in the posted formulate (a missing #\) ).
> Second the formulae itself seems inefficient. Perhaps consulting a basic
> book on numerical analysis first will be more enlightening than optimizing
> the actual code. I am just guessing, of cource, since I haven't seen the
> actual code.
>
> --------------
> John Thingstad
Hi, John.
I picked the formula from a paper by Kioshi Toril, Tomoyuki Mase, and
Takashi Hoshi:
http://www.gisdevelopment.net/aars/acrs/1995/ps4/ps4004.asp
You can find the same formula in Chandrasekhar's book 'Radiative
Transfer'. Dr. Lombardo also has a book where she discusses the famous
(and infamous) formula. In any case, it is well implemented. Since the
transfer function changes all the time, it is modelled using
elementary functions that are fed to the integration program. The
integration program is very small (although the amount of data is
huge).
The only reason for not posting the program right now is that, when I
try to run in on Allegro, I fail miserably. I am trying to compile it
with Allegro for two days. Well, I am able to compile and run it from
the debugger, but I am not able to create standalone DOS application.
In fact, Allegro is very difficult to program. It has a very complex
and unfriendly IDE. Believe me or not, after days of trial and error,
I still cannot create a miserable DOS application. Creating a
standalone DOS application took minutes on Clozure, and seconds on
SBCL.
I don't want to ask you people how to create a GUI-free application o
Allegro, because I want to discover it myself. As soon as I feel
confortable with Allegro, I will ask questions about efficiency,
speed, etc.
P� Sat, 14 Mar 2009 07:44:15 +0100, skrev comp.lang.scheme
<········@yahoo.ca>:
>
> I don't want to ask you people how to create a GUI-free application o
> Allegro, because I want to discover it myself. As soon as I feel
> confortable with Allegro, I will ask questions about efficiency,
> speed, etc.
For console work I have found that the Emacs interface to Allegro (eli or
SLIME) is a lot less of a pain to use.
You don't need to set up projects which I suppose is what is giving you
headaches.
http://www.franz.com/emacs/
--------------
John Thingstad