Didier Verna | 17 Mar 2010 14:24
X-Face
Face
Picon
Picon
Picon
Picon
Gravatar

[2nd CfP] 7th European Lisp Workshop at ECOOP'10, June 21/22


     +------------------------------------------------------------+
     |                    2ND CALL FOR PAPERS                     |
     |                 7th European Lisp Workshop                 |
     | June 21/22, Maribor, Slovenia - co-located with ECOOP 2010 |
     +------------------------------------------------------------+

News
====
Our invited speaker, Manuel Serrano, will talk about "diffuse programming"
and HOP. The abstract of his presentation can be found on the website at:
http://european-lisp-workshop.org/upcoming/programme.php

Important Dates
===============
Submission deadline:               April 19, 2010
Notification of acceptance:        May   05, 2010
ECOOP early registration deadline: May   10, 2010
7th European Lisp Workshop:        June  21 or 22, 2010 (tbdl)

Please note that registration must be done with ECOOP itself.
For more information visit http://www.european-lisp-workshop.org
Contact: Didier Verna, didier@...

Invited Speaker
===============
Manuel Serrano (INRIA, France)
http://www-sop.inria.fr/members/Manuel.Serrano/

Overview
(Continue reading)

peter | 22 Mar 2010 10:07

Transfer peculiarities

I transferred MCL code from one machine to another under SL via USB 
memory stick.  On arrival AFAICS all files have a ._ accompanying 
hidden file (even TIFF files, and the .DS_Store has a ._.DS_Store 
companion. I assume that in transit the resource fork part was split 
off.

Easily remedied by archiving to zip before transferring, but I 
wondered if there was a generalized way to prevent this fork 
schizophrenia happening?
_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl

Sandro Pedrazzini | 22 Mar 2010 10:19
Favicon

Performance differences between 5.1 and 5.2.1


Hi,

I noticed (and measured) an important performance difference between my application running on RMCL 5.1 and the same application running on 5.2.1.
Only loading all the application code, from a fresh RMCL delivery, it takes on 5.2.1 almost twice as much as in 5.1.  Then, every functionality is slower on 5.2.1 and for some specific application tasks I could even measure a difference of a factor 4.

I was wondering if someone else is having such performance problems with 5.2.1

In both cases I am using a 1 GB dump, which, btw, on version 5.2.1 shows such warning on the listener:

Welcome to Macintosh Common Lisp Version 5.2.1!
; Warning: Requested 1073741824 bytes of heap. Max is 1073000000 bytes.
; While executing: CCL::CHECK-CARBONLIB-VERSION
?


Is there a connection?


best regards
Sandro

_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl
Raymond Lee | 22 Mar 2010 18:06
Favicon

(char-code ) inconsistencies

Dear MCL folks,

  The (char-code ) function's behavior has changed from MCL 5.x to RMCL 5.2.1 and now 
appears quite inconsistent for ASCII characters > 127.  For example, in most fonts ASCII 
character #  179 is mapped to the "greater than or equal to" character.  But now in RMCL

 (char-code (character "≥")) --> 8805
          whereas
 (char-code (character 179)) --> 179

  Thus the problem surfaces when you try to coerce text (say, in an image file) to its ASCII 
equivalent, but it won't appear if you call (char-code ) from its inverse, (character ).  Most ASCII 
characters > 127 exhibit similar problems.  Any solutions or ideas come to mind?  Thanks for 
your help,

 Raymond Lee
 Research Professor
 U. S. Naval Academy
_______________________________________________
info-mcl mailing list
info-mcl <at> clozure.com
http://clozure.com/mailman/listinfo/info-mcl
Terje Norderhaug | 22 Mar 2010 18:34

Re: (char-code ) inconsistencies

On Mar 22, 2010, at 10:06 AM, Raymond Lee wrote:
>
>   The (char-code ) function's behavior has changed from MCL 5.x to  
> RMCL 5.2.1 and now
> appears quite inconsistent for ASCII characters > 127.  For  
> example, in most fonts ASCII
> character #  179 is mapped to the "greater than or equal to"  
> character.  But now in RMCL
>
>  (char-code (character "≥")) --> 8805
>           whereas
>  (char-code (character 179)) --> 179
>
>   Thus the problem surfaces when you try to coerce text (say, in an  
> image file) to its ASCII
> equivalent, but it won't appear if you call (char-code ) from its  
> inverse, (character ).  Most ASCII
> characters > 127 exhibit similar problems.  Any solutions or ideas  
> come to mind?

This is due that MCL 5.2 was upgraded to use Unicode, for which 8805  
(2265 hex) is the "greater than or equal to" character.

-- Terje Norderhaug
   terje@...

_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl
peter | 22 Mar 2010 18:44

Re: (char-code ) inconsistencies

At 10:34 AM -0700 10/3/22, Terje Norderhaug wrote:
>On Mar 22, 2010, at 10:06 AM, Raymond Lee wrote:
>>
>>   The (char-code ) function's behavior has 
>>changed from MCL 5.x to RMCL 5.2.1 and now
>>appears quite inconsistent for ASCII 
>>characters > 127.  For example, in most fonts 
>>ASCII
>>character #  179 is mapped to the "greater than 
>>or equal to" character.  But now in RMCL
>>
>>  (char-code (character "„")) --> 8805
>>           whereas
>>  (char-code (character 179)) --> 179
>>
>>   Thus the problem surfaces when you try to 
>>coerce text (say, in an image file) to its ASCII
>>equivalent, but it won't appear if you call 
>>(char-code ) from its inverse, (character ). 
>>Most ASCII
>>characters > 127 exhibit similar problems.  Any 
>>solutions or ideas come to mind?
>
>This is due that MCL 5.2 was upgraded to use 
>Unicode, for which 8805 (2265 hex) is the 
>"greater than or equal to" character.

Presumably hence char-code's fine, we're just 
inputting unicode now where we were using roman.

Isn't the lisp function >= rather than „.

_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl

Raymond Lee | 23 Mar 2010 04:23
Favicon

Re: (char-code ) inconsistencies

Hi Peter and Terje,

  Many thanks for your prompt and informative replies.  Because several uncompressed image 
file formats (e.g., .psd  and  .bis) use the extended ASCII character-integer mapping, I'll need 
to write a workaround for opening/saving such images.  But at least I know what the issue is 
now.  Thanks again for your help,

  Ray Lee
---- Original message ----
>Date: Mon, 22 Mar 2010 17:44:44 +0000
>From: peter <p2.edoc <at> googlemail.com>  
>Subject: Re: [info-mcl] (char-code ) inconsistencies  
>To: Discussion list for MCL users <info-mcl <at> clozure.com>
>
>At 10:34 AM -0700 10/3/22, Terje Norderhaug wrote:
>>On Mar 22, 2010, at 10:06 AM, Raymond Lee wrote:
>>>
>>>   The (char-code ) function's behavior has 
>>>changed from MCL 5.x to RMCL 5.2.1 and now
>>>appears quite inconsistent for ASCII 
>>>characters > 127.  For example, in most fonts 
>>>ASCII
>>>character #  179 is mapped to the "greater than 
>>>or equal to" character.  But now in RMCL
>>>
>>>  (char-code (character "„")) --> 8805
>>>           whereas
>>>  (char-code (character 179)) --> 179
>>>
>>>   Thus the problem surfaces when you try to 
>>>coerce text (say, in an image file) to its ASCII
>>>equivalent, but it won't appear if you call 
>>>(char-code ) from its inverse, (character ). 
>>>Most ASCII
>>>characters > 127 exhibit similar problems.  Any 
>>>solutions or ideas come to mind?
>>
>>This is due that MCL 5.2 was upgraded to use 
>>Unicode, for which 8805 (2265 hex) is the 
>>"greater than or equal to" character.
>
>Presumably hence char-code's fine, we're just 
>inputting unicode now where we were using roman.
>
>Isn't the lisp function >= rather than „.
>_______________________________________________
>info-mcl mailing list
>info-mcl <at> clozure.com
>http://clozure.com/mailman/listinfo/info-mcl

_______________________________________________
info-mcl mailing list
info-mcl <at> clozure.com
http://clozure.com/mailman/listinfo/info-mcl
Ron Garret | 23 Mar 2010 05:26
Favicon

Re: (char-code ) inconsistencies

More likely all you need to do is change the default encoding to latin-1.

On Mar 22, 2010, at 8:23 PM, Raymond Lee wrote:

> Hi Peter and Terje,
> 
>  Many thanks for your prompt and informative replies.  Because several uncompressed image 
> file formats (e.g., .psd  and  .bis) use the extended ASCII character-integer mapping, I'll need 
> to write a workaround for opening/saving such images.  But at least I know what the issue is 
> now.  Thanks again for your help,
> 
>  Ray Lee
> ---- Original message ----
>> Date: Mon, 22 Mar 2010 17:44:44 +0000
>> From: peter <p2.edoc@...>  
>> Subject: Re: [info-mcl] (char-code ) inconsistencies  
>> To: Discussion list for MCL users <info-mcl@...>
>> 
>> At 10:34 AM -0700 10/3/22, Terje Norderhaug wrote:
>>> On Mar 22, 2010, at 10:06 AM, Raymond Lee wrote:
>>>> 
>>>>  The (char-code ) function's behavior has 
>>>> changed from MCL 5.x to RMCL 5.2.1 and now
>>>> appears quite inconsistent for ASCII 
>>>> characters > 127.  For example, in most fonts 
>>>> ASCII
>>>> character #  179 is mapped to the "greater than 
>>>> or equal to" character.  But now in RMCL
>>>> 
>>>> (char-code (character "„")) --> 8805
>>>>          whereas
>>>> (char-code (character 179)) --> 179
>>>> 
>>>>  Thus the problem surfaces when you try to 
>>>> coerce text (say, in an image file) to its ASCII
>>>> equivalent, but it won't appear if you call 
>>>> (char-code ) from its inverse, (character ). 
>>>> Most ASCII
>>>> characters > 127 exhibit similar problems.  Any 
>>>> solutions or ideas come to mind?
>>> 
>>> This is due that MCL 5.2 was upgraded to use 
>>> Unicode, for which 8805 (2265 hex) is the 
>>> "greater than or equal to" character.
>> 
>> Presumably hence char-code's fine, we're just 
>> inputting unicode now where we were using roman.
>> 
>> Isn't the lisp function >= rather than „.
>> _______________________________________________
>> info-mcl mailing list
>> info-mcl@...
>> http://clozure.com/mailman/listinfo/info-mcl
> _______________________________________________
> info-mcl mailing list
> info-mcl@...
> http://clozure.com/mailman/listinfo/info-mcl

_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl

Sandro Pedrazzini | 23 Mar 2010 09:06
Favicon

Re: Performance differences between 5.1 and 5.2.1

Hi Walker,

Thank you for sharing your measures and thoughts.
I am still wondering why such a big difference between RMCL 5.1 and RMCL 5.2 on the same platform.
Is there such an implementation difference on 5.2? 
Could we maybe get some feedback from implementers, at least to understand what we should avoid or do, in order to get as much efficiency as possible?

Regards
Sandro


On 22 Mar 2010, at 20:29, wws2 new wrote:

Hi Sandro,

I also experience a significant performance degradation, perhaps even larger than what you report, as I go between  MCL on a PPC and RMCL on Snow Leopard, the second being much slower despite being on a much faster and more recent chipset.

Some months ago I noticed that (time (dotimes (i x)) can vary significantly for various values of x between MCL and RMCL.  IIRC, somewhere around bignums things really slow down. 

  Welcome to Macintosh Common Lisp Version 5.2.1!

? (time (dotimes (i 1000000)))
  (DOTIMES (I 1000000)) took 15 milliseconds (0.015 seconds) to run.
  Of that, 1 milliseconds (0.001 seconds) were spent in The Cooperative Multitasking Experience.
  NIL
  
? (time (dotimes (i 1000000000)))
  (DOTIMES (I 1000000000)) took 455,771 milliseconds (455.771 seconds) to run.
  Of that, 136,552 milliseconds (136.552 seconds) were spent in The Cooperative Multitasking Experience.
  2,495 milliseconds (2.495 seconds) was spent in GC.
   7,410,336,440 bytes of memory allocated.
  NIL
  
on a Power PPC with MCL, these take 0.002 seconds (7 times faster) and 209 seconds (about 2.5 times as fast) but only 1.2 seconds in CME and 4.2 in GC

? (time (dotimes (i MOST-POSITIVE-FIXNUM)))
  (DOTIMES (I MOST-POSITIVE-FIXNUM)) took 7,985 milliseconds (7.985 seconds) to run.
  Of that, 3 milliseconds (0.003 seconds) were spent in The Cooperative Multitasking Experience.
   5,776 bytes of memory allocated.
  NIL
  
? MOST-POSITIVE-FIXNUM
  536870911
  
?   

As a result of this general slowness, I use my PPC machines for development, but have at least ported everything to RMCL on a new machine for the day when my old machines stop working.  

I also have my non-GUI code running on Clozure, hoping that an IDE and GUI layer eventually mature.   As to speed, my non-GUI code can be as much as 60-100 times faster under CCL than RMCL running on the same Intel machine.     One particularly slow routine which collects data stored in hash-tables (fast under CCL?) and writes around 500Meg to a stream to disk (slow under RMCL) takes 29 seconds on Clozure and around an hour under RMCL (and maybe 9 minutes on PPC-MCL).  Have not tried to figure out what the bottleneck is yet, but it must be something in streams or system-IO. 

BTW under CCL:

Welcome to Clozure Common Lisp Version 1.4-r13119  (DarwinX8664)!
? MOST-POSITIVE-FIXNUM
1152921504606846975
?  So let's not try that, it will take forever as well 

? (time (dotimes (i 1000000)))
(DOTIMES (I 1000000)) took 486 microseconds (0.000486 seconds) to run 
                    with 2 available CPU cores.
During that period, 715 microseconds (0.000715 seconds) were spent in user mode
                    34 microseconds (0.000034 seconds) were spent in system mode
NIL
? (time (dotimes (i 1000000000)))
(DOTIMES (I 1000000000)) took 530,609 microseconds (0.530609 seconds) to run 
                    with 2 available CPU cores.
During that period, 533,194 microseconds (0.533194 seconds) were spent in user mode
                    675 microseconds (0.000675 seconds) were spent in system mode
NIL

Walker


On Mar 22, 2010, Sandro Pedrazzini <sandro.pedrazzini-vS5zOjhOW+wAvxtiuMwx3w@public.gmane.org> wrote:



Hi,

I noticed (and measured) an important performance difference between my application running on RMCL 5.1 and the same application running on 5.2.1.
Only loading all the application code, from a fresh RMCL delivery, it takes on 5.2.1 almost twice as much as in 5.1.  Then, every functionality is slower on 5.2.1 and for some specific application tasks I could even measure a difference of a factor 4.

I was wondering if someone else is having such performance problems with 5.2.1

In both cases I am using a 1 GB dump, which, btw, on version 5.2.1 shows such warning on the listener:

Welcome to Macintosh Common Lisp Version 5.2.1!
; Warning: Requested 1073741824 bytes of heap. Max is 1073000000 bytes.
; While executing: CCL::CHECK-CARBONLIB-VERSION
?


Is there a connection?


best regards
Sandro




_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl
wws2 new | 22 Mar 2010 20:29
Picon
Picon

Re: Performance differences between 5.1 and 5.2.1

Hi Sandro,

I also experience a significant performance degradation, perhaps even larger than what you report, as I go between  MCL on a PPC and RMCL on Snow Leopard, the second being much slower despite being on a much faster and more recent chipset.

Some months ago I noticed that (time (dotimes (i x)) can vary significantly for various values of x between MCL and RMCL.  IIRC, somewhere around bignums things really slow down. 

  Welcome to Macintosh Common Lisp Version 5.2.1!

? (time (dotimes (i 1000000)))
  (DOTIMES (I 1000000)) took 15 milliseconds (0.015 seconds) to run.
  Of that, 1 milliseconds (0.001 seconds) were spent in The Cooperative Multitasking Experience.
  NIL

  

? (time (dotimes (i 1000000000)))
  (DOTIMES (I 1000000000)) took 455,771 milliseconds (455.771 seconds) to run.
  Of that, 136,552 milliseconds (136.552 seconds) were spent in The Cooperative Multitasking Experience.
  2,495 milliseconds (2.495 seconds) was spent in GC.
   7,410,336,440 bytes of memory allocated.
  NIL

  

on a Power PPC with MCL, these take 0.002 seconds (7 times faster) and 209 seconds (about 2.5 times as fast) but only 1.2 seconds in CME and 4.2 in GC

? (time (dotimes (i MOST-POSITIVE-FIXNUM)))
  (DOTIMES (I MOST-POSITIVE-FIXNUM)) took 7,985 milliseconds (7.985 seconds) to run.
  Of that, 3 milliseconds (0.003 seconds) were spent in The Cooperative Multitasking Experience.
   5,776 bytes of memory allocated.
  NIL

  

? MOST-POSITIVE-FIXNUM
  536870911
  
?   

As a result of this general slowness, I use my PPC machines for development, but have at least ported everything to RMCL on a new machine for the day when my old machines stop working.  

I also have my non-GUI code running on Clozure, hoping that an IDE and GUI layer eventually mature.   As to speed, my non-GUI code can be as much as 60-100 times faster under CCL than RMCL running on the same Intel machine.     One particularly slow routine which collects data stored in hash-tables (fast under CCL?) and writes around 500Meg to a stream to disk (slow under RMCL) takes 29 seconds on Clozure and around an hour under RMCL (and maybe 9 minutes on PPC-MCL).  Have not tried to figure out what the bottleneck is yet, but it must be something in streams or system-IO. 

BTW under CCL:

Welcome to Clozure Common Lisp Version 1.4-r13119  (DarwinX8664)!
? MOST-POSITIVE-FIXNUM
1152921504606846975
?  So let's not try that, it will take forever as well 

? (time (dotimes (i 1000000)))
(DOTIMES (I 1000000)) took 486 microseconds (0.000486 seconds) to run 
                    with 2 available CPU cores.
During that period, 715 microseconds (0.000715 seconds) were spent in user mode
                    34 microseconds (0.000034 seconds) were spent in system mode
NIL
? (time (dotimes (i 1000000000)))
(DOTIMES (I 1000000000)) took 530,609 microseconds (0.530609 seconds) to run 
                    with 2 available CPU cores.
During that period, 533,194 microseconds (0.533194 seconds) were spent in user mode
                    675 microseconds (0.000675 seconds) were spent in system mode
NIL

Walker


On Mar 22, 2010, Sandro Pedrazzini <sandro.pedrazzini-vS5zOjhOW+wAvxtiuMwx3w@public.gmane.org> wrote:



Hi,

I noticed (and measured) an important performance difference between my application running on RMCL 5.1 and the same application running on 5.2.1.
Only loading all the application code, from a fresh RMCL delivery, it takes on 5.2.1 almost twice as much as in 5.1.  Then, every functionality is slower on 5.2.1 and for some specific application tasks I could even measure a difference of a factor 4.

I was wondering if someone else is having such performance problems with 5.2.1

In both cases I am using a 1 GB dump, which, btw, on version 5.2.1 shows such warning on the listener:

Welcome to Macintosh Common Lisp Version 5.2.1!
; Warning: Requested 1073741824 bytes of heap. Max is 1073000000 bytes.
; While executing: CCL::CHECK-CARBONLIB-VERSION
?


Is there a connection?


best regards
Sandro



_______________________________________________
info-mcl mailing list
info-mcl@...
http://clozure.com/mailman/listinfo/info-mcl

Gmane