[cram-developers] SBCL heap size

[Gayane Kazhoyan]

Hi Gheorghe,

The high-level plans composed of numerous perception, manipulation and
navigation actions (that have vague symbolic descriptions of locations,
objects, trajectories etc. as parameters) involve computationally intensive
reasoning mechanisms in order to ground those vague descriptions to actual
entities in the world surrounding the robot at the moment of plan
execution. On the one hand we end up with higher requirements on our
hardware (which in the modern world is usually not a problem, PR2 has 24 GB
of RAM), and on the other hand we acquire highly flexible plans that are
not limited to the current state of the environment, the specific robot
hardware etc., at least this is the goal towards which we are working. When
implementing complex systems there is always the trade off between the
computational efficiency and the capabilities of the system on the feature
level. I, personally, expect a robot executive that is trying to approach
in its reasoning capabilities the way the humans think to be extremely
computationally expensive.

Coming closer to the point and having finished my philosophical speech, I
suspect that there are three bottlenecks in the current implementation. (1)
The generative algorithm generating candidates for location designators
currently has as its domain the whole environment of the robot, i.e. for
the kitchen scenario it's the whole kitchen. This should not be too hard to
optimize by using some kind of a quadtree. (2) The randomized sampling
algorithm for designator resolution sometimes takes way too much time for
finding a good solution. 1.5 years ago I have been working on a priority
sampling mechanism, which resulted in a major performance improvement. I
haven't had time to clean up that code and merge it in yet. (3) Prolog is
basically a depth-first search algorithm, which is always slow. We had a
discussion about this in some of the previous emails.

Unfortunately, a different story is that Jan also had a problem of heap
overflow when simply starting a ROS node from roslisp and nothing else,
which has nothing to do with CRAM and also needs to be looked into.

If you would like to contribute to optimizing CRAM, in the discussion about
Prolog Lorenz pointed out a number of low-hanging fruits for improvement of
our Prolog implementation, I guess that could be a starting point.

Cheers
Gaya



On Sat, Mar 15, 2014 at 12:27 AM, Gheorghe Lisca <liscagheorghe at gmail.com>wrote:

> Hi Gaya,
>
> thanks for the advice!
>
> Just out of curiosity do you have in mind an example when CRAM would eat
> more than 1GB of RAM?
>
> Do you have an idea about which CRAM module would eat so much memory and
> maybe why?
>
> Cheers,
> Gheorghe
>
>
> On Fri, Mar 14, 2014 at 11:19 PM, Gayane Kazhoyan <
> kazhoyan at cs.uni-bremen.de> wrote:
>
>> Dear CRAM developers,
>>
>> Some of us have recently been getting into problems with SBCL heap
>> overflow.
>> The usual way to change the heap size is either to set
>>
>> (slime-lisp-implementations
>>    '((sbcl ("sbcl" "--dynamic-space-size" "MY-NEW-HEAP-SIZE"))))
>>
>> before invoking slime, e.g. in the emacs init file, or to pass a command
>> line argument ``--dynamic-heap-size MY-NEW-HEAP-SIZE`` to the sbcl
>> executive.
>>
>> As in our case slime is invoked by rosemacs and the SLIME-ROS function
>> thereof overrides user-defined SLIME-LISP-IMPLEMENTATIONS, the first option
>> of the above will not have any effect.
>> So, what is left is to pass the command line argument. I found no better
>> solution than to change the slime-ros.el itself. It is located in
>> /usr/share/emacs/site-lisp/rosemacs-el.
>> You should end up with
>>
>> (inferior-lisp-program (concat sbcl-binary
>>                                         " --dynamic-space-size 4096"
>>                                         " --load " roslisp-path
>>                                         "/scripts/roslisp-sbcl-init"))
>>
>> for 4 GB of RAM.
>>
>> To check if the change has taken effect, call (sb-ext:dynamic-space-size).
>>
>> My default heap size used to be 1 GB and since the change I haven't been
>> getting into any overflow problems whatsoever.
>>
>> If that doesn't help, the function for explicitly calling the garbage
>> collector was (sb-ext:gc :full t).
>>
>> Cheers,
>> Gaya
>>
>> --
>> Gayane Kazhoyan
>> Institute for Artificial Intelligence, Universität Bremen
>> https://ai.uni-bremen.de/team/gayane_kazhoyan
>>
>> _______________________________________________
>> cram-developers mailing list
>> cram-developers at informatik.uni-bremen.de
>> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
>>
>>
>
> _______________________________________________
> cram-developers mailing list
> cram-developers at informatik.uni-bremen.de
> https://mailman.informatik.uni-bremen.de/mailman/listinfo/cram-developers
>
>


-- 
Gayane Kazhoyan
Institute for Artificial Intelligence, Universität Bremen
https://ai.uni-bremen.de/team/gayane_kazhoyan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.informatik.uni-bremen.de/pipermail/cram-developers/attachments/20140315/55fb8c15/attachment.html>