Naively, it's a one-liner in msize.go:initSizes

        if size&(size-1) == 0 { // bump alignment once in a while
            if size >= 2048 {
                align = 256
            } else if size >= 128 {
                align = size / 8
            } else if size >= 16 { // <---- change goes here, s/16/32
                align = 16 // required for x86 SSE instructions, if we want to use them
            }
        }

but make.bash then crashes.
So, cheap and easy, I got 2 out of 3.
Rick made some very discouraging noises expecting this for 1.8, but I'll look a little harder.

Time for 1.8 is now down to only a couple of more working days and while
the idea seems solid we don't have any performance numbers to indicate the
value of the change.

On Thu, Oct 27, 2016 at 3:10 PM, dr2chase notifications@github.com wrote:

Naively, it's a one-liner in msize.go:initSizes

    if size&(size-1) == 0 { // bump alignment once in a while
        if size >= 2048 {
            align = 256
        } else if size >= 128 {
            align = size / 8
        } else if size >= 16 { // <---- change goes here, s/16/32
            align = 16 // required for x86 SSE instructions, if we want to use them
        }
    }

but make.bash then crashes.
So, cheap and easy, I got 2 out of 3.
Rick made some very discouraging noises expecting this for 1.8, but I'll
look a little harder.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#17633 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AA7Wn97PbpG0m-U1ENpmNZ4rnVW5s321ks5q4Pc-gaJpZM4KikrA
.

Fair enough. Here's one data point from the compiler for 1.9 about the prevalence of slice allocations: While compiling std+cmd, 3.42% of all allocations were []*gc.Node; 1.16% of allocations were []*gc.Field.

but make.bash then crashes.

My hunch would be that this is violating some of the assumptions of heapBitsSetType, which is very optimized for the current alignment constraints of small size classes. It's probably not too hard to fix, but it does mean it doesn't necessarily work to just add a size class to the table.

Is this a dup of #8885?

Yes. Closing this one, since #8885 predates it so much. (Normally we close the dup with the least conversation if the dates are roughly equal)