Can't seem to get profiling to work on CMUCL (18c, x86 Linux).
I get errors like this all the time:
Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
593237680 is not of type (UNSIGNED-BYTE 29)
Restarts:
0: [ABORT] Return to Top-Level.
Debug (type H for help)
("MACROLET ((FROB NIL #))"
...
Any ideas?
--
Ola Rinta-Koski ···@cyberell.com
Cyberell Oy +358 41 467 2502
Rauhankatu 8 C, FIN-00170 Helsinki, FINLAND www.cyberell.com
Ola Rinta-Koski <···@cyberell.com> writes:
> Can't seem to get profiling to work on CMUCL (18c, x86 Linux).
> I get errors like this all the time:
>
> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
> 593237680 is not of type (UNSIGNED-BYTE 29)
Further investigation reveals that the culprit is this statement:
(- (PROFILE::TOTAL-CONSING) PROFILE::START-CONSED)
within the profiling code. Apparently there's a lot of consing going
on.
Any ideas how to get around this? I'd be happy to just get "this
function conses a lot" instead of "this function consed n bytes".
--
Ola Rinta-Koski ···@cyberell.com
Cyberell Oy +358 41 467 2502
Rauhankatu 8 C, FIN-00170 Helsinki, FINLAND www.cyberell.com
>>>>> "Ola" == Ola Rinta-Koski <···@cyberell.com> writes:
Ola> Ola Rinta-Koski <···@cyberell.com> writes:
>> Can't seem to get profiling to work on CMUCL (18c, x86 Linux).
>> I get errors like this all the time:
>>
>> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
>> 593237680 is not of type (UNSIGNED-BYTE 29)
Ola> Further investigation reveals that the culprit is this statement:
Ola> (- (PROFILE::TOTAL-CONSING) PROFILE::START-CONSED)
Ola> within the profiling code. Apparently there's a lot of consing going
Ola> on.
Ola> Any ideas how to get around this? I'd be happy to just get "this
Ola> function conses a lot" instead of "this function consed n bytes".
Don't run the test for so long? :-)
If you have sources, you may be able to change the declaration for
total-consing and friends to be integer or something like that. This
may help at the expense of more consing in the profiler itself.
Alternatively, you may want to wait. I understand someone has worked
on this issue and has a good solution. Don't know when it will be
available.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Ola" == Ola Rinta-Koski <···@cyberell.com> writes:
> Ola> Ola Rinta-Koski <···@cyberell.com> writes:
> >> Can't seem to get profiling to work on CMUCL (18c, x86 Linux).
> >> I get errors like this all the time:
> >>
> >> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
> >> 593237680 is not of type (UNSIGNED-BYTE 29)
> Don't run the test for so long? :-)
I get this error message immediately when I start profiling.
> If you have sources, you may be able to change the declaration for
> total-consing and friends to be integer or something like that. This
> may help at the expense of more consing in the profiler itself.
I already looked at the source and it would appear that the cause of
this is some CMUCL-specific optimization. Maybe the function that
returns the number of consed bytes was changed between versions and
the profiling code wasn't, I don't know.
--
Ola Rinta-Koski ···@cyberell.com
Cyberell Oy +358 41 467 2502
Rauhankatu 8 C, FIN-00170 Helsinki, FINLAND www.cyberell.com
>>>>> "Ola" == Ola Rinta-Koski <···@cyberell.com> writes:
Ola> Raymond Toy <···@rtp.ericsson.se> writes:
>> >>>>> "Ola" == Ola Rinta-Koski <···@cyberell.com> writes:
Ola> Ola Rinta-Koski <···@cyberell.com> writes:
>> >> Can't seem to get profiling to work on CMUCL (18c, x86 Linux).
>> >> I get errors like this all the time:
>> >>
>> >> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
>> >> 593237680 is not of type (UNSIGNED-BYTE 29)
>> Don't run the test for so long? :-)
Ola> I get this error message immediately when I start profiling.
Hmm, I've had this happen before. Never figured it out. I just quit
out of lisp and restarted, and profiling worked.
>> If you have sources, you may be able to change the declaration for
>> total-consing and friends to be integer or something like that. This
>> may help at the expense of more consing in the profiler itself.
Ola> I already looked at the source and it would appear that the cause of
Ola> this is some CMUCL-specific optimization. Maybe the function that
Ola> returns the number of consed bytes was changed between versions and
Ola> the profiling code wasn't, I don't know.
Don't think that's the case, but I'd need to check to be sure.
Ray
Raymond Toy <···@rtp.ericsson.se> writes:
> >>>>> "Ola" == Ola Rinta-Koski <···@cyberell.com> writes:
>
> Ola> Raymond Toy <···@rtp.ericsson.se> writes:
> >> >>>>> "Ola" == Ola Rinta-Koski <···@cyberell.com> writes:
> Ola> Ola Rinta-Koski <···@cyberell.com> writes:
> >> >> Can't seem to get profiling to work on CMUCL (18c, x86 Linux).
> >> >> I get errors like this all the time:
> >> >>
> >> >> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
> >> >> 593237680 is not of type (UNSIGNED-BYTE 29)
>
> >> Don't run the test for so long? :-)
>
> Ola> I get this error message immediately when I start profiling.
>
> Hmm, I've had this happen before. Never figured it out. I just quit
> out of lisp and restarted, and profiling worked.
It's something to do with the return value of get-internal-run-time, I
think (from memory). I'm fairly sure it's the time type that's at
fault.
Maybe CLOCC have a fix, now or soon?
Cheers,
Christophe
--
Jesus College, Cambridge, CB5 8BL +44 1223 510 299
http://www-jcsu.jesus.cam.ac.uk/~csr21/ (defun pling-dollar
(str schar arg) (first (last +))) (make-dispatch-macro-character #\! t)
(set-dispatch-macro-character #\! #\$ #'pling-dollar)
Christophe Rhodes <·····@cam.ac.uk> writes:
> Raymond Toy <···@rtp.ericsson.se> writes:
> > >>>>> "Ola" == Ola Rinta-Koski <···@cyberell.com> writes:
> > Ola> Raymond Toy <···@rtp.ericsson.se> writes:
> > >> >>>>> "Ola" == Ola Rinta-Koski <···@cyberell.com> writes:
> > Ola> Ola Rinta-Koski <···@cyberell.com> writes:
> > >> >> Can't seem to get profiling to work on CMUCL (18c, x86 Linux).
> > >> >> I get errors like this all the time:
> > >> >>
> > >> >> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
> > >> >> 593237680 is not of type (UNSIGNED-BYTE 29)
> It's something to do with the return value of get-internal-run-time, I
> think (from memory). I'm fairly sure it's the time type that's at
> fault.
No, it's the number of bytes consed that makes things overflow.
--
Ola Rinta-Koski ···@cyberell.com
Cyberell Oy +358 41 467 2502
Rauhankatu 8 C, FIN-00170 Helsinki, FINLAND www.cyberell.com
* Ola Rinta-Koski wrote:
> I already looked at the source and it would appear that the cause of
> this is some CMUCL-specific optimization. Maybe the function that
> returns the number of consed bytes was changed between versions and
> the profiling code wasn't, I don't know.
I think this is it. Actually I have a nasty suspicion this is my
fault... A long time ago (in the CMU days I think) I remember
reporting a bug that TIME could blow up for consy long-running
programs (either it reported absurd negative values for consing, or it
just gave an error). This turned out to be because the cons counter
was a machine integer (or maybe a fixnum) and this got fixed so it
wasn't - I suspect by having the cons counter be two fixnums or
something with steam overflowing rather than a general bignum which
you probably would not want. So I rather suspect that this change has
broken something else.
--tim
Fixnum is used all over the place in the CMUCL profiler code for
memory counting. You cannot use integer, because then the profiler
starts to cons, which makes the profile useless (the time profile as
well since the bignum operations overhead on each functionc all is too
big). You cannot replace it with single-float because it needs to be
put into a special variable, which would cons for single-float. You
cannot use a struct because you need to shadow the value (not the
reference) in let.
I have an implementation based on two fixnums forming a 56 bit
integer, but it is too ugly for now, not a simple diff against the
CMUCL tree and the CVS repository is just in progress of being set up.
If you only need the time profile, I would recommend deleting the cons
counters from the profiler code.
Alternativly, do not cons more than 536870911 bytes :-)
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
········@counter.bik-gmbh.de (Martin Cracauer) writes:
> I have an implementation based on two fixnums forming a 56 bit
> integer, but it is too ugly for now, not a simple diff against the
> CMUCL tree and the CVS repository is just in progress of being set up.
So it requires changes elsewhere besides profile.lisp?
> If you only need the time profile, I would recommend deleting the cons
> counters from the profiler code.
I will try that.
> Alternativly, do not cons more than 536870911 bytes :-)
I would like not to - that is why I want to do the profiling in the
first place!
--
Ola Rinta-Koski ···@cyberell.com
Cyberell Oy +358 41 467 2502
Rauhankatu 8 C, FIN-00170 Helsinki, FINLAND www.cyberell.com
Ola Rinta-Koski <···@cyberell.com> writes:
>········@counter.bik-gmbh.de (Martin Cracauer) writes:
>> I have an implementation based on two fixnums forming a 56 bit
>> integer, but it is too ugly for now, not a simple diff against the
>> CMUCL tree and the CVS repository is just in progress of being set up.
> So it requires changes elsewhere besides profile.lisp?
Yes, the GC infrastructure for reporting bytes consed needs to be
adopted as well. Since you can't easily reload gc.x86f, that isn't
nice to integrate without a new binary.
I forgot to mention that my changes are x86 with genrational
conservative GC only, but are not yet conditionalized to let other
port build in the old style.
>> Alternativly, do not cons more than 536870911 bytes :-)
> I would like not to - that is why I want to do the profiling in the
> first place!
Can you profile a sub-part of your code? Usually you may be able to
get rid of one or two major consing function easily and then debug the
whole thing.
Martin
--
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Martin Cracauer <········@bik-gmbh.de> http://www.bik-gmbh.de/~cracauer/
FreeBSD - where you want to go. Today. http://www.freebsd.org/
Ola Rinta-Koski <···@cyberell.com> wrote in message news:<··············@arenal.cyberell.com>...
> Can't seem to get profiling to work on CMUCL (18c, x86 Linux).
> I get errors like this all the time:
>
> Type-error in KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
> 593237680 is not of type (UNSIGNED-BYTE 29)
>
> Restarts:
> 0: [ABORT] Return to Top-Level.
>
> Debug (type H for help)
>
> ("MACROLET ((FROB NIL #))"
> ...
>
> Any ideas?
SBCL <http://sbcl.sourceforge.net> is a fork off CMU CL which has
this fixed. If SBCL is an acceptable alternative, you could use
SBCL. Otherwise, it should be straightforward to port the code
to CMU CL.