www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11331] New: Inefficient initialization of struct

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11331

           Summary: Inefficient initialization of struct
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: andrei erdani.com



PDT ---
Consider the following stack region:

struct InSituRegion2(size_t size)
{
    // The store will be aligned to realof.align
    union
    {
        private ubyte[size] _store = void;
        real _forAlignmentOnly;
    }
    void* _crt, _end;

    void[] allocate(size_t bytes)
    {
          assert(_crt && _end);
        // round up
        const rounded = (bytes + real.alignof - 1) / real.alignof;
        auto newCrt = _crt + rounded;
        if (newCrt > _end) return null;
        auto result = _crt[0 .. bytes];
        _crt = newCrt;
        return result;
    }
}

size_t fun2(size_t s)
{
    InSituRegion2!(1024 * 64) r;
      r._crt = r._store.ptr;
      r._end = r._store.ptr + r._store.length;
    auto a = cast(uint[]) r.allocate(s);
    return a[s / 2];
}

(The code of fun2 has been written to be complex enough to avoid a few elisions
effected by optimizers.)

Disassembly reveals that constructing the struct object entails a memcpy of the
object's init over the object memory, even though most of the object is
deliberately left uninitialized. This undoes the performance gains of defining
and using an encapsulated stack region.

The initialization function should either use multiple memcpy calls or
individual word assignments.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 23 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11331


Dicebot <public dicebot.lv> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |public dicebot.lv



Erm, isn't it by spec? `void` initializer is targeted for variables, not member
fields. Here it just says that relevant `T.init` part can be garbage.

Fixing this issue would imply that there are no more guaranteed deterministic
T.init values for all types.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11331




PDT ---
 Dicebot: yah, it's an enhancement. One of the spec as well :o). The .init
value can still exist, but the initialization doesn't need to use it.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 23 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11331






  Dicebot: yah, it's an enhancement. One of the spec as well :o). The .init
 value can still exist, but the initialization doesn't need to use it.


Well, this sounds like quite an important change - I'd prefer this issue
description to tell more about possible implications of that spec change than
about generated assembly :)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 23 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=11331




PDT ---
http://dlang.org/struct.html mentions that "Struct instances that are not
instantiated with a constructor are default initialized to their .init value."
and mentions that S() is "same as auto b = S.init;"

There is no guarantee about the values of the = void members in S.init, but
definitely the spec clarifies that two default-constructed objects will compare
equal. So we need to change the spec to only guarantee non-=void fields of
default-constructed objects to be equal.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Oct 23 2013