comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* STL map to STL vector - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c++/t/1164ef3d2f08f58f?hl=en
* STL::MAP: Printing values only once .. - 4 messages, 4 authors
http://groups.google.com/group/comp.lang.c++/t/671080d0fc07abda?hl=en
* Boost - 21 messages, 10 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
TOPIC: STL map to STL vector
http://groups.google.com/group/comp.lang.c++/t/1164ef3d2f08f58f?hl=en
==============================================================================
== 1 of 1 ==
Date: Sat, Jan 18 2014 3:57 pm
From: Seungbeom Kim
On 2014-01-17 03:38, Juha Nieminen wrote:
> Seungbeom Kim <musiphil@bawi.org> wrote:
>>
>> I agree that standard names should not depend on implementation details,
>> but what would be so misleading in the name "hash_map" for something
>> that "by specification" requires and is organized by a hash function?
>
> Does the standard require for std::unordered_map to use the provided
> hash function for something?
Almost. Yes practically. 23.2.5[unord.req]/9:
"Keys with the same hash code appear in the same bucket."
Technically, an unordered associative container may avoid using the
hash function without violating that requirement if it chooses to use
a single bucket (even as it creates more buckets to lower the "nominal"
load factor), but it was never meant to be used that way, and it would
be a terrible QoI issue.
Anyway, my point was that the standard requires in the interface
specification the existence of something called a "hash function" and
that the word "hash" doesn't just refer to an implementation detail.
--
Seungbeom Kim
==============================================================================
TOPIC: STL::MAP: Printing values only once ..
http://groups.google.com/group/comp.lang.c++/t/671080d0fc07abda?hl=en
==============================================================================
== 1 of 4 ==
Date: Sun, Jan 19 2014 2:02 pm
From: Martijn Lievaart
On Sat, 18 Jan 2014 04:24:27 +0100, Alf P. Steinbach wrote:
> On 18.01.2014 03:39, Rahul Mathur wrote:
>> Hi,
>
> Oh, hi!
>
>
>> I have a input.txt file separator by pipe '|' as -
>>
>> 40147|181|ORANGE|MIKE|XX||1000397900|3500
>> 40148|373|ORANGE|BOB|XX||1078889400|4500
>> 40149|673|ORANGE|TREY|XX||1095159900|5500
>>
>>
>> I only wish to have all the FIRST(ID=40147) and LAST FIELD(PRICE=3500)
>> to be printed for three lines as given above.
>
> I think this would be a task for "awk", or its modern replacement if
> there is one. But as I recall from old days, "awk" was good at splitting
> lines into fields. If working in Windows, then there are lots of "Unix
> utilities" around, including just installing Cygwin (one practical idea
> is to map drive U: to such utilities, write "u::awk").
In this case, the modern replacement of awk is ..... awk.
Above requirement can be met with
awk -d'|' '{print $1, $7}'
which is more or less guarenteed to be simpler than any C++ program doing
the same task. :-)
M4
== 2 of 4 ==
Date: Sun, Jan 19 2014 10:18 pm
From: Rahul Mathur
If I need to print FIRST, FOURTH and SIXTH field only related to third row TREY only.
How can I modify above code?
On Saturday, January 18, 2014 8:09:21 AM UTC+5:30, Rahul Mathur wrote:
> Hi,
>
>
>
> I have a input.txt file separator by pipe '|' as -
>
>
>
> 40147|181|ORANGE|MIKE|XX||1000397900|3500
>
> 40148|373|ORANGE|BOB|XX||1078889400|4500
>
> 40149|673|ORANGE|TREY|XX||1095159900|5500
>
>
>
>
>
> I only wish to have all the FIRST(ID=40147) and LAST FIELD(PRICE=3500) to be printed for three lines as given above.
>
>
>
> I am reading as -
>
>
>
> --
>
> #include <iostream>
>
> #include <fstream>
>
> #include <sstream>
>
> #include <string>
>
> #include <boost/algorithm/string.hpp>
>
>
>
> using namespace std;
>
>
>
> struct FILE_INPUT {
>
> int ID;
>
> int Asset_ID;
>
> char T_Name[];
>
> char Symbol[];
>
> char Series[];
>
> char Gap;
>
> int Date;
>
> int price;
>
> };
>
>
>
>
>
> int main() {
>
>
>
> typedef std::map<int, int> unordmap;
>
> unordmap ask;
>
>
>
> FILE_INPUT fl_inp;
>
> memset( &fl_inp, 0, sizeof(fl_inp) );
>
> ifstream in ("input.txt");
>
> string s;
>
>
>
> const char delimiter = '|';
>
> while ( getline (in, s) ) {
>
> trim( s );
>
> if ( !s.empty() ) {
>
> stringstream strm( s );
>
> string item;
>
> getline( strm, item );
>
> stringstream stra( item );
>
> string tmp;
>
> getline( stra, tmp, delimiter );
>
> {
>
> stringstream strb( tmp );
>
> strb >> fl_inp.ID;
>
> }
>
> getline( stra, tmp, delimiter )
>
> {
>
> stringstream strb( tmp );
>
> strb >> fl_inp.price;
>
> }
>
>
>
> ask.insert( std::make_pair((fl_inp.ID),(fl_inp.price)) );
>
> unordmap::iterator pos = ask.begin();
>
> for (pos = ask.begin(); pos != ask.end(); ++pos) {
>
> std::cout << "ID: " << pos->first << "\t"
>
> << "Price: " << pos->second << std::endl;
>
> }
>
> std::cout << " " << endl;
>
> }
>
> }
>
> }
>
> --
>
>
>
> The map is being inserted with both ID as key and price as value but while printing it prints the values thrice as -
>
>
>
> ID: 40147 Price: 3500
>
>
>
> ID: 40147 Price: 4500
>
> ID: 40148 Price: 5500
>
>
>
> ID: 40147 Price: 3500
>
> ID: 40148 Price: 4500
>
> ID: 40149 Price: 5500
>
>
>
> The MAP should print all values together only once as -
>
>
>
> ID: 40147 Price: 3500
>
> ID: 40148 Price: 4500
>
> ID: 40149 Price: 5500
>
>
>
> --
>
>
>
> Can I maintain some checks to print all values simply once.
>
>
>
> Thanks.
== 3 of 4 ==
Date: Sun, Jan 19 2014 10:50 pm
From: Ian Collins
Rahul Mathur wrote:
> If I need to print FIRST, FOURTH and SIXTH field only related to third row TREY only.
>
> How can I modify above code?
>
Parse the rest of the fields and print them... Have a go and post your
code. If you do, please clean up the mess that shite google interface
will make of your code.
There wasn't any "above code" because you have top-posted :)
--
Ian Collins
== 4 of 4 ==
Date: Mon, Jan 20 2014 9:01 am
From: Jorgen Grahn
On Sun, 2014-01-19, Martijn Lievaart wrote:
> On Sat, 18 Jan 2014 04:24:27 +0100, Alf P. Steinbach wrote:
>
>> On 18.01.2014 03:39, Rahul Mathur wrote:
>>> Hi,
>>
>> Oh, hi!
>>
>>
>>> I have a input.txt file separator by pipe '|' as -
>>>
>>> 40147|181|ORANGE|MIKE|XX||1000397900|3500
>>> 40148|373|ORANGE|BOB|XX||1078889400|4500
>>> 40149|673|ORANGE|TREY|XX||1095159900|5500
>>>
>>>
>>> I only wish to have all the FIRST(ID=40147) and LAST FIELD(PRICE=3500)
>>> to be printed for three lines as given above.
>>
>> I think this would be a task for "awk", or its modern replacement if
>> there is one. But as I recall from old days, "awk" was good at splitting
>> lines into fields. If working in Windows, then there are lots of "Unix
>> utilities" around, including just installing Cygwin (one practical idea
>> is to map drive U: to such utilities, write "u::awk").
>
> In this case, the modern replacement of awk is ..... awk.
Well, or Perl.
> Above requirement can be met with
>
> awk -d'|' '{print $1, $7}'
There was a "for three lines" requirement too, but it can be met by
piping things through 'sed 3q'. Or Perl, or possibly Awk itself.
> which is more or less guarenteed to be simpler than any C++ program doing
> the same task. :-)
Yes. And next best is a C++ program using the same approach.
I got the impression that the original sucked up the whole input file
before extracting the information it wanted; that's slower and IME
more troublesome (harder to report syntax errors and so on).
I didn't read the original carefully though.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
==============================================================================
TOPIC: Boost
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
== 1 of 21 ==
Date: Mon, Jan 20 2014 12:28 am
From: Juha Nieminen
Nick Baumbach <nich@iwqoc.org> 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?
What kind of sense does that even make?
--- news://freenews.netfront.net/ - complaints: news@netfront.net ---
== 2 of 21 ==
Date: Mon, Jan 20 2014 5:44 am
From: drew@furrfu.invalid (Drew Lawson)
In article <ck3jd9hvrjo7eio0idenggt72dg2hjtvct@4ax.com>
Robert Wessel <robertwessel2@yahoo.com> writes:
>And just what part (or all) of Boost is going to require hours of
>compilation time?
My previous job made use of Boost, and had a script to build it
all. Using that script, it did take hours of elapsed time to build.
Comments from others show that the script probably wasn't using the
best options.
Anyway, it was no particular problem. We just told new people (or
people with new machines) to start it before leaving for the day.
(FWIW, I think the OP is yet another usenet performance artist.)
--
|Drew Lawson | Of all the things I've lost |
| | I miss my mind the most |
== 3 of 21 ==
Date: Mon, Jan 20 2014 7:26 am
From: scott@slp53.sl.home (Scott Lurndal)
Nick Baumbach <nich@iwqoc.org> 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.
== 4 of 21 ==
Date: Mon, Jan 20 2014 7:42 am
From: Herman Viracocha
Drew Lawson wrote:
> Anyway, it was no particular problem. We just told new people (or
> people with new machines) to start it before leaving for the day.
>
>
> (FWIW, I think the OP is yet another usenet performance artist.)
You agree with him that it takes hours then still call him "performance
artist".
What sort of performance artist are you?
== 5 of 21 ==
Date: Mon, Jan 20 2014 7:44 am
From: Herman Viracocha
Juha Nieminen wrote:
> Nick Baumbach <nich@iwqoc.org> 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"?
== 6 of 21 ==
Date: Mon, Jan 20 2014 8:03 am
From: Robert Wessel
On Mon, 20 Jan 2014 15:26:52 GMT, scott@slp53.sl.home (Scott Lurndal)
wrote:
>Nick Baumbach <nich@iwqoc.org> 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.
== 7 of 21 ==
Date: Mon, Jan 20 2014 8:10 am
From: Robert Wessel
On Mon, 20 Jan 2014 15:44:31 +0000 (UTC), Herman Viracocha
<hermv@idioqm.org> wrote:
>Juha Nieminen wrote:
>
>> Nick Baumbach <nich@iwqoc.org> 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...
== 8 of 21 ==
Date: Mon, Jan 20 2014 8:12 am
From: Robert Wessel
On Mon, 20 Jan 2014 10:03:33 -0600, Robert Wessel
<robertwessel2@yahoo.com> wrote:
>On Mon, 20 Jan 2014 15:26:52 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>Nick Baumbach <nich@iwqoc.org> 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*
== 9 of 21 ==
Date: Mon, Jan 20 2014 8:17 am
From: "J. Clarke"
In article <0fbDu.28641$YS5.16286@fx02.iad>, scott@slp53.sl.home says...
>
> Nick Baumbach <nich@iwqoc.org> 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.
== 10 of 21 ==
Date: Mon, Jan 20 2014 8:48 am
From: Walter Profile
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.
== 11 of 21 ==
Date: Mon, Jan 20 2014 8:53 am
From: drew@furrfu.invalid (Drew Lawson)
In article <lbjg4b$nsh$2@speranza.aioe.org>
Herman Viracocha <hermv@idioqm.org> writes:
>Drew Lawson wrote:
>
>> Anyway, it was no particular problem. We just told new people (or
>> people with new machines) to start it before leaving for the day.
>>
>>
>> (FWIW, I think the OP is yet another usenet performance artist.)
>
>You agree with him that it takes hours then still call him "performance
>artist".
>
>What sort of performance artist are you?
Having trouble reading?
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.
--
Drew Lawson | "But the senator, while insisting he was not
| intoxicated, could not explain his nudity."
== 12 of 21 ==
Date: Mon, Jan 20 2014 8:56 am
From: Bob Hammerman
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.
== 13 of 21 ==
Date: Mon, Jan 20 2014 8:57 am
From: Bob Hammerman
Robert Wessel wrote:
> On Mon, 20 Jan 2014 10:03:33 -0600, Robert Wessel
> <robertwessel2@yahoo.com> wrote:
>
>>On Mon, 20 Jan 2014 15:26:52 GMT, scott@slp53.sl.home (Scott Lurndal)
>>wrote:
>>
>>>Nick Baumbach <nich@iwqoc.org> 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
== 14 of 21 ==
Date: Mon, Jan 20 2014 9:01 am
From: Bob Hammerman
Robert Wessel wrote:
> On Mon, 20 Jan 2014 15:44:31 +0000 (UTC), Herman Viracocha
> <hermv@idioqm.org> wrote:
>
>>Juha Nieminen wrote:
>>
>>> Nick Baumbach <nich@iwqoc.org> 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.
== 15 of 21 ==
Date: Mon, Jan 20 2014 9:08 am
From: scott@slp53.sl.home (Scott Lurndal)
Robert Wessel <robertwessel2@yahoo.com> writes:
>On Mon, 20 Jan 2014 15:26:52 GMT, scott@slp53.sl.home (Scott Lurndal)
>wrote:
>
>>Nick Baumbach <nich@iwqoc.org> 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.
The aforementioned 192-core shared ccNUMA memory system (1TB DRAM) was selling
for about USD100,000 in 2009. About the same as a simliarly sized cluster
(16 nodes).
The followon system, which was in design, had 1024 xeon cores instead
of 192 opteron cores; but the economy stepped in and aborted that plan.
== 16 of 21 ==
Date: Mon, Jan 20 2014 9:14 am
From: scott@slp53.sl.home (Scott Lurndal)
Walter Profile <wprof@fj3dee.org> writes:
>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?
An eight-socket high-end xeon system can provide 64-cores and 1TB DRAM.
The motherboards, processors and memory can be purchased from Newegg,
Amazon and other on-line vendors.
>
>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.
What does 'usenet' have to do with the availability of very large systems?
On what basis do you claim knowledge of "what most on usenet are using"?
>
>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.
scott
== 17 of 21 ==
Date: Mon, Jan 20 2014 9:15 am
From: scott@slp53.sl.home (Scott Lurndal)
drew@furrfu.invalid (Drew Lawson) writes:
>In article <lbjg4b$nsh$2@speranza.aioe.org>
> Herman Viracocha <hermv@idioqm.org> writes:
>>Drew Lawson wrote:
>>
>>> Anyway, it was no particular problem. We just told new people (or
>>> people with new machines) to start it before leaving for the day.
>>>
>>>
>>> (FWIW, I think the OP is yet another usenet performance artist.)
>>
>>You agree with him that it takes hours then still call him "performance
>>artist".
>>
>>What sort of performance artist are you?
>
>Having trouble reading?
I think you missed the double entendre.
scott
== 18 of 21 ==
Date: Mon, Jan 20 2014 9:27 am
From: Jorgen Grahn
On Mon, 2014-01-20, Scott Lurndal wrote:
> Nick Baumbach <nich@iwqoc.org> 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 .
== 19 of 21 ==
Date: Mon, Jan 20 2014 9:34 am
From: Bob Hammerman
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.
== 20 of 21 ==
Date: Mon, Jan 20 2014 10:15 am
From: Victor Bazarov
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
== 21 of 21 ==
Date: Mon, Jan 20 2014 10:52 am
From: Bob Hammerman
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.
==============================================================================
You received this message because you are subscribed to the Google Groups "comp.lang.c++"
group.
To post to this group, visit http://groups.google.com/group/comp.lang.c++?hl=en
To unsubscribe from this group, send email to comp.lang.c+++unsubscribe@googlegroups.com
To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c++/subscribe?hl=en
To report abuse, send email explaining the problem to abuse@googlegroups.com
==============================================================================
Google Groups: http://groups.google.com/?hl=en
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment