pro December 2011

pro@common-lisp.net

22 participants
6 discussions

[pro] GPU/CUDA & common lisp
by Tamas Papp 05 Apr '12

05 Apr '12

Hi everyone, I am about to buy a new server for number crunching, and I would like to keep my options open about GPU/CUDA based computations. The most intensively parallelizable thing that I am doing is particle filtering, and currently that works fine (and is really fast) in a multi-core CPU with SBCL, but I keep hearing wonderful things about GPUs from people, and I was wondering if I could make use of them but still program in CL. I basically have two questions: - What is the current status of using CPUs for computation in CL (in particular SBCL)? All I found was CL-GPU but I haven't tried it yet (my current server does not have a GPU). - What hardware is supported (if I want to use CL)? Can I use something like Nvidia's TESCLA C line? Any help/pointers/accounts would be appreciated, I am just exploring this so I don't know much about it yet, apologies if I am not asking the right questions. Best, Tamas

4 5

[pro] Declarations in compilers (feedback welcome)
by Juan Jose Garcia-Ripoll 30 Dec '11

30 Dec '11

After struggling mentally with this for a few weeks, I would like to have some consultation before I introduce some changes in ECL -- not that I expect many users here, but at least some implementor-fellows and power users of other implementations. My concerns right now relate to how declarations should be used by a compiler, and in particular how declarations interact with SAFETY levels. Please correct me if I am wrong, but I have seen more or less the following approaches [a]- Most implementations blindly believe declarations below a certain safety level. Above it, they seem more or less useless. [b]- SBCL takes declarations (and THE) as type assertions. For instance, in (LET ((Y (FOO X))) (DECLARE (FIXNUM Y))) ...) the assignment to Y would be checked to be a FIXNUM. This means the type declaration is actually enforced and believed and only at SAFETY 0 the checks are dropped (*) In both cases one ends up with a model in which in order to truly believe a declaration and have no extra burden (assertions), one has to drop to SAFETY 0 in all code that is involved with it, which is a mess, because it might inadvertently affect other parts of the code. It is for this reason that I am considering an alternative model for ECL which would grade safety as follows - Type declarations are always believed - SAFETY >= 1 adds type checks to enforce them. - SAFETY = 0, no checks. - SAFETY = 1, the special form THE or additional proclamations on the functions can be used to deactivate the check. As in (LET ((Y (THE FIXNUM (FOO X))) ...) This would allow one to keep most code safe, while deactivating some checks when they are really known to be true (**). Do you think this is useful/useless? The problem I see with this approach is that all code around is written for model [a] or [b], but I could not come up with something more sensible so far. Juanjo (*) Actually the checks are also deactivated when SBCL can infer the type of the value that is assigned to Y. This is somewhat contradictory, because (SETF Y (THE FIXNUM (FOO X))) would still generate a check, but proclaiming FOO to return a FIXNUM would completely bypass the check. (**) Yes, indeed I know that LOCALLY exists for a reason, but it does more than THE. For instance, if I (LOCALLY (DECLARE (SAFETY 0)) (THE FIXNUM (FOO (SLOT-ACCESSOR X)))... this influences the safety of the code that accesses a structure, which is not good. P.S.: Thanks to Paul Khuong for pointing out that SBCL behaves differently w.r.t. declarations. -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

4 6

[pro] what lisp command line arg parser is good?
by Mark H. David 21 Dec '11

21 Dec '11

Anyone with some thoughts on which command line parser is good to use? There seem to be n of them out there. None really stands out, that I can tell. Must be quicklisp readable, other than that, I don't have any kind of fancy requirements. Just something simple, and reliable. Widely used would be good, and/or well maintained. Any pro tips? Thanks, Mark

8 10

[pro] Keyword arguments and compiler macros
by Juan Jose Garcia-Ripoll 05 Dec '11

05 Dec '11

[Sorry for possible duplicates] I just realized that compiler macros might be too restrictive in some implementations. Take for instance (define-compiler-macro foo (a &key key-arg) ...) This is assuming that FOO is only going to be invoked with _constant_ keyword arguments. I know, I know, most uses will have always one argument or :KEY-ARG, but suppose you want to call (FOO some-value a-non-constant-expression some-other-value)... What is the compiler to do? I _now_ think that the compiler macro processor should simply recognize the failure to parse the form and return the original form, unprocessed, but the implementations I have at hand do not do that. ECL to begin with, but also CCL and SBCL. Any opinions on this? Juanjo -- Instituto de Física Fundamental, CSIC c/ Serrano, 113b, Madrid 28006 (Spain) http://juanjose.garciaripoll.googlepages.com

5 8

[pro] Bignum Arithmetic
by David McClain 04 Dec '11

04 Dec '11

I'm getting more deeply involved in Bignum prime-field and Elliptic Curve computations. Wonder if anyone knows the degree to which the Bignum support in Lisp is enhanced, in the sense that multiple algorithms can be used for, e.g., multiplication, depending on bignum operand sizes. FFT's over integer fields for large numbers, Montgomery multiplication elsewhere, etc.?? I just reviewed GnuMP docs and saw a fairly sophisticated collection of internal optimizations. Would it pay to migrate to GnuMP for specialized applications? Dr. David McClain dbm(a)refined-audiometrics.com

6 5

[pro] Mark Kantrowitz infix.lisp easter egg?
by Alexander Repenning 03 Dec '11

03 Dec '11

Using Mark Kantrowitz old but very handy infix we noticed some peculiar pattern of errors where very basic expressions do not correctly convert infix expressions into prefix ones. The version I just tried was this one: http://www.cliki.net/infix in => pre, red for incorrect "a + 1" => (+ A 1) "s + 1" => S+1 "s - 1" => S-1 "s * 1" => (* S 1) "a + 1.5" => (+ A 1.5) "s + 1.5" => (+ S 1.5) "s + s" => (+ S S) "s + 1 + 1" => (+ S+1 1) "s + 1e1" => (+ S 10.0) Can somebody see a pattern here? AFAIK, the combination of the one letter variables names that are characters D, E, F, L, or S followed by "+" or "-" and then followed by an int does not work. Is this a bug or some very special case that is supposed to work like this for no (to me) obvious reason? If this is bug, how could this have slipped through the net for so many years? I know many people have using this software. I tried various versions of infix.lisp. Are D, E, F, L, or S special tokens? If so, what do they mean, and where are they declared? Confused, Alex ---- test program spitting out the variable names not working ------ This should print nothing: (map nil #'(lambda (Char) (when (symbolp (read-from-string (format nil "#i(~A + 1)" Char))) ;; should be a list, NOT a symbol! (print Char))) "ABCDEFGHIJKLMNOPQRSTUVWXYZ") but prints: #\D #\E #\F #\L #\S Prof. Alexander Repenning University of Colorado Computer Science Department Boulder, CO 80309-430 vCard: http://www.cs.colorado.edu/~ralex/AlexanderRepenning.vcf

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

pro December 2011