Thread overview
[Issue 10323] New: getAMDcacheinfo needlessly allocates
Jun 10, 2013
Adam D. Ruppe
Jun 10, 2013
Adam D. Ruppe
Jun 10, 2013
Adam D. Ruppe
Jun 10, 2013
David Nadlinger
Oct 05, 2013
Adam D. Ruppe
Oct 05, 2013
Adam D. Ruppe
June 10, 2013
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


--- Comment #0 from Adam D. Ruppe <destructionator@gmail.com> 2013-06-10 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: -------
June 10, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10323


hsteoh@quickfur.ath.cx changed:

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


--- Comment #1 from hsteoh@quickfur.ath.cx 2013-06-10 13:04:39 PDT ---
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: -------
June 10, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10323



--- Comment #2 from Adam D. Ruppe <destructionator@gmail.com> 2013-06-10 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: -------
June 10, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10323



--- Comment #3 from Adam D. Ruppe <destructionator@gmail.com> 2013-06-10 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: -------
June 10, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10323



--- Comment #4 from Steven Schveighoffer <schveiguy@yahoo.com> 2013-06-10 13:32:46 PDT ---
(In reply to comment #3)
> 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: -------
June 10, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10323


David Nadlinger <code@klickverbot.at> changed:

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


--- Comment #5 from David Nadlinger <code@klickverbot.at> 2013-06-10 14:23:17 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: -------
October 05, 2013
http://d.puremagic.com/issues/show_bug.cgi?id=10323



--- Comment #6 from Adam D. Ruppe <destructionator@gmail.com> 2013-10-04 18:59:13 PDT ---
pull # 625 fixed

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
October 05, 2013
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: -------