Java > Scala

[Timon Gehr]

On 11/30/2011 09:58 PM, bigsandwich wrote:
> Jeff Nowakowski Wrote:
>
>> On 11/30/2011 01:38 PM, Walter Bright wrote:
>>>
>>> Yes, it is. What I meant by the "large and heavy rock" is the difficulty
>>> of expressing any sort of semantics that are not Java semantics in the
>>> JVM bytecode.
>>
>> Fair enough.
>>
>>> In C++, one does all the memory management manually.
>>
>> But in C++ libraries are designed with this in mind. You didn't address
>> his point: "Unless you want to do all of the memory management yourself,
>> which pretty much results in not using phobos and most of the cool
>> features in D."
>>
>> And isn't the point of D to relieve you of the burden of doing stuff
>> like memory management? You should read Tim Sweeney's (Gears of War
>> developer) "The Next Mainstream Programming Language", where the slide
>> for Gameplay Simulation says, "Usually garbage-collected." I assume by
>> this he means that for C++ the developers end up writing their own
>> garbage collector inside the program.
>>
>> http://www.st.cs.uni-saarland.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
>>
>> If D could demonstrably solve the problems outlined in these slides,
>> you'd have a whole industry at your fingertips.
>
> I don't usually post, but "someone is wrong on the internet" (http://xkcd.com/386/) :)
>
> "Usually garbage collected" in the case of Unreal refers to Unreal Script which is not C++ at all.  Its a language similar to Java that is compiled into bytecode.

Such kind of code could be written in (Safe)D perfectly fine and it 
would certainly perform better as well

>
> Most games use allocations schemes for different parts of the game, including garbage collection.  You wouldn't want to use GC in performance critical code anyway, so it probably doesn't matter that its that slow.
>
> What does matter is having a way to isolate GC to the few libraries where your willing to pay for it and turn it off for everything else.  It would be great if there was a way to build a static library and just pass a switch that would make compilation fail if there was GC allocation in the library.
>

Afaik this is planned.

> Other good features if you want to push into game dev:
> 1) Be able to override allocators (ie new, delete, or whatever they are called in D now) so that you can allocate out of different heaps.
>

http://www.d-programming-language.org/class.html#allocators

Andrei wants to deprecate them in favour of std.conv.emplace. I have 
already used std.conv.emplace to good effect for some simple custom 
class allocators.

Every allocation in my performance sensitive code looks like this:

New!Class(params)

I can then replace the allocator for a whole module by changing one 
small alias at the top of the module to quickly test performance of 
different allocation schemes on typical workloads.


> 2) Be able to control when GC occurs (ie every x frames, or in between levels, or only when there is a lull in the action).

http://www.d-programming-language.org/phobos/core_memory.html

In D, you have full control over the GC. You can disable and enable it, 
you can explicitly start a collection and you can even ask it to free as 
much of its internal data structures as possible etc. (And there is 
still a huge potential for improvements of its implementation! :o))



The quite common claim that you cannot use Phobos without cluttering up 
all your code with allocations is just not true. Phobos is not an 
Object-oriented class library. There are seldom hidden allocations, and 
it is almost always obvious when allocations must happen. The most 
useful high-level features of D are compile time features that do not 
harm performance (on the contrary).