Prev: Names or traits for std::random param_type access methods?
Next: Throwing error is potentially buggy
From: Nick Hounsome on 1 Jun 2010 22:54
On 1 June, 21:33, "Peter C. Chapin" <pcc482...(a)gmail.com> wrote:
> Nick Hounsome wrote:
> > It seems to me that you still have to wait for everyting to be
> > initialized before main (unless the compiler adds a whole lot of extra
> > overhead or you are prepared to break things) so unless the compiler
> > somehow knew that certain ctors were expensive (a huge ask) it could
> > easily be more expensive to launch and synchronize the threads than to
> > just do it all on one thread as "usual".
>
> The compiler might already be initializing some sort of thread pool to support
> other features. In that case, the additional overhead of using multiple
> threads during initialization might be slight.

I think that it still goes against the spirit of C++ - You shouldn't
have to pay the cost if you don't use the feature.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

From: Goran on 1 Jun 2010 23:06
On May 28, 10:07 am, Lailoken <lailo...(a)gmail.com> wrote:
> On May 27, 12:08 pm, DeMarcus <use_my_alias_h...(a)hotmail.com> wrote:
>
> > As the standard now defines multi-threading, is there anything said
> > about the initialization of global variables? I.e. will a compiler be
> > allowed to initialize global data in parallel?
>
> I have always developed as if global variables were initialized
> concurrently.

What, using underlying system-specific synchronization primitives to
access them? ;-)

On a more serious note, optimizer compiler would first need to know
that spawning a thread is beneficial (e.g. profile-guided optimization
shows that one particular static takes so long to execute that
initializing it's translation in another thread gives better result
(swamps the overhead of thread creation/destruction/synchronization).
And of course, that programmer does not mind (temporary) memory and OS
resources footprint hit.

I am not sure I'd like to see that as a common practice. As a specific
optimization, yeah, OK, I can live with that.

Goran.


--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

 | 
Pages: 1
Prev: Names or traits for std::random param_type access methods?
Next: Throwing error is potentially buggy