Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C++ > Boost

Reply
Thread Tools

Boost

 
 
Herman Viracocha
Guest
Posts: n/a
 
      01-20-2014
Juha Nieminen wrote:

> Nick Baumbach <(E-Mail Removed)> wrote:
>> I mean, it has to make things easier, but it does not looks like, since
>> it takes hours to compile.

>
> It does not make things easier because it takes hours to compile?


No? Definitely is not easier. Are you sure you clearly understand "hours
to compile"?
 
Reply With Quote
 
 
 
 
J. Clarke
Guest
Posts: n/a
 
      01-20-2014
In article <0fbDu.28641$(E-Mail Removed)>, http://www.velocityreviews.com/forums/(E-Mail Removed) says...
>
> Nick Baumbach <(E-Mail Removed)> writes:
> >Ian Collins oratorically vehemently insists
> >
> >> On a more up to date machine with gcc:
> >>
> >> time ./b2 -j 32
> >>
> >> <stuff>
> >>
> >> The Boost C++ Libraries were successfully built!
> >>
> >> real 1m2.319s user 27m57.961s sys 1m49.214s

> >
> >Wow, -j 32 !! Say no more. Where did you find that 32 since at most I only
> >can find 16, as 2 threads per core. Actually thread core, not real core.
> >An i7 is still a 4 core, not sure how that threaded core is embedded into
> >the hardware.
> >
> >Please elaborate

>
> Many larger systems are available. Not too many years ago, I was running
> -j384 compiles regularly on a 192-core shared memory system.


People tend to assume that the consumer processors are the high end and
ignore the existence of the Xeon and Opteron lines. Using off-the-shelf
parts from Amazon you can build a 64-core machine with a terabyte of
RAM. Not _cheap_ but doable.


 
Reply With Quote
 
 
 
 
Walter Profile
Guest
Posts: n/a
 
      01-20-2014
J. Clarke wrote:

>> >Wow, -j 32 !! Say no more. Where did you find that 32 since at most I
>> >only can find 16, as 2 threads per core. Actually thread core, not
>> >real core. An i7 is still a 4 core, not sure how that threaded core is
>> >embedded into the hardware.
>> >
>> >Please elaborate

>>
>> Many larger systems are available. Not too many years ago, I was
>> running -j384 compiles regularly on a 192-core shared memory system.

>
> People tend to assume that the consumer processors are the high end and
> ignore the existence of the Xeon and Opteron lines. Using off-the-shelf
> parts from Amazon you can build a 64-core machine with a terabyte of
> RAM.
> Not _cheap_ but doable.


What off-the-shelf from Amazon are you talking about. Are you sure what
distributed shared memory is all about?

You seemingly agree in something that is stupid. The most on usenet are
using what is outhere available. Thus for now a 4 core / 8 threads are is
th best buy.

Moreover, if the code is not properly granulated for shared memory
distribution systems, that -j384 makes no sense.

 
Reply With Quote
 
Bob Hammerman
Guest
Posts: n/a
 
      01-20-2014
Drew Lawson wrote:

> I agree that it is possible (though apparently not necessary) for Boost
> to take hours to build.
>
> His repeated "you are noise and do not answer the question" song and
> dance is, IMO, a lame act.


Rather you agree but not know what you agree in. Total confusion.
 
Reply With Quote
 
Bob Hammerman
Guest
Posts: n/a
 
      01-20-2014
Robert Wessel wrote:

> On Mon, 20 Jan 2014 10:03:33 -0600, Robert Wessel
> <(E-Mail Removed)> wrote:
>
>>On Mon, 20 Jan 2014 15:26:52 GMT, (E-Mail Removed) (Scott Lurndal)
>>wrote:
>>
>>>Nick Baumbach <(E-Mail Removed)> writes:
>>>>Ian Collins oratorically vehemently insists
>>>>
>>>>> On a more up to date machine with gcc:
>>>>>
>>>>> time ./b2 -j 32
>>>>>
>>>>> <stuff>
>>>>>
>>>>> The Boost C++ Libraries were successfully built!
>>>>>
>>>>> real 1m2.319s user 27m57.961s sys 1m49.214s
>>>>
>>>>Wow, -j 32 !! Say no more. Where did you find that 32 since at most I
>>>>only can find 16, as 2 threads per core. Actually thread core, not
>>>>real core. An i7 is still a 4 core, not sure how that threaded core is
>>>>embedded into the hardware.
>>>>
>>>>Please elaborate
>>>
>>>Many larger systems are available. Not too many years ago, I was
>>>running -j384 compiles regularly on a 192-core shared memory system.

>>
>>
>>Although arraigning to build over a cluster would almost certainly be
>>far cheaper. OTOH, I've never looked at the internals of the Boost
>>build system, so I have no idea how hard it would be to get it to do
>>that.

>
>
> "Arraigning" to compiler over a cluster? Is that anything like being
> sentenced to hard labor? Spell checkers are fun... *sigh*


Not to forget that "cluster" has nothing to do with multicore and shared
memory
 
Reply With Quote
 
Bob Hammerman
Guest
Posts: n/a
 
      01-20-2014
Robert Wessel wrote:

> On Mon, 20 Jan 2014 15:44:31 +0000 (UTC), Herman Viracocha
> <(E-Mail Removed)> wrote:
>
>>Juha Nieminen wrote:
>>
>>> Nick Baumbach <(E-Mail Removed)> wrote:
>>>> I mean, it has to make things easier, but it does not looks like,
>>>> since it takes hours to compile.
>>>
>>> It does not make things easier because it takes hours to compile?

>>
>>No? Definitely is not easier. Are you sure you clearly understand "hours
>>to compile"?

>
> Interesting just how similar the NNTP headers for Nick Baumbach's and
> Herman Viracocha's posts are...


What has this to do with the subject to discuss? You seems confused.
 
Reply With Quote
 
Jorgen Grahn
Guest
Posts: n/a
 
      01-20-2014
On Mon, 2014-01-20, Scott Lurndal wrote:
> Nick Baumbach <(E-Mail Removed)> writes:
>>Ian Collins oratorically vehemently insists
>>
>>> On a more up to date machine with gcc:
>>>
>>> time ./b2 -j 32
>>>
>>> <stuff>
>>>
>>> The Boost C++ Libraries were successfully built!
>>>
>>> real 1m2.319s user 27m57.961s sys 1m49.214s

>>
>>Wow, -j 32 !! Say no more. Where did you find that 32 since at most I only
>>can find 16, as 2 threads per core. Actually thread core, not real core.
>>An i7 is still a 4 core, not sure how that threaded core is embedded into
>>the hardware.
>>
>>Please elaborate

>
> Many larger systems are available. Not too many years ago, I was running
> -j384 compiles regularly on a 192-core shared memory system.


Part of the point being: it's sometimes optimal to use more make
processes than the number of CPUs. (A coworker pointed that out to me
15 years ago or so.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
 
Reply With Quote
 
Bob Hammerman
Guest
Posts: n/a
 
      01-20-2014
Scott Lurndal wrote:

>>Moreover, if the code is not properly granulated for shared memory
>>distribution systems, that -j384 makes no sense.

>
> If you have one source file, then yes, the obvious is obvious. If you
> have thousands of source files, well, then.... Try building oracle11i,
> or glibc, or linux, or a custom hypervisor instead of hello world
> sometime.


Not sure at all, remember, shared memory, if the threads or processes are
interrelated, threads are, then they will wait in whatever queue for ready
data.

Back to the point. Are you implying that Boost is good only for high-ends
since it compiles faster. I don't need a 192 core for coding in C/C++.

It looks like no one knows why Boost would be good to anything.
 
Reply With Quote
 
Victor Bazarov
Guest
Posts: n/a
 
      01-20-2014
On 1/20/2014 12:34 PM, Bob Hammerman wrote:
> Scott Lurndal wrote:
>
>>> Moreover, if the code is not properly granulated for shared memory
>>> distribution systems, that -j384 makes no sense.

>>
>> If you have one source file, then yes, the obvious is obvious. If you
>> have thousands of source files, well, then.... Try building oracle11i,
>> or glibc, or linux, or a custom hypervisor instead of hello world
>> sometime.

>
> Not sure at all, remember, shared memory, if the threads or processes are
> interrelated, threads are, then they will wait in whatever queue for ready
> data.
>
> Back to the point. Are you implying that Boost is good only for high-ends
> since it compiles faster. I don't need a 192 core for coding in C/C++.
>
> It looks like no one knows why Boost would be good to anything.


It's "good to" Usenet trolling, as your example clearly shows.

V
--
I do not respond to top-posted replies, please don't ask
 
Reply With Quote
 
Bob Hammerman
Guest
Posts: n/a
 
      01-20-2014
Scott Lurndal wrote:

>>Moreover, if the code is not properly granulated for shared memory
>>distribution systems, that -j384 makes no sense.

>
> If you have one source file, then yes, the obvious is obvious. If you
> have thousands of source files, well, then.... Try building oracle11i,
> or glibc, or linux, or a custom hypervisor instead of hello world
> sometime.


I did compiled linux kernel years ago all the time. It took merely a 10 min
on a i386 and similar.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Boost::any and boost::lambda with std::find_if Misiu C++ 3 01-31-2007 05:46 PM
#include <boost/shared_ptr.hpp> or #include "boost/shared_ptr.hpp"? Colin Caughie C++ 1 08-29-2006 02:19 PM
Problems mixing boost::lambda::bind and boost::shared_ptr.. Toby Bradshaw C++ 6 06-02-2006 04:12 PM
Any Boost Experts out there for Boost.Regex? Richard Latter C++ 2 05-17-2004 03:12 PM
Boost + Python C/API: Mixing python return types with boost return types Steve Knight Python 2 10-10-2003 10:11 AM



Advertisments