www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 10323] New: getAMDcacheinfo needlessly allocates

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

           Summary: getAMDcacheinfo needlessly allocates
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: druntime
        AssignedTo: nobody puremagic.com
        ReportedBy: destructionator gmail.com



11:55:55 PDT ---
src/druntime/src/core/cpuid.d line 544:

        immutable ubyte [] assocmap = [ 0, 1, 2, 0, 4, 0, 8, 0, 16, 0, 32, 48,
64, 96, 128, 0xFF ];


The real problem here is that a array initializer allocates, even if all the
data is static, and the compiler should probably be fixed, but in the mean time
I think we should go ahead and kill as many allocations as possible from
druntime, and this is one of them.

In my experimentation, I found just sticking "static" in front of this line
solved the immediate problem.

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


hsteoh quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hsteoh quickfur.ath.cx



Yeah, for array initializers to *always* allocate seems wrong to me. Is there a
bug for it?

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




13:21:06 PDT ---
Well, they don't *always* allocate - in the variable is static, they don't. But
if not they do and that sucks. I'm pretty sure it is a well known issue and
this bug seems close: http://d.puremagic.com/issues/show_bug.cgi?id=6421 but is
talking about static so not sure.

Bugzilla search never works easily for me :(

My preferred solution to the array literal question is if the contents are all
literal values too (or, ideally, if they can evaluate to literals with CTFE),
put the literal into static data like you would with a string literal. Well,
maybe not like a string literal, since they are read only and arrays expect to
be writable. Maybe put them in the initialized data segment instead, with
read/write.

Then only do a runtime allocation if the literal isn't all literals, e.g. "int
x = 10; auto b = [x, 100];", b would be an ok allocation because x is a runtime
value.


Nevertheless, in druntime we should be mindful of it and at least mark these
arrays static so they work today, pending an answer to the bigger question.

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




13:27:25 PDT ---
thinking some more about that data segment thing, maybe that won't work either
because ~= would try to find gc info, to check capacity, that doesn't exist
there. But I'm sure that can be worked around, the literal could perhaps write
out a dummy gc info block before the array informing append that it has zero
extra capacity.

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




13:32:46 PDT ---


 thinking some more about that data segment thing, maybe that won't work either
 because ~= would try to find gc info, to check capacity, that doesn't exist
 there. But I'm sure that can be worked around, the literal could perhaps write
 out a dummy gc info block before the array informing append that it has zero
 extra capacity.


The runtime can detect when it's not dealing with non-GC memory (think about
appending to stack data).

Appending would simply allocate a new GC block.

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


David Nadlinger <code klickverbot.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |code klickverbot.at



PDT ---
It should be possible to treat immutable arrays just like static immutable
ones.

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




18:59:13 PDT ---


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


Adam D. Ruppe <destructionator gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


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