comp.lang.c++
http://groups.google.com/group/comp.lang.c++?hl=en
comp.lang.c++@googlegroups.com
Today's topics:
* memory manager to prevent memory leaks - 4 messages, 3 authors
http://groups.google.com/group/comp.lang.c++/t/f3d6fc8d8d354450?hl=en
* 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 - 17 messages, 8 authors
http://groups.google.com/group/comp.lang.c++/t/81738d66827a11c8?hl=en
==============================================================================
TOPIC: memory manager to prevent memory leaks
http://groups.google.com/group/comp.lang.c++/t/f3d6fc8d8d354450?hl=en
==============================================================================
== 1 of 4 ==
Date: Sat, Jan 18 2014 9:46 am
From: Jorgen Grahn
On Sat, 2014-01-18, Paavo Helde wrote:
> hbdevelop1@gmail.com wrote in
> news:db61afcf-75c0-4f17-b7e1-a982425f96f8@googlegroups.com:
>
>> Hello,
>>
>> I have written a memory tracker to prevent memory leaks in my
>> programs.
>
> This kind of memory tracker does not prevent leaks; at best it just
> reports them, and *only in the executed code paths* which happen to be
> passed during the run.
...
(reordered a bit)
> So, as this memory tracker is both unreliable, subfunctional and most
> often not needed, I would advise to ditch it and ...
That's a bit harsh ...
> However, in C++ actually *preventing* memory leaks is usually simple,
> just don't ever use new/delete (or malloc/free) in the application code.
> Use automated classes like std::vector instead. If really needed,
> encapsulate new/delete in a specific RAII class.
I agree to that, and I personally have had no or very few resource
leaks in my C++ code in recent years.
But I'm always suspicious about advice which assumes:
- you work only with people who produce good C++ code
- you do so yourself
- you always have spare time to go back and rewrite code
which turned out bad.
There's nothing wrong with tools which help you deal with imperfect
code. C++ itself is such a tool!
My advise would be slightly different:
- There are many tools which do this already; use some of
those. (The ones which work with C's malloc/free should work
for C++ code too.)
- If you use them and find leaks, think about how you could
have used the language to make them impossible or unlikely.
/Jorgen
--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .
== 2 of 4 ==
Date: Sat, Jan 18 2014 12:04 pm
From: hbdevelop1@gmail.com
On Saturday, January 18, 2014 2:34:07 AM UTC-5, Paavo Helde wrote:
>
> Why would you need __FILE__ and __LINE__ of the point of deletion if you
> will remove the allocation entry anyway?
>
This is because the compiler asks for a matching operator delete for each operator new I overload.
Thank you very much for your constructive reaction
== 3 of 4 ==
Date: Sat, Jan 18 2014 12:05 pm
From: hbdevelop1@gmail.com
Thank you very much for your constructive reaction Jorgen Grahn
== 4 of 4 ==
Date: Sat, Jan 18 2014 1:14 pm
From: Paavo Helde
hbdevelop1@gmail.com wrote in
news:8612e686-dd66-4714-9232-8dc9738a14a7@googlegroups.com:
> On Saturday, January 18, 2014 2:34:07 AM UTC-5, Paavo Helde wrote:
>
>
>>
>> Why would you need __FILE__ and __LINE__ of the point of deletion if
>> you will remove the allocation entry anyway?
>>
> This is because the compiler asks for a matching operator delete for
> each operator new I overload.
This is used only for automatic release of memory in case the object
creation fails (constructor throws an exception). One cannot call the
placement delete operator directly (there is no syntax for passing the
'placement' parameters in the delete-expression).
So, in your leak detector you probably should redefine the standard
operator delete as well, to avoid the cumbersome deleteObj() function (and
probably switch to using malloc/free for the actual memory allocation, to
avoid infinite recursion problems).
hth
Paavo
==============================================================================
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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 17 ==
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
==============================================================================
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