headers
Dimitri S | 3 Sep 2003 09:37
Picon
Favicon

Icons in MCL


Since the big thing about OS-X is good loooks, how come the MCL 5.0 icon is 
still low-resolution? I'd love to know how to change the icon for my app, 
but how? I found something called an Icon Composer in the Developer tools of 
OS-X, but it has no help, and I have no idea how to link such a .icns file 
to MCL. Any general hints or (best of all) examples would be much 
appreciated!

(In OS9, I simply used Resedit to edit my application icon. In fact that 
changed MCL's icon too, despite having specified a new :creator in 
save-application, so I guess I was not doing it right then either..)

(please reply via info-mcl, or to my proper email which is dim at lissys dot 
demon dot co dot uk)

Dimitri Simos
Lissys

_________________________________________________________________
Express yourself with cool emoticons - download MSN Messenger today! 
http://www.msn.co.uk/messenger
Permalink | Reply | 1 comment |
headers
Dimitri S | 3 Sep 2003 09:36
Picon
Favicon

Number-crunching speed in MCL


I'm finding that number-crunching in MCL 5.0 is consistently about 3 times 
*slower* than it was in 4.3.1. (comparing 5.0 in OS-X with 4.3.1 running 
under classic in the same machine, a Titanium G4 500 MHz).

Is this right? Do others agree? Is it the compiler or what?

(please reply via info-mcl, or to my proper email which is dim at lissys dot 
demon dot co dot uk)

Dimitri Simos
Lissys

_________________________________________________________________
Find a cheaper internet access deal - choose one to suit you. 
http://www.msn.co.uk/internetaccess
Permalink | Reply | 2 comments |
headers
james anderson | 3 Sep 2003 16:37
Picon
Gravatar

Re: Number-crunching speed in MCL

he factor "3 times slower" does not agree with my observations.

i'm working over some old graphics code, which includes matrix 
catenation. given the "recent" at-length correspondence wrt consing and 
in-line operations i reworked the matrix routines.

i had not yet look back at older mcl versions, but took this note as an 
occasion to at least make a quick check.

i tried mcl 5.0/osx, 4.3.5/classic, and 4.3.1/classic, all on a 1.25 g4.
i looked at  512x512 catenation for double-float matrices.
the figures were within 10%
4.3.1 was slower. with increasing repetitions the factor increased, so 
i would theorize that it had to do with os scheduling differences 
between classic and osx.

...

On Wednesday, Sep 3, 2003, at 09:36 Europe/Berlin, Dimitri S wrote:

>
> I'm finding that number-crunching in MCL 5.0 is consistently about 3 
> times *slower* than it was in 4.3.1. (comparing 5.0 in OS-X with 4.3.1 
> running under classic in the same machine, a Titanium G4 500 MHz).
>
> Is this right? Do others agree? Is it the compiler or what?
>
>
> (please reply via info-mcl, or to my proper email which is dim at 
> lissys dot demon dot co dot uk)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Shannon Spires | 3 Sep 2003 16:49
Picon

Re: Number-crunching speed in MCL

Dimitri Simos wrote:

> I'm finding that number-crunching in MCL 5.0 is consistently about 3 times 
> *slower* than it was in 4.3.1. (comparing 5.0 in OS-X with 4.3.1 running 
> under classic in the same machine, a Titanium G4 500 MHz).
> 
> Is this right? Do others agree? Is it the compiler or what?

If you would post some code that demonstrates this, it would help us answer that
question. Vague pronouncements to this list of "MCL is slow" or "MCL seems not
to do X right" are very difficult to confirm or deny without example code.

--

-- 
Shannon Spires
svspire@...
Permalink | Reply | 0 comments |
headers
Arthur Ogus | 3 Sep 2003 18:38
Picon
Favicon

Re: Icons in MCL

I have a related to problem to that mentioned by Dimitri S.  I used MCL 
5.0
to create an application image, and resedit to change the icons of my 
app.
MCL's icon didn't change for me.  However, when I used the set info box
of a document to ask that all files with extension .tex be opened with 
my app,
the system instead set them to open with MCL 5.0.  My understanding, and
perhaps also the tools provided by digitool, seem inadequate  for OSX.

What should I do here?

Thanks.

On Wednesday, September 3, 2003, at 12:37 AM, Dimitri S wrote:

>
> Since the big thing about OS-X is good loooks, how come the MCL 5.0 
> icon is still low-resolution? I'd love to know how to change the icon 
> for my app, but how? I found something called an Icon Composer in the 
> Developer tools of OS-X, but it has no help, and I have no idea how to 
> link such a .icns file to MCL. Any general hints or (best of all) 
> examples would be much appreciated!
>
> (In OS9, I simply used Resedit to edit my application icon. In fact 
> that changed MCL's icon too, despite having specified a new :creator 
> in save-application, so I guess I was not doing it right then > either..)
>
> (please reply via info-mcl, or to my proper email which is dim at 
> lissys dot demon dot co dot uk)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Dimitri S | 3 Sep 2003 18:53
Picon
Favicon

Re: Number-crunching speed in MCL

Mea culpa!

Apologies to the list and to James Anderson for this. One of the things 
about the crash-resistance of OSX is that you leave applications running for 
weeks on end without quitting. I thought it would be enough to do full GCs 
before running timing tests, but I was very wrong, because having restarted 
both 5.0 and 4.3.1, they were within 15% of each other (4.3.1 still winning, 
just). I still have no idea why only my 5.0 slowed down so much over several 
days, but possibly have no one to blame but myself. The 'test code' was my 
entire suite of aircraft performance routines, so I'm afraid I can't give a 
compact sample. Goes to prove I'm an aero guy, not a software guy!

Elementary...

_________________________________________________________________
It's fast, it's easy and it's free. Get MSN Messenger today! 
http://www.msn.co.uk/messenger
Permalink | Reply | 0 comments |
headers
james anderson | 6 Sep 2003 11:56
Picon
Gravatar

a query on floating-point operations

greetings all;

in the continuing quest towards floating-point performance, but before 
approaching the arcana of floating-point and multivec compilers, i 
thought i'd look at "constant-foldng". below is a comparison of a 
function which implements a (matrix X vector) operation using the 
matrix directly with one which compiles a function which folds the 
matrix as constants.

to my surprise the functions perform roughly the same. !?

is this a consequence of the cache architecture / internal processor 
parallelism which makes the array references as effective as 
referencing constants from the code? is there some effect i'm 
overlooking?

thanks.

...
------------------------------------------------

(defun transform-immediate
        (m p result)
   "tranform a location stored in a vector"
   (declare (optimize (speed 3) (safety 0))
            (type (simple-array double-float (4)) p result)
            (type (simple-array double-float (4 4)) m))
   (let ((hr 0.0d0))
     (declare (type double-float hr)
              (dynamic-extent hr))
(Continue reading)

Permalink | Reply | 2 comments |
headers
Randall Beer | 7 Sep 2003 00:34
Picon

Re: floating point optimization, continued

Let's start with the crash you're  getting.

Here is what I get:

? (define-double-function %transform-x* (m0 m1 m2 m3 x y z hr)
     (/ (+ (+ (* x m0)
              (* y m1))
           (+ (* z m2)
              m3))
        hr))
%TRANSFORM-X*
? (defvar *x* (%copy-float 0.0d0))
*X*
? (%set-double! *x* (%transform-x* 3.0d0 3.0d0 3.0d0 0.0d0 1.0d0 1.0d0 
1.0d0 1.0d0))
9.0
? (define-double-function %transform-x* (m0 m1 m2 x y z hr)
     (/ (+ (+ (* x m0)
              (* y m1))
           (+ (* z m2)
              0.0d0))
        hr))
%TRANSFORM-X*
? (%set-double! *x* (%transform-x* 3.0d0 3.0d0 3.0d0 1.0d0 1.0d0 1.0d0 
1.0d0))
9.0
?

So, if I understood your example correctly, this seems to work for me. 
Were you doing something different from this, or am I missing something?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Peter Paine | 8 Sep 2003 08:37
Picon
Picon

Re: a query on floating-point operations

At 11:56 am +0200 03/9/6, james anderson wrote:
>is this a consequence of the cache architecture / internal processor 
>parallelism which makes the array references as effective as 
>referencing constants from the code? is there some effect i'm 
>overlooking?

I am more lost that you James.
I wondered if perhaps the compiler could not use the declaration 
(type (simple-array double-float (4)) p result) when within the 
compile-transform macro.  So I tried using a macro to wrapped local 
declarations for each access, i.e. in lieu of (* ... I used (*d ... 
where *d is

(defmacro *d (a b)
   `(* (the double-float ,a) (the double-float ,b)))

This had a deleterious effect of speed.

At a tangent I tried svref in lieu of aref in the symbol-macrolet on 
the simple-arrays p and result, which produced massive consing.

My hunch is that rather than array access being as fast as raw float 
access, there is some other inefficiency in the compile-transform 
version which slows it.

The next test is to manually substitute the example float values in 
the compile-transform function, so allowing us to remove the runtime 
compiler phase (hence see if that is the source of the inefficiency).

My trial and error optimization technique needs wholesale
(Continue reading)

Permalink | Reply | 1 comment |
headers
james anderson | 8 Sep 2003 12:43
Picon
Gravatar

Re: a query on floating-point operations


On Monday, Sep 8, 2003, at 08:37 Europe/Berlin, Peter Paine wrote:

> At 11:56 am +0200 03/9/6, james anderson wrote:
>> is this a consequence of the cache architecture / internal processor 
>> parallelism which makes the array references as effective as 
>> referencing constants from the code? is there some effect i'm 
>> overlooking?
>
> ...
> (defmacro *d (a b)
>   `(* (the double-float ,a) (the double-float ,b)))
>
> This had a deleterious effect of speed.
that surprises me. i've did not observe "the double-float" forms to 
have any effect on performance when other declarations are correct.
>
> At a tangent I tried svref in lieu of aref in the symbol-macrolet on 
> the simple-arrays p and result, which produced massive consing.
>
> My hunch is that rather than array access being as fast as raw float 
> access, there is some other inefficiency in the compile-transform 
> version which slows it.

the test does a single call first to compile the transform

>
> ...
>
> James, you don't say what environment you are using (MCL, MacOS,
(Continue reading)

Permalink | Reply | 0 comments |

Gmane