Steel Bank Common Lisp

On Thu, 14 Jan 2010, Yue Li wrote:
> Then run my multithreading program again, and still, all the threads
> occupy one of the two cores when running, and the speed up is very
> trivial.
>
> Here did I miss something on configuring the GC? or I am totally out
> of the correct direction?

I think you hit a common problem.  The official SBCL binaries are built 
single-threaded.  To get a multithreaded build, you must build it 
yourself.

This isn't very hard.  Download and extract the SBCL sources somewhere. 
The INSTALL file tells you what to do and how to enable threads (see 
sections 2.1 and 2.2).

I don't think this is a GC issue.

Later,
Daniel

Hi, Daniel

On Fri, Jan 15, 2010 at 1:23 AM, Daniel Herring <dherring@...> wrote:
> On Thu, 14 Jan 2010, Yue Li wrote:
>>
>> Then run my multithreading program again, and still, all the threads
>> occupy one of the two cores when running, and the speed up is very
>> trivial.
>>
>> Here did I miss something on configuring the GC? or I am totally out
>> of the correct direction?
>
> I think you hit a common problem.  The official SBCL binaries are built
> single-threaded.  To get a multithreaded build, you must build it yourself.
>
> This isn't very hard.  Download and extract the SBCL sources somewhere. The
> INSTALL file tells you what to do and how to enable threads (see sections
> 2.1 and 2.2).
>

Thanks for your help! However, the sbcl installed on my machine is
built by myself, and I already enabled sb-thread following the INSTALL
file, I think if I did that incorrectly, I could not invoke
make-thread to spawn threads.

Cheers,

Yue

> I don't think this is a GC issue.
>
> Later,
> Daniel
>

> Thanks for your help! However, the sbcl installed on my machine is
> built by myself, and I already enabled sb-thread following the INSTALL
> file, I think if I did that incorrectly, I could not invoke
> make-thread to spawn threads.
> 
My guess would be that this is an operating system issue. This based on
the facts that sbcl uses pthread on x86 and pthread doesn't have a way
to hint the operating system how to schedule threads.

A possible thing could be that the operating system is reluctant to
migrate threads to other cores until there is subtantial load on them
over time. So if you run your program for several minutes maybe the os
will migrate one of them.

I may be wrong here to, there could be no/little cost at all to have the
threads on different cores and also no/little cost to migrate them.

best regards,
/larry

Larry Valkama wrote:
> My guess would be that this is an operating system issue.

since the OP is on Linux, maybe the "taskset" command could help?

Hi,

Yue Li <xyly781@...> writes:
>> On Thu, 14 Jan 2010, Yue Li wrote:
>>> Here did I miss something on configuring the GC? or I am totally out
>>> of the correct direction?
>>
>> I don't think this is a GC issue.
>
> Thanks for your help! However, the sbcl installed on my machine is
> built by myself, and I already enabled sb-thread following the INSTALL
> file, I think if I did that incorrectly, I could not invoke
> make-thread to spawn threads.

That is true.

Your problem is indeed a GC issue. The garbage collector is single
threaded and has to stop the world for collection, so everything gets
interrupted during collection. The less you cons, of course, the less
that happens, but if you have something consing like mad, then you will
mostly see the GC thread.

The same thing bit me a few days ago.

The short term solution is patience, or perhaps having multiple sbcls
communicating via sockets, as no other (free) multithreaded CL i am
aware of is competitive with SBCL in terms of speed anyway (at least on
numerical computations). Except perhaps CMU CL, and I doubt that there
things are better on this regard..

The long term solution would be a good parallel GC, but I suspect that
these are not very easy to write.

Regards,
        Mario.

---------- Forwarded message ----------
From: Yue Li <xyly781@...>
Date: Fri, Jan 15, 2010 at 11:49 AM
Subject: Re: [Sbcl-help] SBCL threads only occupy one of the cores
To: Giovanni Gigante <giov@...>


On Fri, Jan 15, 2010 at 6:03 AM, Giovanni Gigante <giov@...> wrote:
> Larry Valkama wrote:
>> My guess would be that this is an operating system issue.
>
> since the OP is on Linux, maybe the "taskset" command could help?
>
  Maybe I was wrong, but I think taskset could be used to put a
process to another core, but could not schedule a thread to occupy
another core?

Yue

On Fri, Jan 15, 2010 at 5:51 AM, Larry Valkama
<remlali@...> wrote:
>
>> Thanks for your help! However, the sbcl installed on my machine is
>> built by myself, and I already enabled sb-thread following the INSTALL
>> file, I think if I did that incorrectly, I could not invoke
>> make-thread to spawn threads.
>>
> My guess would be that this is an operating system issue. This based on
> the facts that sbcl uses pthread on x86 and pthread doesn't have a way
> to hint the operating system how to schedule threads.
>
> A possible thing could be that the operating system is reluctant to
> migrate threads to other cores until there is subtantial load on them
> over time. So if you run your program for several minutes maybe the os
> will migrate one of them.
>

Though I'm still not sure the reason is due to OS scheduler, but the
behavior you just described above is quite true. If I ask each thread
to execute a time cost load, say a deadloop, or then, threads will
also occupy the other core. But the strange thing is that, after
executing for a while, the threads will come back to the first core
from the second one again.

Thanks,

Yue


> I may be wrong here to, there could be no/little cost at all to have the
> threads on different cores and also no/little cost to migrate them.
>
> best regards,
> /larry
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for Conference
> attendees to learn about information security's most important issues through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> Sbcl-help mailing list
> Sbcl-help@...
> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>

In article 
<3df685d31001141817s333c8bf7l209dd80a953942fa@...>,
 Yue Li <xyly781@...> wrote:

> I'm running some simple computation, such as computing the sum of a
> list of one million integers in a reduction fashion.  I would like to
> parallelize the sum by using threads.  Therefore, I usually create
> about 2-4 threads, each computes a portion of the sum. The results are
> always correct, however, I found the performance is always as fast as
> my sequential version. Then I looked at the CPU monitor, and it shows
> that when doing computation using threads, all the threads only occupy
> the first core, and very seldomly occupy the second core. I read the
> SBCL manual, and googled on websites but seems I could not find the
> answer.

Can you post or link to (a reduced version of) your test case?

Paul Khuong

On 16 January 2010 21:17, Paul Khuong <pvk@...> wrote:

>> I'm running some simple computation, such as computing the sum of a
>> list of one million integers in a reduction fashion.  I would like to
>> parallelize the sum by using threads.  Therefore, I usually create
>> about 2-4 threads, each computes a portion of the sum. The results are
>> always correct, however, I found the performance is always as fast as
>> my sequential version. Then I looked at the CPU monitor, and it shows
>> that when doing computation using threads, all the threads only occupy
>> the first core, and very seldomly occupy the second core. I read the
>> SBCL manual, and googled on websites but seems I could not find the
>> answer.
>
> Can you post or link to (a reduced version of) your test case?

It may also be that your CPU affinity mask is set to restrict threads
from the SBCL process to a single core. SB-CPU-AFFINITY may be of use
for you in that case:

 http://github.com/nikodemus/sb-cpu-affinity

(Though if you say that computation _occasionally_ occurs on the
second core as well, I doubt affinity mask is the issue. Most likely
issue is that your code is not as parallel as you expect it to be for
one reason or another.)

Cheers,

 -- Nikodemus

On Fri, Feb 26, 2010 at 6:03 AM, Nikodemus Siivola
<nikodemus@...> wrote:
> On 16 January 2010 21:17, Paul Khuong <pvk@...> wrote:
>
>>> I'm running some simple computation, such as computing the sum of a
>>> list of one million integers in a reduction fashion.  I would like to
>>> parallelize the sum by using threads.  Therefore, I usually create
>>> about 2-4 threads, each computes a portion of the sum. The results are
>>> always correct, however, I found the performance is always as fast as
>>> my sequential version. Then I looked at the CPU monitor, and it shows
>>> that when doing computation using threads, all the threads only occupy
>>> the first core, and very seldomly occupy the second core. I read the
>>> SBCL manual, and googled on websites but seems I could not find the
>>> answer.
>>
>> Can you post or link to (a reduced version of) your test case?
>
> It may also be that your CPU affinity mask is set to restrict threads
> from the SBCL process to a single core. SB-CPU-AFFINITY may be of use
> for you in that case:
>
>  http://github.com/nikodemus/sb-cpu-affinity
>
> (Though if you say that computation _occasionally_ occurs on the
> second core as well, I doubt affinity mask is the issue. Most likely
> issue is that your code is not as parallel as you expect it to be for
> one reason or another.)

Hmm, in that case, it would be surprising that the same computations
with ECL-based or CLISP-based builds systematically display a
far better load-balancing behavior than with SBCL (or Clozure.)

-- Gaby

On 26 February 2010 19:10, Gabriel Dos Reis
<gdr@...> wrote:

>> (Though if you say that computation _occasionally_ occurs on the
>> second core as well, I doubt affinity mask is the issue. Most likely
>> issue is that your code is not as parallel as you expect it to be for
>> one reason or another.)
>
> Hmm, in that case, it would be surprising that the same computations
> with ECL-based or CLISP-based builds systematically display a
> far better load-balancing behavior than with SBCL (or Clozure.)

Not necessarily: that "one reason or another" may be something in the
implementation itself.

Can you post a test-case, please?

Cheers,

 -- Nikodemus