Announcement

Collapse
No announcement yet.

Intel Wants To Contribute Parallel STL Support To libstdc++ / libc++

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • coder
    replied
    Originally posted by hoohoo View Post
    To be honest I am not always sure which new feature came from which revision (0x, '11, '17. Isn't there a '13 too or did I imagine that one?). For 20-odd years C++ was the unchanging firmament upon which the universe rested. Then all these changes came.
    Many references have tagged in which versions certain features were added (and deprecated). For instance:

    http://en.cppreference.com/w/

    Originally posted by hoohoo View Post
    When, I wonder, will the kitchen sink be added?
    I hear you. I'm also troubled by the new rate of change. Their stated policy seems to be updating the standard every 3 years, with most big changes introduced on the odd-numbered updates. So, C++11 and C++17 are the big updates, while C++14 and C++20 are like maintenance updates.

    I think 11 and 14 made a lot of sense. In fact, many of those changes were overdue. I wish they could've just held off any more big changes until at least C++20. I work on a variety of platforms, including an embedded platform and an enterprise platform with lagging compilers. It's already caused me some trouble when open source libraries I've wanted to use had eagerly embraced C++14 and C++17 features not supported by some of these platforms' compilers.

    Beyond that, I just have trouble recommending C++. I've made a career of using it, but it's gotten so big and unwieldy that I'm genuinely concerned for its future. We've seen this movie before, with languages like ADA and Common Lisp.

    Leave a comment:


  • hoohoo
    replied
    Originally posted by coder View Post
    How is that different from brace-initialization, in C++11?

    Edit: it seems they just added some new rules around it:

    http://mariusbancila.ro/blog/2017/04...ced-init-list/
    To be honest I am not always sure which new feature came from which revision (0x, '11, '17. Isn't there a '13 too or did I imagine that one?). For 20-odd years C++ was the unchanging firmament upon which the universe rested. Then all these changes came.

    When, I wonder, will the kitchen sink be added?

    Leave a comment:


  • coder
    replied
    Originally posted by hoohoo View Post
    The initializer lists for containers are pretty nice too, even if they are just syntactic sugar.
    How is that different from brace-initialization, in C++11?

    Edit: it seems they just added some new rules around it:

    http://mariusbancila.ro/blog/2017/04...ced-init-list/
    Last edited by coder; 02 December 2017, 08:10 PM.

    Leave a comment:


  • hoohoo
    replied
    Originally posted by davidbepo View Post
    YES YES!!
    for me its the only useful feature of c++17 and that its not supported by the compilers is sad
    ;-)

    The initializer lists for containers are pretty nice too, even if they are just syntactic sugar.

    Leave a comment:


  • coder
    replied
    Originally posted by d4ddi0 View Post
    I was very surprised in 2012 to find that not only was libstdc++ not parallelized, In places it wasn't even reentrant (and thus not safe to use in threaded code at all).
    Because for most of what was in libstdc++, it didn't make sense to embed either threading or locks. Most of that stuff belongs at a higher level. Threading (still) isn't something one does naively (and expects any good results).

    Originally posted by d4ddi0 View Post
    No need to worry here about hurting another vendor.
    Yes, there is need. In their closed-source libraries & tools, Intel has a history of shunting off to a slow-path, unless an Intel-branded CPU was detected. This made their CPUs look artificially fast and hurt anyone running AMD (or other). I'm glad to hear this is vendor neutral, but then it'd be harder to get away with that nonsense in opensource.

    Leave a comment:


  • schmidtbag
    replied
    Originally posted by pal666 View Post
    seems like by something you mean c++17 standard
    Seeing as Bulldozer was released in 2011, no, I didn't mean that and as usual, I have no clue how you draw your conclusions.

    Leave a comment:


  • pal666
    replied
    Originally posted by schmidtbag View Post
    Seems like something you'd think AMD would've developed back when Bulldozer was released (since that CPU heavily depends upon parallelization to be worth using).
    seems like by something you mean c++17 standard

    Leave a comment:


  • pal666
    replied
    Originally posted by davidbepo View Post
    YES YES!!
    for me its the only useful feature of c++17 and that its not supported by the compilers is sad
    this is a library feature, you don't need new compiler for it, you could do it yourself, like intel did

    Leave a comment:


  • d4ddi0
    replied
    I was very surprised in 2012 to find that not only was libstdc++ not parallelized, In places it wasn't even reentrant (and thus not safe to use in threaded code at all). We assume that because something is mature that it is not a candidate for major improvements. This is exciting development.

    No need to worry here about hurting another vendor. The usual way for this sort of thing is there will be a portable C/C++ codepath.
    If there is an opportunity for major vendor specific optimizations, , and an optimized one that can be enabled with compiler switches.
    I'm sure people will be looking at it on amd, arm, AARCH64, and other platforms to see if there is anything more they can do for their respective platforms.

    Leave a comment:


  • schmidtbag
    replied
    Seems like something you'd think AMD would've developed back when Bulldozer was released (since that CPU heavily depends upon parallelization to be worth using).

    Leave a comment:

Working...
X