Forum: Ruby MultiThreading in C++

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
08da87881caf50a3166491a65fd685ee?d=identicon&s=25 ktxn1020 (Guest)
on 2007-02-06 22:56
(Received via mailing list)
Hi,

I am pretty new to multithreaded programming. I have a question with a
hope someone can help me out.

I want to find distances between points using thread (Win MFC)

For instance distance from:
p1 to p2, p3, p4, p5
p2 to p1, p3, p4, p5
p3 to p1, p2, p4, p5
p4 to p1, p2, p3, p5
p5 to p1, p2, p3, p4

with

p1(x1, y1) = p1(42.67,73.75)
p2(x2, y2) = p2 (61.22, 149.9)
p3(x3, y3) = p3(30.27, 97.73)
p4(x4, y4) = p4(35.18,101.83)
p5(x5, y5) = p5(41.15, 104.87)


using formular distance = square root (square (x2 - x1) + square (y2 -
y1))

How can I do it and what is the best way to do this?

Thanks in advance,
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (blackhedd)
on 2007-02-06 23:00
(Received via mailing list)
The best way to solve this problem is not to use threads. It's
local-compute
and local-memory bound so there is no capturable system latency. The
problem
appears to be parallelizable to some degree. If you are sure you'll be
running it on multi-processor or multicore hardware, then break up the
dataset into multiple chunks, and run each one through a separate
process.
Threads add nothing here.
397f61cc4458e13157b4facf72325e5f?d=identicon&s=25 Gennady Bystritsky (Guest)
on 2007-02-06 23:01
(Received via mailing list)
ktxn1020 wrote:
> p3 to p1, p2, p4, p5
>
>
> using formular distance = square root (square (x2 - x1) + square (y2
> - y1))
>
> How can I do it and what is the best way to do this?
>
> Thanks in advance,

The best way is to do your school assignments yourself ;-), you will
benefit from it in the future the great deal. Besides, it may be the
wrong list as Ruby is discussed here.

Gennady.
4dea430d31b993abaf41cd9b54f8128d?d=identicon&s=25 Avdi Grimm (Guest)
on 2007-02-06 23:03
(Received via mailing list)
On 2/6/07, ktxn1020 <kn0805@hotmail.com> wrote:
> Hi,
>
> I am pretty new to multithreaded programming. I have a question with a
> hope someone can help me out.

First, this is a mailing list for the Ruby programming language, not
C++.  You would probably have better luck on a mailing list devoted to
C++ programming, or on the comp.lang.c++ newsgroup.

Second, why are on earth are you using threads to solve the problem you
stated?
E34b5cae57e0dd170114dba444e37852?d=identicon&s=25 Logan Capaldo (Guest)
on 2007-02-06 23:54
(Received via mailing list)
On Wed, Feb 07, 2007 at 06:59:41AM +0900, Francis Cianfrocca wrote:
> The best way to solve this problem is not to use threads. It's local-compute
> and local-memory bound so there is no capturable system latency. The problem
> appears to be parallelizable to some degree. If you are sure you'll be
> running it on multi-processor or multicore hardware, then break up the
> dataset into multiple chunks, and run each one through a separate process.
> Threads add nothing here.
>
*applauds*
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2007-02-07 15:34
(Received via mailing list)
On Tue, 06 Feb 2007 22:59:41 +0100, Francis Cianfrocca
<garbagecat10@gmail.com> wrote:

> If you are sure you'll be
> running it on multi-processor or multicore hardware, then break up the
> dataset into multiple chunks, and run each one through a separate
> process.
> Threads add nothing here.
>

Threads for a single process only get scheduled on one of the cores?
This
is new to me, I thought at least on Windowsen, threads are the base
scheduling unit.

David Vallner
2c51fec8183a5d21c4e11b430beabb47?d=identicon&s=25 Patrick Hurley (Guest)
on 2007-02-07 17:30
(Received via mailing list)
On 2/7/07, David Vallner <david@vallner.net> wrote:
> Threads for a single process only get scheduled on one of the cores? This
> is new to me, I thought at least on Windowsen, threads are the base
> scheduling unit.

Difference between a Windows (native) thread and a Ruby (green)
thread. The Ruby interpreter does not (yet) support native threads.

pth
430ea1cba106cc65b7687d66e9df4f06?d=identicon&s=25 David Vallner (Guest)
on 2007-02-08 13:54
(Received via mailing list)
On Wed, 07 Feb 2007 17:28:59 +0100, Patrick Hurley <phurley@gmail.com>
wrote:

> On 2/7/07, David Vallner <david@vallner.net> wrote:
>> Threads for a single process only get scheduled on one of the cores?
>> This
>> is new to me, I thought at least on Windowsen, threads are the base
>> scheduling unit.
>
> Difference between a Windows (native) thread and a Ruby (green)
> thread. The Ruby interpreter does not (yet) support native threads.
>

The whole thread is horribly off-topic with C++ and MFC being involved
 from the beginning from someone who thought ruby-talk is there to work
out
his homework. So the threads in my (equally off-topic) question are in
fact native Win32 threads.

David Vallner
481b8eedcc884289756246e12d1869c1?d=identicon&s=25 Francis Cianfrocca (blackhedd)
on 2007-02-08 21:47
(Received via mailing list)
On 2/8/07, David Vallner <david@vallner.net> wrote:
>
> On Wed, 07 Feb 2007 17:28:59 +0100, Patrick Hurley <phurley@gmail.com>
> wrote:
>
> > On 2/7/07, David Vallner <david@vallner.net> wrote:
> >> Threads for a single process only get scheduled on one of the cores?
> >> This
> >> is new to me, I thought at least on Windowsen, threads are the base
> >> scheduling unit.
> >



Horribly offtopic reply: on Windows, the scheduling unit is what Windows
calls a "thread" (and might be more properly termed a kernel thread or a
light-weight process). Essentially the same deal on Linux. On Solaris
it's
different, you have both LWPs and userland threads. To your point,
windows
threads within a process will get scheduled on multiple cores and/or
processors (you can even tune their affinity for particular cores), but
this
adds nothing of value in the OP's homework assignment. Partition the
incoming dataset, schedule on multiple processes, and aggregate the
result
sets at the end. So much easier to debug than a threaded implementation.
This topic is locked and can not be replied to.