www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [OT] Unity migrating parts of their engine from C++ into High

reply Paulo Pinto <pjmlp progtools.org> writes:
A bit off topic, yet still relevant given the ongoing attempts 
for D to be usable on the games industry.

At this year's GDC Unity had a few talks of the new subsystems 
being transitioning from internal engine code in C++ into upper 


For that purpose they are introducing a new compiler, based on 



Keypoints of the subset:

- Only structs are used, no classes;
- .NET collections are replaced by native collections that manage 
their own memory
- No code that would trigger GC is allowed
- Compiler is aware of Unity features and is able to explore 
SIMD, by doing auto-vectorization, and transparently transform 
structs fields into optimal representations


after integrating the new compiler infrastructure.



https://www.youtube.com/watch?v=NF6kcNS6U80

Also relevant,

"Job System & Entity Component System"
https://www.youtube.com/watch?v=kwnb9Clh2Is

"A Data Oriented Approach to Using Component Systems"

https://www.youtube.com/watch?v=p65Yt20pw0g

Some might remember Mike Acton's talk at CppCon about 
data-oriented programming, he is one of the developers leading 
this effort.

https://www.mcvuk.com/development/exclusive-unity-takes-a-principled-step-into-triple-a-performance-at-gdc
Apr 02 2018
next sibling parent reply 12345swordy <alexanderheistermann gmail.com> writes:
On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote:
 A bit off topic, yet still relevant given the ongoing attempts 
 for D to be usable on the games industry.

 At this year's GDC Unity had a few talks of the new subsystems 
 being transitioning from internal engine code in C++ into upper 


 For that purpose they are introducing a new compiler, based on 



 Keypoints of the subset:

 - Only structs are used, no classes;
 - .NET collections are replaced by native collections that 
 manage their own memory
 - No code that would trigger GC is allowed
 - Compiler is aware of Unity features and is able to explore 
 SIMD, by doing auto-vectorization, and transparently transform 
 structs fields into optimal representations


 after integrating the new compiler infrastructure.



 https://www.youtube.com/watch?v=NF6kcNS6U80

 Also relevant,

 "Job System & Entity Component System"
 https://www.youtube.com/watch?v=kwnb9Clh2Is

 "A Data Oriented Approach to Using Component Systems"

 https://www.youtube.com/watch?v=p65Yt20pw0g

 Some might remember Mike Acton's talk at CppCon about 
 data-oriented programming, he is one of the developers leading 
 this effort.

 https://www.mcvuk.com/development/exclusive-unity-takes-a-principled-step-into-triple-a-performance-at-gdc
Interesting that they are going the "No classes allowed" approach. It looks like the bullet points can be done in better c mode of D. Regardless, I been pushing for a way to deallocated classes in the nogc context, which apparently not very much people here seemed to care about.
Apr 02 2018
next sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
 - Only structs are used, no classes;
 - .NET collections are replaced by native collections that 
 manage their own memory
 - No code that would trigger GC is allowed
 - Compiler is aware of Unity features and is able to explore 
 SIMD, by doing auto-vectorization, and transparently transform 
 structs fields into optimal representations
mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface. interface IRange<T> { void popFront(); bool empty(); T front(); } struct MyRange<T>: IRange<T> { //implementation } void foo<T>(IRange<T> someRange) { //do something with someRange even it's a struct //this includes code completion and other IDE specific stuff. } In D, template constrains are not very clean and they not have IDE support: void foo(T)(T someRange) if (isInputRange!T) { }
Apr 02 2018
next sibling parent reply Meta <jared771 gmail.com> writes:
On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
 On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
 - Only structs are used, no classes;
 - .NET collections are replaced by native collections that 
 manage their own memory
 - No code that would trigger GC is allowed
 - Compiler is aware of Unity features and is able to explore 
 SIMD, by doing auto-vectorization, and transparently 
 transform structs fields into optimal representations
equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface. interface IRange<T> { void popFront(); bool empty(); T front(); } struct MyRange<T>: IRange<T> { //implementation } void foo<T>(IRange<T> someRange) { //do something with someRange even it's a struct //this includes code completion and other IDE specific stuff. } In D, template constrains are not very clean and they not have IDE support: void foo(T)(T someRange) if (isInputRange!T) { }
Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.
Apr 02 2018
next sibling parent reply Meta <jared771 gmail.com> writes:
On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:
 On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
 On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
 - Only structs are used, no classes;
 - .NET collections are replaced by native collections that 
 manage their own memory
 - No code that would trigger GC is allowed
 - Compiler is aware of Unity features and is able to explore 
 SIMD, by doing auto-vectorization, and transparently 
 transform structs fields into optimal representations
equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface. interface IRange<T> { void popFront(); bool empty(); T front(); } struct MyRange<T>: IRange<T> { //implementation } void foo<T>(IRange<T> someRange) { //do something with someRange even it's a struct //this includes code completion and other IDE specific stuff. } In D, template constrains are not very clean and they not have IDE support: void foo(T)(T someRange) if (isInputRange!T) { }
Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.
To clarify, the struct will be boxed when passing it to a function that accepts an IFoo, or if you do `IFoo foo = someStruct` or the like.
Apr 02 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 03/04/2018 11:01 AM, Meta wrote:
 On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:
 On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
 On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
 - Only structs are used, no classes;
 - .NET collections are replaced by native collections that manage 
 their own memory
 - No code that would trigger GC is allowed
 - Compiler is aware of Unity features and is able to explore SIMD, 
 by doing auto-vectorization, and transparently transform structs 
 fields into optimal representations
mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface. interface IRange<T> {    void popFront();    bool empty();    T front(); } struct MyRange<T>: IRange<T> {   //implementation } void foo<T>(IRange<T> someRange) {    //do something with someRange even it's a struct    //this includes code completion and other IDE specific stuff. } In D, template constrains are not very clean and they not have IDE support: void foo(T)(T someRange) if (isInputRange!T) { }
Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.
To clarify, the struct will be boxed when passing it to a function that accepts an IFoo, or if you do `IFoo foo = someStruct` or the like.
Shame we don't have signatures, then we'd have similar functionality only better! https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
Apr 02 2018
next sibling parent reply aliak <something something.com> writes:
On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole wrote:
 Shame we don't have signatures, then we'd have similar 
 functionality only better!

 https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
Is there an eta on this being submitted for consideration? Or has it already or? Cheers
Apr 03 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 03/04/2018 7:43 PM, aliak wrote:
 On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole wrote:
 Shame we don't have signatures, then we'd have similar functionality 
 only better!

 https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
Is there an eta on this being submitted for consideration? Or has it already or? Cheers
No ETA, it is a major addition comparable to classes and I want to get it right.
Apr 03 2018
parent aliak <something something.com> writes:
On Tuesday, 3 April 2018 at 07:57:36 UTC, rikki cattermole wrote:
 On 03/04/2018 7:43 PM, aliak wrote:
 On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole 
 wrote:
 Shame we don't have signatures, then we'd have similar 
 functionality only better!

 https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
Is there an eta on this being submitted for consideration? Or has it already or? Cheers
No ETA, it is a major addition comparable to classes and I want to get it right.
Ok. Really looking forward to it! :)
Apr 03 2018
prev sibling parent rumbu <rumbu rumbu.ro> writes:
On Tuesday, 3 April 2018 at 05:24:02 UTC, rikki cattermole wrote:
 Shame we don't have signatures, then we'd have similar 
 functionality only better!

 https://github.com/rikkimax/DIPs/blob/master/DIPs/DIP1xxx-RC.md
+1000 This would be a very interesting development.
Apr 03 2018
prev sibling parent reply rumbu <rumbu rumbu.ro> writes:
On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:
 On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
 void foo<T>(IRange<T> someRange)
 {
    //do something with someRange even it's a struct
    //this includes code completion and other IDE specific 
 stuff.
 }


 In D, template constrains are not very clean and they not have 
 IDE support:

 void foo(T)(T someRange) if (isInputRange!T)
 {

 }
Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.
clearly stated in the video (15:30). In fact, boxing would bring
Apr 02 2018
parent Meta <jared771 gmail.com> writes:
On Tuesday, 3 April 2018 at 04:50:15 UTC, rumbu wrote:
 On Monday, 2 April 2018 at 22:55:58 UTC, Meta wrote:
 On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
 void foo<T>(IRange<T> someRange)
 {
    //do something with someRange even it's a struct
    //this includes code completion and other IDE specific 
 stuff.
 }


 In D, template constrains are not very clean and they not 
 have IDE support:

 void foo(T)(T someRange) if (isInputRange!T)
 {

 }
Worth mentioning is that doing this necessarily causes the struct to be boxed. I would not be surprised if they ban structs inheriting from interfaces.
It's clearly stated in the video (15:30). In fact, boxing would
Oh, that's really neat (was on mobile and could not watch the video).
Apr 03 2018
prev sibling parent reply Laeeth Isharc <Laeeth laeeth.com> writes:
On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
 On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
 - Only structs are used, no classes;
 - .NET collections are replaced by native collections that 
 manage their own memory
 - No code that would trigger GC is allowed
 - Compiler is aware of Unity features and is able to explore 
 SIMD, by doing auto-vectorization, and transparently 
 transform structs fields into optimal representations
equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface. interface IRange<T> { void popFront(); bool empty(); T front(); } struct MyRange<T>: IRange<T> { //implementation } void foo<T>(IRange<T> someRange) { //do something with someRange even it's a struct //this includes code completion and other IDE specific stuff. } In D, template constrains are not very clean and they not have IDE support: void foo(T)(T someRange) if (isInputRange!T) { }
You can do that in D too - see Atila's concepts library.
Apr 02 2018
parent Laeeth Isharc <Laeeth laeeth.com> writes:
On Tuesday, 3 April 2018 at 01:31:12 UTC, Laeeth Isharc wrote:
 On Monday, 2 April 2018 at 20:19:17 UTC, rumbu wrote:
 On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
 - Only structs are used, no classes;
 - .NET collections are replaced by native collections that 
 manage their own memory
 - No code that would trigger GC is allowed
 - Compiler is aware of Unity features and is able to explore 
 SIMD, by doing auto-vectorization, and transparently 
 transform structs fields into optimal representations
equivalent, mainly because of the fact that you can inherit interfaces. You can have template constraints in D but this is not as user friendly as a struct interface. interface IRange<T> { void popFront(); bool empty(); T front(); } struct MyRange<T>: IRange<T> { //implementation } void foo<T>(IRange<T> someRange) { //do something with someRange even it's a struct //this includes code completion and other IDE specific stuff. } In D, template constrains are not very clean and they not have IDE support: void foo(T)(T someRange) if (isInputRange!T) { }
You can do that in D too - see Atila's concepts library.
interface IFoo { int foo(int i, string s) safe; double lefoo(string s) safe; } implements!(Foo, IFoo) struct Foo { int foo(int i, string s) safe { return 0; } double lefoo(string s) safe { return 0; } } // doesn't compile /* implements!(Oops, IFoo) struct Oops {} */
Apr 02 2018
prev sibling parent Mike Franklin <slavo5150 yahoo.com> writes:
On Monday, 2 April 2018 at 18:54:28 UTC, 12345swordy wrote:
 Interesting that they are going the "No classes allowed" 
 approach. It looks like the bullet points can be done in better 
 c mode of D.
I think you'll find Sarn's work on Xanthe quite interesting: https://forum.dlang.org/post/qjowkuwstewnmdunepiq forum.dlang.org https://forum.dlang.org/post/ntnvrdoqgjpuogoxexqn forum.dlang.org D provides some remarkable features (type introspection, mixins, templates, etc...) that could make something like this possible in D.
 Regardless, I been pushing for a way to deallocated classes in 
 the  nogc context, which apparently not very much people here 
 seemed to care about.
I think people care, but it's a difficult problem to solve due to the burden of some of D's technical debt. I know you are aware of the proposed ProtoObject which may provide an eventual solution. I, for one, am considering abandoning classes altogether and looking for ways to build on Sarn's aforementioned work to make object hierarchies in D using only structs. Mike
Apr 03 2018
prev sibling parent reply Dukc <ajieskola gmail.com> writes:
On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote:
 - No code that would trigger GC is allowed
Impressive! It definitely won't be anyhing like D or Rust in that this sounds wonderous nonetheless! Especially if, even without its core feature, classes, it's worthy as a c++ replacement where applicable. I should really check this at some point.
Apr 03 2018
parent Paulo Pinto <pjmlp progtools.org> writes:
On Tuesday, 3 April 2018 at 07:29:11 UTC, Dukc wrote:
 On Monday, 2 April 2018 at 17:30:20 UTC, Paulo Pinto wrote:
 - No code that would trigger GC is allowed
Impressive! It definitely won't be anyhing like D or Rust in GC that this sounds wonderous nonetheless! Especially if, even without its core feature, classes, it's worthy as a c++ replacement where applicable. I should really check this at some point.
The relevant point is that according to Miguel de Icaza interview at Unity's booth, the ongoing focus on performance was one of the Then you have developers like Mike Acton which has a strong point of view on where C++ is going on game development, that has
Apr 03 2018