headers
Didier Verna | 3 Apr 2006 12:18
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

at a loss with inlining


        Hi !

I'm at a loss with respect to how inlining works in CMUCL, so I have several
questions:

I compile a single file with this at the top of the file:

(declaim (optimize (speed 3)
		   (compilation-speed 0)
		   (safety 0)
		   (debug 0)))

1/ If I additionally put (declaim ([not]inline foo)), am I SURE that the
function will [not] be inlined, or does Python just treat this as request /
indication / wish / desire / dream-on ;-) ?

2/ Is it possible that a non inlined function is called somewhere, but still I
don't see any #<FDEFINITION for ..> in the disassembled code ? If yes, where
do I see the function call ?

Thanks a lot

--

-- 
Didier Verna, didier <at> lrde.epita.fr, http://www.lrde.epita.fr/~didier

EPITA / LRDE, 14-16 rue Voltaire   Tel.+33 (1) 44 08 01 85
94276 Le Kremlin-Bicêtre, France   Fax.+33 (1) 53 14 59 22   didier <at> xemacs.org
(Continue reading)

Permalink | Reply | 0 comments |
headers
Didier Verna | 7 Apr 2006 14:07
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

oddities in type declarations


        Hi !

Consider the following file to be compiled:

(declaim (optimize (speed 3)
		   (compilation-speed 0)
		   (safety 0)
		   (debug 0)))

(defun assign (array value)
  (declare (type (simple-array fixnum (* *)) array))
  (declare (type fixnum value))
  (let ((size (array-dimension array 0))) ; don't worry, array is square
    (dotimes (i size)
      (declare (type fixnum i))
      (dotimes (j size)
	(setf (aref array i j) value)))))

        The declaration of i as a fixnum seems to allow CMU-CL to inline some
operations on the loop. Otherwise, I would get a message liike this:

; In: DEFUN ASSIGN

;   (DOTIMES (I SIZE) (DOTIMES # #))
; --> DO BLOCK LET TAGBODY UNLESS COND IF NOT IF >= IF 
; ==>
;   (< I #:G0)
; Note: Forced to do GENERIC-< (cost 10).
;     Unable to do inline fixnum comparison (cost 4) because:
(Continue reading)

Permalink | Reply | 8 comments |
headers
Paul Werkowski | 8 Apr 2006 14:19

Re: oddities in type declarations


|
| Consider the following file to be compiled:
|
| (declaim (optimize (speed 3)
|    (compilation-speed 0)
|    (safety 0)
|    (debug 0)))
|
| (defun assign (array value)
|   (declare (type (simple-array fixnum (* *)) array))
|   (declare (type fixnum value))
|   (let ((size (array-dimension array 0))) ; don't worry, array is square
|     (dotimes (i size)
|       (declare (type fixnum i))
|       (dotimes (j size)
| (setf (aref array i j) value)))))
|
|
|         The declaration of i as a fixnum seems to allow CMU-CL to inline some
| operations on the loop. Otherwise, I would get a message liike this:
|

<...>

|         But do I really have the right to do so ? The macro expansion of the
| function indicates that two consecutive declarations for i are issued in that
| case.

CMUCL inserts the declaration of UNSIGNED-BYTE for each counter,
(Continue reading)

Permalink | Reply | 7 comments |
headers
Didier Verna | 9 Apr 2006 14:20
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

Re: oddities in type declarations


"Paul Werkowski" <pw <at> snoopy.mv.com> wrote:

> |
> | Consider the following file to be compiled:
> |
> | (declaim (optimize (speed 3)
> |    (compilation-speed 0)
> |    (safety 0)
> |    (debug 0)))
> |
> | (defun assign (array value)
> |   (declare (type (simple-array fixnum (* *)) array))
> |   (declare (type fixnum value))
> |   (let ((size (array-dimension array 0))) ; don't worry, array is square
> |     (dotimes (i size)
> |       (declare (type fixnum i))
> |       (dotimes (j size)
> | (setf (aref array i j) value)))))
> |
> |
> |         The declaration of i as a fixnum seems to allow CMU-CL to inline
> | some operations on the loop. Otherwise, I would get a message liike this:
> |
>
> <...>
>
> |         But do I really have the right to do so ? The macro expansion of
> | the function indicates that two consecutive declarations for i are issued
> | in that case.
(Continue reading)

Permalink | Reply | 6 comments |
headers
Paul Werkowski | 9 Apr 2006 16:09

Re: oddities in type declarations


|
|         Sure. But what I was wondering was that if I insert my own
| declaration, the macroexpanded code ends up with two different ones (CMU-CL's
| one isn't removed) which looks weird. I was wondering if it's even legal.

CMUCL is doing something odd here. It has bound the loop counters to internally
named
variables, then inserted a (DECLARE UNSIGNED-BYTE #:Gxxxx) for each.
Then, it let-binds those counters to the original variable names. So, your
declaration on
I and J do not conflict with the compiler inserted declarations. The more
interesting thing
here is that no matter what you declare for I and J, it will not effect the
result type of
the offset computation and the compiler will always generate a note. I'm pretty
sure
this is not what was intended.

| > The compiler notes are about the computation for the actual element offset.
| > The sum of two fixnums can be greater than the fixnum range.
|
|         I'm not sure we understood each other: I understand why the compiler
| issues the notes, but my question was about the fact that I have two nested
| loops (one on I and one on J), but only notes about I.

It's been a long time since I looked at that part of the compiler. Maybe Ray can
comment.

|
(Continue reading)

Permalink | Reply | 1 comment |
headers
Raymond Toy | 9 Apr 2006 17:33
Picon
Favicon

Re: oddities in type declarations


Paul Werkowski wrote:
> |
> |         Sure. But what I was wondering was that if I insert my own
> | declaration, the macroexpanded code ends up with two different ones (CMU-CL's
> | one isn't removed) which looks weird. I was wondering if it's even legal.
> 
> 
> CMUCL is doing something odd here. It has bound the loop counters to internally
> named
> variables, then inserted a (DECLARE UNSIGNED-BYTE #:Gxxxx) for each.
> Then, it let-binds those counters to the original variable names. So, your
> declaration on
> I and J do not conflict with the compiler inserted declarations. The more
> interesting thing
> here is that no matter what you declare for I and J, it will not effect the
> result type of
> the offset computation and the compiler will always generate a note. I'm pretty
> sure
> this is not what was intended.

If you're using a recent snapshot, then, yes, that happens.  I changed 
the dotimes macro some time ago because of a discussion on this list 
about what should happen in (dotimes (k n) <modify k>).  It was decided 
that the loop should still run n times, but the value of k would be as 
modified.

I think to get this right, you'd have to parse any declarations for the 
loop counter and apply that to the gensym'ed loop counter.  I didn't do 
that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Kamen TOMOV | 9 Apr 2006 21:54

SERVE-EVENT based multitasking


On Fri, Apr 07 2006, Kamen TOMOV wrote:

> I run a server that works in a multi-threaded mode under CMUCL. As
> far as I understand MP (multiprocessing) in CMUCL runs on top of
> SERVE-EVENT mechanism. I expect to have long file-copying operations
> so in order to keep my server responsive I need to make such
> operations run in the background.
>
> So my question is - is it OK to mess with the SERVE-EVENT functions
> such add-fd-handler, remove-fd-handler etcetera while
> multiprocessing is being run under CMUCL? What is the proper way to
> do it?

I recently posted this issue to comp.lang.lisp but did not get a
response. It is CMUCL related so I would be grateful if you advise
about it.
Permalink | Reply | 501 comments |
headers
vlado tzankov | 9 Apr 2006 22:20
Picon

Re: SERVE-EVENT based multitasking


Hi Kamen,

If you organize the "long file-copying operations" properly - it is 
possible to use SERVE-EVENT for multitasking-like stuff. Generally it 
works on file handles. The long read/write operations should be split 
in smaller chunks - however I am not sure what functions you should 
use. I have done in the past such multitasking-like stuff - but mainly 
with sockets.

BR
	Vlado

On Sunday, April 9, 2006, at 10:54  PM, Kamen TOMOV wrote:

>
> On Fri, Apr 07 2006, Kamen TOMOV wrote:
>
>> I run a server that works in a multi-threaded mode under CMUCL. As
>> far as I understand MP (multiprocessing) in CMUCL runs on top of
>> SERVE-EVENT mechanism. I expect to have long file-copying operations
>> so in order to keep my server responsive I need to make such
>> operations run in the background.
>>
>> So my question is - is it OK to mess with the SERVE-EVENT functions
>> such add-fd-handler, remove-fd-handler etcetera while
>> multiprocessing is being run under CMUCL? What is the proper way to
>> do it?
>
> I recently posted this issue to comp.lang.lisp but did not get a
(Continue reading)

Permalink | Reply | 504 comments |
headers
Kamen TOMOV | 10 Apr 2006 23:07

Re: SERVE-EVENT based multitasking


On Sun, Apr 09 2006, vlado tzankov wrote:

> Hi Kamen,
>
> If you organize the "long file-copying operations" properly - it is
> possible to use SERVE-EVENT for multitasking-like stuff. Generally
> it works on file handles. The long read/write operations should be
> split in smaller chunks - however I am not sure what functions you
> should use. I have done in the past such multitasking-like stuff -
> but mainly with sockets.

Hi Vlado,

Thanks for your reply. Do you think that explicitly using SERVE-EVENT
would prevent the multiprocessing system in CMUCL from working
properly? Thanks.

By the way we found a few days ago: http://lisp-bg.blogspot.com/

Regards,
--

-- 
Kamen TOMOV
Permalink | Reply | 0 comments |
headers
Kamen TOMOV | 10 Apr 2006 23:05

Re: SERVE-EVENT based multitasking


On Sun, Apr 09 2006, vlado tzankov wrote:

> Hi Kamen,
>
> If you organize the "long file-copying operations" properly - it is
> possible to use SERVE-EVENT for multitasking-like stuff. Generally
> it works on file handles. The long read/write operations should be
> split in smaller chunks - however I am not sure what functions you
> should use. I have done in the past such multitasking-like stuff -
> but mainly with sockets.

Hi Vlado,

Thanks for your reply. Do you think that explicitly using SERVE-EVENT
would prevent the multiprocessing system in CMUCL from working
properly? Thanks.

By the way there is a brand new lisp-bg blog since a few days:
http://lisp-bg.blogspot.com/

Regards,
--

-- 
Kamen TOMOV
Permalink | Reply | 0 comments |

Gmane