May 03, 2012
On 3 May 2012 12:27, Don Clugston <dac@nospam.com> wrote:

> On 30/04/12 01:03, Manu wrote:
>
>> On 30 April 2012 01:24, Tove <tove@fransson.se <mailto:tove@fransson.se>> wrote:
>>
>>    On Sunday, 29 April 2012 at 22:13:22 UTC, Manu wrote:
>>
>>        Is it technically possible to have a precise GC clean up all
>>        unreferenced
>>        memory in one big pass?
>>
>>
>>    yes, but unless it's also moving/compacting... one would suffer
>>    memory fragmentation... so I would imagine TempAlloc is a better fit?
>>
>>
>> In some cases I'm comfortable with that type of fragmentation (large regularly sized resources), although that leads me to a gaping hole in D's allocation system...
>>
>> <OT, but still very important>
>> There is no way to request aligned memory. I can't even specify an
>>
>> alignment on a user type and expect it to be aligned if I create one on
>> the stack, let alone the heap >_<
>> It seems I can request alignment for items within a struct, but I can't
>> align the struct its self. In addition, a struct doesn't inherit the
>> alignment of its aligned members, so the struct is allocated unaligned,
>> and the aligned member fails its promise anyway.
>>
>
> Bug 2278.
>

Why do you suggest alignment to only 8 bytes (not 16)? MOVAPS and friends
operate on 16 byte aligned data, and all non-x86 architectures are strictly
16byte aligned with no unaligned alternative possible.
I'd like to see that proposal extended to arbitrary power-of-2, and to
allow align(n) applied to structs/classes.


May 07, 2012
Been away for a bit.  My recap of the recent discussion, in reverse chronological order...

GC.  The discussion on the GC is great, *but* it may be best to move it to its own thread.  I don't think that the nuances of the GC is a critical issue preventing D becoming adopted at a company -- even if those nuances (e.g., memory fragmentation, BlkAttr.NO_SCAN, false pointers, 10 second garbage collection, room for improvement) are very important to fully grok.

J2EE.  Using D instead of J2EE is an interesting notion.  Companies that are invested in using J2EE probably are not amenable to changing from JVM, so D would be viable for J2EE-centric enterprise environments if it could be compiled to Java Bytecode.  (The J2EE infrastructure provides a lot of administration, monitoring, and management facilities.)

Games.  As Peter indicated, and I assume Kenta Cho would whole-heartedly agree, for high-performance games the GC (or even malloc/free) can be avoided.  D is a fully viable language for high-performance games.  Awesome!

License.  The discussion on the licenses, as far as I can tell, impacts several things, and merits having further discussion in its own thread.  Its great to see that D2 compilers are coming either as stock part of some Linux distros, or as an easily obtainable package[1].
[1] alas far less great, since the "slight" increase to barrier to entry is actually quite high.  Back before Ruby and Python were stock components, I've seen people who prefer Python or prefer Ruby use Perl instead just because they could rely on it being there -- even though pulling down Python or Ruby was a snap.

Arrays.  Thank you for bringing to my attention the GC implications of using the built-in arrays and slicing.  I think that having D-based template C++ STL/BOOST-like alternatives that have different (non-GC) memory requirements makes sense now.  I don't think this is a show-stopper for D becoming adopted at a company.
1 2 3 4 5 6
Next ›   Last »