FAQ

On 2012/10/11 20:52:12, r wrote:
LGTM
LGTM. Are there similar savings inside 5g ?

https://codereview.appspot.com/6655045/

Search Discussions

  • Minux at Oct 12, 2012 at 6:07 am

    On Fri, Oct 12, 2012 at 10:41 AM, wrote:

    Are there similar savings inside 5g ?
    As I didn't suspect gc would use much memory, I haven't looked at gc.

    But I suspect there are similar saving in gc.
  • Minux at Oct 12, 2012 at 6:32 am

    On Fri, Oct 12, 2012 at 2:00 PM, minux wrote:
    On Fri, Oct 12, 2012 at 10:41 AM, wrote:

    Are there similar savings inside 5g ?
    As I didn't suspect gc would use much memory, I haven't looked at gc.

    But I suspect there are similar saving in gc.
    The same reordering is applicable to gc, but i think gc orders fields for
    better documentations (group related fields together), and the space
    saving won't be big if i can't reorder the fields freely.

    Russ said that gc put every number (even 0 is) as bigint/bigfloat, and
    removing
    that could bring us big space savings. Also, he said that we could reuse
    used
    number (or cache small frequently used numbers, say -1, 0, 1-100, 128, 256,
    etc
    in an array).
  • Rémy Oudompheng at Oct 12, 2012 at 6:41 am

    On 2012/10/12 minux wrote:
    The same reordering is applicable to gc, but i think gc orders fields for
    better documentations (group related fields together), and the space
    saving won't be big if i can't reorder the fields freely.

    Russ said that gc put every number (even 0 is) as bigint/bigfloat, and
    removing
    that could bring us big space savings. Also, he said that we could reuse
    used
    number (or cache small frequently used numbers, say -1, 0, 1-100, 128, 256,
    etc
    in an array).
    As far as I remember, the largest memory usage when compiling the
    dreadful output of test/rotate.go was essentially in Nodes. It's not
    clear what we can do for that.

    Rémy.
  • Minux at Oct 12, 2012 at 7:07 am

    On Fri, Oct 12, 2012 at 2:41 PM, Rémy Oudompheng wrote:

    As far as I remember, the largest memory usage when compiling the
    dreadful output of test/rotate.go was essentially in Nodes. It's not
    clear what we can do for that.
    Yeah, true.

    By freely reordering struct Node, I can make the 6g's maximum RSS
    smaller by 1.43% (from 5357168 KiB to 5281024 KiB, -76144 KiB).

    After reordering struct Sym, RSS go down by 3776 KiB (to 5277248 KiB).

    After reordering struct Type, RSS go down by 9168 KiB (to 5268080 KiB).

    To see the maximum RSS saved this way, I added #pragma pack to gc/go.h,
    and the RSS is now 5198800 KiB (down by 158368 KiB, a merely 3%).

    No big improvements (and doing this will severely affect code documentation
    quality), so maybe we need to use different type of Node struct for
    different
    kinds of node (which is a pretty big task).
  • Dave Cheney at Oct 12, 2012 at 11:23 am
    5.3Gb to compile! That is getting into Firefox territory.
    http://www.phoronix.com/scan.php?page=news_item&px=MTA3MTQ
    On Fri, Oct 12, 2012 at 6:07 PM, minux wrote:
    On Fri, Oct 12, 2012 at 2:41 PM, Rémy Oudompheng wrote:

    As far as I remember, the largest memory usage when compiling the
    dreadful output of test/rotate.go was essentially in Nodes. It's not
    clear what we can do for that.
    Yeah, true.

    By freely reordering struct Node, I can make the 6g's maximum RSS
    smaller by 1.43% (from 5357168 KiB to 5281024 KiB, -76144 KiB).

    After reordering struct Sym, RSS go down by 3776 KiB (to 5277248 KiB).

    After reordering struct Type, RSS go down by 9168 KiB (to 5268080 KiB).

    To see the maximum RSS saved this way, I added #pragma pack to gc/go.h,
    and the RSS is now 5198800 KiB (down by 158368 KiB, a merely 3%).

    No big improvements (and doing this will severely affect code documentation
    quality), so maybe we need to use different type of Node struct for
    different
    kinds of node (which is a pretty big task).
  • Minux at Oct 12, 2012 at 7:51 am

    On Fri, Oct 12, 2012 at 3:14 PM, Dave Cheney wrote:

    5.3Gb to compile! That is getting into Firefox territory.
    http://www.phoronix.com/scan.php?page=news_item&px=MTA3MTQ
    That's the very reason that test is not enabled by default, or
    all the builders will blow up. :-)
  • Minux Ma at Oct 12, 2012 at 9:22 am
    *** Submitted as
    http://code.google.com/p/go/source/detail?r=1baa80f7f4a4 ***

    cmd/5l: reorder some struct fields to reduce memory consumption
    Valgrind Massif result when linking godoc:
    On amd64:
    old new -/+
    mem_heap_B 185844612 175358047 -5.7%
    mem_heap_extra_B 773404 773137 -0.0%

    On 386/ARM:
    old new -/+
    mem_heap_B 141775701 131289941 -7.4%
    mem_heap_extra_B 737011 736955 -0.0%

    R=golang-dev, r, dave
    CC=golang-dev
    http://codereview.appspot.com/6655045


    http://codereview.appspot.com/6655045/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
categoriesgo
postedOct 12, '12 at 2:41a
activeOct 12, '12 at 11:23a
posts8
users3
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase