Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

How much faster would Unity games/apps be if it used C++?

Discussion in 'General Discussion' started by Arowx, Oct 26, 2013.

  1. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    If Unity provided it's engine as a DLL with header files so users could write their games in C++ instead of C# how much faster would they run?
     
  2. MarigoldFleur

    MarigoldFleur

    Joined:
    May 12, 2012
    Posts:
    1,353
    They'd run as fast as a piece of string is long.
     
  3. dxcam1

    dxcam1

    Joined:
    Feb 6, 2012
    Posts:
    477
    depends on the programmer?
     
  4. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    Or twices as long as half it's length.

    Fact C# and Mono is SLOOOWER than Compiled C++, but the question is how much faster is C++, 2x, 5x the only real way to find out is to ask and hope the good developers at UT who have worked on a C++ version of Unity (Due to the Apple App Store Native apps only policy issue).

    This would not make the Unity game engine run any faster, but it would increase the speed of the game logic we write which could greatly improve frame rates, allowing for more stuff in our 16ms (60fps) game logic window and therefore better games.

    If you're developing in C# then syntactically your code could very easily be converted to C++ (*).

    * yes there would be some gotchas with collections, pointers and references but nothing a programmer could not work through and even automate into a code conversion program. :p
     
  5. XGundam05

    XGundam05

    Joined:
    Mar 29, 2012
    Posts:
    473
    But on modern systems, does it really matter? There have been a whole slew of tests and studies comparing C++ to C#. The thing about those tests, they don't all agree on which is faster. Especially on the tests that are actually meaningful, they can come out tied more often than not. Granted, I think most of them are between .Net and native, so there is that. (If I remember which ones help illustrate my point specifically, I shall link to them...but I has 5 minutes before I need to head out)

    Don't get me wrong, a) I don't want this to turn into another argument on the matter, and b) I LOVE pointers. Love them. I had a recent problem, parameterizing a sweep across a 3D* array that would allow me to sweep in any of the six directions with the same code, wherein the perfect solution was to use pointers...but, I couldn't use unsafe code for this solution, so I had to come up with a bastardized exploit to get around it.

    *It was a 3D array represented in a 1D array in the structure of (x + y * width + z * width * height).
     
  6. dxcam1

    dxcam1

    Joined:
    Feb 6, 2012
    Posts:
    477
    You already can do most of your game logic in C++ though; I've done it with libraries and module interfaces for editor access.
     
  7. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    As an indie game developer working on VR enabled games (it's the future, this time, honest ;)) that need to hit or exceed 60fps or include a vomit bag.

    That gives me < 16ms to run a game world (ideally, according to John Carmack, we should be running at 120fps so < 8ms), anything that takes up a chunk of this time means the game has to be reduced in some way, so in a way using C# Mono is a limiting factor on what the Unity game engine can deliver.

    My understanding is that Mono is now owned by another company and this prevents Unity from progressing to a newer versions of Mono with improved GC, optimisations and features.

    Could now be a good time to take Unity to C++, Unreal Engine 4 has already made this move?
     
  8. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    But isn't this is an indirect linkage, your dll is being called from C# which is being called from the Unity Engine, you gain performance and speed but add another layer of communication and overhead?
     
  9. lmbarns

    lmbarns

    Joined:
    Jul 14, 2011
    Posts:
    1,473
    Optimization? Occlusion culling? Aren't there ways to bring any game to the minimum fps by trading off view distance and reducing overdraw?

    I shipped a game with over 2.5mil polygons and it used the kinect for input and was able to get it running perfectly (had it automated, running 24+ hours without issue). It was on a micro computer 7"x7"x4" form factor with integrated graphics........


    Also worked on an oculus rift + kinect project on a team of 12 that had a badass scene with several thousand draw calls before optimization.
     
    Last edited: Oct 26, 2013
  10. Breyer

    Breyer

    Joined:
    Nov 10, 2012
    Posts:
    412
    its depends on programmer AND TIME - so sometimes c# can be faster than c++ because c# is easier a lot than c++ if we need special optimising (threading? etc.) so c# has faster workflow and you can spend saved time to more optimise in c# (unsafe code?)

    but if performance is only once criteria then c++ is the best option - c++ + assembler rulz ^^
     
  11. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    Yes, but let's say that you do all of the in engine optimisations and get the game running at about 30fps and looking great, your using 33ms so your still over budget by 18ms. How much of that overhead is being used by Mono and C#?

    Also I like to use procedural/dynamic worlds which do not work well with Unity's current static baked occlusion culling system.
     
  12. MarigoldFleur

    MarigoldFleur

    Joined:
    May 12, 2012
    Posts:
    1,353
    If we had a better mono implementation it'd probably help a lot more than all the testing and redocumentation that would be required for adding an entirely new language and workflow.
     
  13. dxcam1

    dxcam1

    Joined:
    Feb 6, 2012
    Posts:
    477
    If you're this hardcore C++ you might wanna migrate to Ogre3D.
     
  14. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,562
    Not much if any speed difference considering most games are GPU bound on most platforms. In cases where you ARE actually CPU bound then yes it can help you a little with *this* version of mono. MS's compiler is gives considerably closer performance to C++ and for inexperienced programmers may even be slightly faster.
     
  15. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    That could really help with performance overall, but your still using Mono which is generally slower than .Net which is slower than C++.

    It is a chunk of work, but in theory Unity could provide the engine as a dll with header files for the C++ programmers to build their games, the interfaces could be very similar to those provided already in C# and API documentation can be automatically generated from comments in the code by the programmers.

    Unity already uses external editors for code it would just mean that C++ projects would work more like the Unity XCode projects for iOS/Mac with an extra step in the build/run process.
     
  16. MarigoldFleur

    MarigoldFleur

    Joined:
    May 12, 2012
    Posts:
    1,353
    As mentioned earlier, "slower" is an incredibly difficult to quantify term in these cases. Adding C++ support might not necessarily provide any realistic performance increase since most of what's happening in Unity is handled at lower levels by the engine itself.
     
  17. JamesLeeNZ

    JamesLeeNZ

    Joined:
    Nov 15, 2011
    Posts:
    5,618
    If you are only talking about the scripting side, probably not much.

    If it gave us more access to the internals of the engine, ie physx, you could completely change up the engine for your needs (or mess it up. ha)
     
  18. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    For simpler games, yes, but if you take an RTS style game e.g. Starcraft or a Simulation style game e.g. Civ with layers of systems dealing with things like pathfinding, strategic AI, unit behaviours and dynamic systems and lots of active units then C#'s overhead is a limiting factor.

    Most benchmarks indicate that a C++ program takes a fraction of the time to run of a similar C# program how much of a fraction varies between programs.

    Games written in C++ perform better than C# quite simply because you are batch processing the JIT compilation so it does not need to be done at all, in addition to this C++ compilers can see the whole of the project and optimise accordingly JIT compilers are limited in their optimisation scope.

    Yes there will be cases where C# can go toe to toe with C++ but C++ did not have to do any JIT compilation so it was already in the lead.
     
  19. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    OK let's put it another way, what is the most complex game you have seen developed with Unity, by complex I mean big open world games with very high unit counts and or complex layers of simulation like Civ?

    Are there any RTS's, MMO's, Sims made with Unity that just blow you away with the number of enemies active at any one time?
     
  20. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    So Unity becomes a modular framework and all the module providers have to do is provide appropriate interfaces. But couldn't that leave Unity open to being a frontend for the Unreal or Crytech engines?
     
  21. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,194
    For the most part I don't this the lack of such games has as much to do with script code not being in C++ as much as it has to do with:

    1) No streaming / manual resource management support, making it very difficult to work with open-world-sized resources in a build
    2) No 64-bit editor, making it very difficult to work with open-world-sized resources in the editor
     
  22. Deleted User

    Deleted User

    Guest

    A 64-Bit editor would be very nice..
     
  23. AndrewGrayGames

    AndrewGrayGames

    Joined:
    Nov 19, 2009
    Posts:
    3,823
    Agreed. Later Mono implementations have known performance increases. I vote for this.

    Also, speaking as someone working on improving my design abilities (I already write code for my day job), I wouldn't see why we would want to go down to C++.

    C++ is generally fast because it can be very low-level (e.g. memory operations), which is good for console development or performance-critical projects. However, for someone writing a 'simple' iOS or Android game, the level of abstraction that a managed language like C# operates at is just fine; instead of worrying with low-level things like memory management, I can focus on writing game logic and integrating assets.

    I agree with others who say, 'we need performance improvements', particularly in regard to garbage collection. But I'm not sure C++ is necessarily the right way to go to get that.
     
  24. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,562
    You knew this would set me off again.

    Yes, really... the slowest part of game development in Unity are the programmers themselves. I mean, for most C# vs C++ arguments, its the method not the language that's going to be the slow part. I mean we can always spread calculations across frames or thread it.

    I really need that resource management stuff. Specially for what is coming now we've got a reasonable budget on the table coming up.
     
  25. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    What about threading the the first tool a game developer is going to go for to offload work that makes a "layered" world come alive but does not impact game fps is threading.

    So if my Unit is off screen and is not being drawn how comes it still takes up time in the main thread, could Unity provide an off screen thread for non-rendered active components?
     
  26. Jaimi

    Jaimi

    Joined:
    Jan 10, 2009
    Posts:
    4,812
    You can write just as bad code in c++ as you can in C#. Meaning: the language you use will be way less important than the algorithms you use.
     
  27. Arowx

    Arowx

    Joined:
    Nov 12, 2009
    Posts:
    7,116
    For a simple game you will be mostly writing code in extended versions of the Monobehaviour class so therefore memory allocation and clearing are not even an issue as Unity handles the instantiation and destruction of these objects. Also with C++ Unity can provide a memory management system that would ensure a games memory is allocated and used appropriately. All developers would have to do is use a Monobehaviour class that uses the system or a sub-class that allows them to create normal objects that use it, as long as they tell Unity when it is no longer needed.

    Instead of relying upon a generic Garbage collection system we could have a system that provides pooling and object re-activation under the hood and only discards objects when instructed to do so.
     
  28. Dustin-Horne

    Dustin-Horne

    Joined:
    Apr 4, 2013
    Posts:
    4,562
    You could do that with C# if you want to. Just pre-initialize a bunch of objects and pool them, then only use from the pool. As long as they don't ever go out of scope they won't get collected and if you were able to avoid allocating any new memory on the heap (not sure that's possible with Unity but it was with XNA) then you can avoid having the GC ever run automatically at all.

    No, as far as performance, C++ is "generally" faster, but as others have said, it depends on the programmer. But if you had functionally equivalent and similarly written code, the code itself will perform virtually identically in both. The differences you'd actually see are all related to garbage collection and this can be nearly eliminated or managed by careful programming.

    Now, you also mentioned earlier switching between the two languages and how "easy" it would be because the syntax is similar. Syntax isn't the issue. In fact, C# is a really easy language to learn, but the .NET Framework itself (in its entirety) is simply massive and takes longer to learn than the languages. A person starting out could become proficient in C#, F# and VB .NET from a syntax and style perspective without ever mastering a significant portion of the framework. That all being said, there's a massive difference between C# and C++. One is managed and one is not. It's not just about syntax. It's a whole different way of thinking because you have to carefully manage those resources yourself.
     
  29. RElam

    RElam

    Joined:
    Nov 16, 2009
    Posts:
    375
    The parts of most games that are a bottleneck, rendering, physics, particles, etc. are already in C++, and seem decently fast. The key to optimization is optimizing that which needs it, not optimizing everything (this assumes you do not have infinite developer resources and time, if so, then you don't have to follow good practices :)). Ultimately we're talking about a matter of scaling, and if the argument is your game is truly less fun if it's pushing 20% less 'things', then I'd love to hear that design. Even 2X less 'things', I think we're well past the point in technology where that is a blocking factor in game design.
    This is not, IMO, the problem. The problem with current garbage collection is not that it's slow, precisely, but that there's not a low latency version of it. The .net spec has a low latency garbage collector (GCLatencyMode) but it doesn't work in mono (at least the version we're using). While faster (insert sub system here) would be better, the solution to our GC problems seems to be the support of that feature, not a replacement of the GC system/overall behavior. In short, the GC is missing a feature, not a refactor, IMO.
     
  30. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,562
    Unity's main slowdown will be chucking more on screen than the GPU can handle, and this is generally the developer's fault. Unity isn't a magic bullet (no engine is). If you look at the insane stuff Naughty Dog did with streaming, on a PS3, then you appreciate how much work can be required. Lucky for most, times have changed and the hardware is back to managing how much vertex processing you're using, how much fragment processing you're using and if you're threading in a good way. Threading isn't going anywhere. It's here to stay. For the most part, you want unity to deal with that and only thread if you really have to.

    And threading is a massive can of worms.

    Streaming isn't just going to be solved by threading something. It has to be solved in engine source, because part of the problem isn't getting the data, it's the stalls when you have the data. And I'm not all that sure what Unity can do about it at this point in time without some prior pieces in place.
     
  31. superpig

    superpig

    Quis aedificabit ipsos aedificatores? Unity Technologies

    Joined:
    Jan 16, 2011
    Posts:
    4,194
    Well, no - the 'first tool' a game developer is going to go for to offload work is to avoid doing the work in the first place. The second tool is to do as much of the work as possible at build time, instead of at runtime. Threading's probably, like, fifth.

    That the unit is offscreen makes very little difference. The difficult problem with threading (and I mean really difficult) is synchronisation; it's nontrivial to write code that has completely consistent behaviour when used by multiple threads simultaneously. You can't really just pick up an arbitrary chunk of code and farm it off to another thread and still have it work.

    Also, bear in mind that threading is already possible in a number of circumstances. You can spin off secondary threads at the moment. You just can't touch the Unity API from them.
     
  32. TylerPerry

    TylerPerry

    Joined:
    May 29, 2011
    Posts:
    5,577
    Wow, your a mod? Thanks for donating your time :)
     
  33. Yoska

    Yoska

    Joined:
    Nov 14, 2012
    Posts:
    188
    Okey this discussion is above my league and this might be a bit besides point but I believe Civ V and IV both use scripting languages for game logic. Lua and Python respectively. But then again Firaxis' tech is delicated for that style of games and I have no idea for how much stuff they actually do use those languages for. Might be 99.99% C++.
     
    Last edited: Oct 27, 2013
  34. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,039
    Considering that plenty of in-house game engines use languages like Lua for their scripting by choice despite having direct access to C++ already I think it's pretty clear that there are benefits to be had by stepping out of C++ land. C++ might indeed be a faster language, but - like any other optimisation - unless your language is your bottleneck then changing it won't help.

    A faster language does not necessarily lead to faster execution. The places where the benefits of C++ are most pronounced are the places where Unity already uses C++ exclusively - the low level engine code.

    At performance programming classes I've attended the game logic that we put in scripts is what's typically known as "slow code" by performance programmers. It's called that because by its nature it often does stuff that there's not a lot of benefit to optimising at the low level, often because more time is spent accessing memory than actually executing instructions, even when implemented in a slower language.
     
  35. im

    im

    Joined:
    Jan 17, 2013
    Posts:
    1,393
    here take a look

    c++ vs c#.net
    http://www.codeproject.com/Articles/212856/Head-to-head-benchmark-Csharp-vs-NET

    c++ vs mono
    http://benchmarksgame.alioth.debian.org/u64q/benchmark.php?test=all〈=csharp&lang2=gpp&data=u64q

    .net vs mono
    http://geekswithblogs.net/CISCBrain/archive/2005/08/28/Mono_vs_dotNet_Performance_Test.aspx

    also keep in mind the mono/.net have just in time compilers (jit)

    so that really helps over purely interpreted msil bytecode.

    well that is with microsoft .net, mono .net can at times be slower and use a whole lot more memory. :(

    and to make things a worse the version of mono integrated with unity is really old and from what ive read even slower, fatter and buggier...

    so hopefully unity will update mono in the not too distant future

    and it would really be nice if they would give ability to use microsoft .net runtime eventually...

    still it depends on the programmer. and how they do things. i mean they could code a really bad data structures/algorithms.

    but all being equals assembly language, c, c++ and then something like .net, and then java and other managed jitted languages and towards the end (being worse) is like lua which many games developers use, why because its not jitted so no native compiler and it does not support native threading so all the game logic will run in a single thread on a single core.

    i know there is luajit, but they dont use it. they use luaplus for the most part and it does not support luajit. i did luaplusjit, but i dont know of any game that uses it. i guess they are too lazy to link against some other library...

    lua in general is up there with unreal script both about 20x or more slower than natively jitted languages like c# or even luajit...

    re: civ

    from what i recall they use lua, most likely luaplus. lua plus is just lua but c/c++ interface to it. the thing is its very dated and not really supported anymore. lua/luajit is where its at now for the lua crowd.

    personally i think they should give up on lua and head over to mono/java where its even better. its hard to do a little language without all the $$$$$ and developers that the big guys like oracle(sun) java and microsoft (novell) have with .net...
     
    Last edited: Oct 28, 2013
  36. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,145
    They already do, if you're publishing to Windows 8 store or WP8—that's why you can't use obsolete collections like ArrayList and Hashtable on those platforms, since they've been removed from the latest .NET. And there have been various performance complaints; apparently some aspect of it is slower than Mono...so don't assume that it's magically better. I think this idea that the version of Mono currently in Unity is so terrible, and upgrading it will make everything a million times better, is perhaps not actually based on reality. (That's not to say that it couldn't be improved, just don't expect anything earth-shattering in real-world usage.)

    --Eric
     
  37. im

    im

    Joined:
    Jan 17, 2013
    Posts:
    1,393
    re: hashtable / arraylist

    i have latest visual studio / .net and i have no problem using ArrayList and Hashtable. its in using System.Collections;

    metro is not desktop. its more limited api like on mobile devices. winrt (metro) is more like compact .net so its a subset they take out stuff. in this case they took out non generic collections.

    anyways i would not be there if i could help it..

    although i dont do metro. why reward/encourage/support bad behavior/decisions...

    bad enough that i have to run windows 8.1 the last thing i want it anything to do is spend time there...

    ? does that work for windows desktop game or metro games?

    i dont do metro, but i repeat myself, im starting to sound like sam-i-am out of green eggs and ham ;)

    i meant for windows desktop games. like the ones i play with..

    also i did not say .net is always better/faster/smaller than mono

    look at the link i give

    i didnt say million times faster. and i did not say horribly terrible or magically better

    but a lot of improvements and bug fixes to mono, including the garbage collector...

    there are number of threads on the version of mono with unity and that garbage collector...

    i dont expect anything but what they improved and fixed and it would be nice if we did have it in some upcoming release of unity...

    and it would be nice if i could run the editor and if not the games in microsoft .net runtime. without metro...

    also metro .net apis are subset of desktop .net api
    http://msdn.microsoft.com/en-us/library/windows/apps/br230232.aspx

    i personally dont like metro.

    also metro application go through additional security scrutiny and limitations which can result in them running slower and having issues cause the loops it and one has to play.

    basically microsoft runs them walled off sandbox container and its expensive to get in and out, if not outright difficult and/or impossible. its more designed for phone... or like browser...

    here take a look
    http://www.extremetech.com/computin...ction-in-windows-8-is-an-absolute-train-wreck

    plus its hard to find benchmarks. cause i dont know of anyone doing modern ai (modern in name only, cause its a step back in time and functionality)

    so i would not judge desktop .net by metro .net, personally i would not waste my time there. i guess it great for app store games, but i dont play any of them. apple did better job, although i dont like their dev tools, languages, libraries. sort of something out of time.
     
    Last edited: Oct 28, 2013
  38. TylerPerry

    TylerPerry

    Joined:
    May 29, 2011
    Posts:
    5,577
    Metro games AFAIK.
     
  39. MarigoldFleur

    MarigoldFleur

    Joined:
    May 12, 2012
    Posts:
    1,353
    This would be true if they updated to 2.8 and not 3.x
     
  40. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,039
    I'm pretty certain that you're right. I'm sure that Unity wants to improve things as much as any of us do, and they've experimented with it before, so I'm sure that if it was going to make such a pronounced difference they'd have gone ahead and done it.

    So you honestly believe that 3.x would give us "magically better" results?
     
  41. MarigoldFleur

    MarigoldFleur

    Joined:
    May 12, 2012
    Posts:
    1,353
    In a lot of senses, yes. Especially when it comes to things like Unity's terminally slow garbage collection.
     
  42. TylerPerry

    TylerPerry

    Joined:
    May 29, 2011
    Posts:
    5,577
    A completely off the top guess of mine is that Unity is working on their own implementation of the .NET framework, that will come in Unity 6.2.3. With the framework will come the new unified renderer that will fix all the issues on all the platforms, the word "Unification" will be spoken of heaps and will get old real quick.
     
  43. im

    im

    Joined:
    Jan 17, 2013
    Posts:
    1,393
    here is my take on metro ui

    parody of Dr. Seuss' Green Eggs and Hame
    https://en.wikipedia.org/wiki/Green_Eggs_and_Ham

    Code (csharp):
    1.  
    2. I am Sam
    3.  
    4. I am Sam
    5. Sam I am
    6.  
    7. That Sam-I-am
    8. That Sam-I-am!
    9. I do not like
    10. that Sam-I-am
    11.  
    12. Do you like
    13. metro modern ui
    14.  
    15. I do not like it,
    16. Sam-I-am.
    17. I do not like
    18. metro modern ui.
    19.  
    20. Would you like it
    21. Here or there?
    22.  
    23. I would not like it
    24. here or there.
    25. I would not like it
    26. anywhere.
    27. I do not like
    28. metro modern ui.
    29. I do not like it,
    30. Sam-I-am
    31.  
    32. Would you like it
    33. in a house?
    34. Would you like it
    35. with a mouse?
    36.  
    37. I do not like it
    38. in a house.
    39. I do not like it
    40. with a mouse.
    41. I do not like it
    42. here or there.
    43. I do not like it
    44. anywhere.
    45. I do not like metro modern ui.
    46. I do not like it, Sam-I-am.
    47.  
    48.  
    49. Would you use it
    50. in a box?
    51. Would you use it
    52. with a fox?
    53.  
    54. Not in a box.
    55. Not with a fox.
    56. Not in a house.
    57. Not with a mouse.
    58. I would not use it it here or there.
    59. I would not use it anywhere.
    60. I would not use metro modern ui.
    61. I do not like it, Sam-I-am.
    62.  
    63. Would you? Could you?
    64. in a car?
    65. Use it! Use it!
    66. Here it is.
    67.  
    68. I would not ,
    69. could not,
    70. in a car
    71.  
    72. You may like it.
    73. You will see.
    74. You may like it
    75. in a tree?
    76. d not in a tree.
    77. I would not, could not in a tree.
    78. Not in a car! You let me be.
    79.  
    80. I do not like it in a box.
    81. I do not like it with a fox
    82. I do not like it in a house
    83. I do mot like it with a mouse
    84. I do not like it here or there.
    85. I do not like it anywhere.
    86. I do not like metro modern ui.
    87. I do not like it, Sam-I-am.
    88.  
    89. A train! A train!
    90. A train! A train!
    91. Could you, would you
    92. on a train?
    93.  
    94. Not on a train! Not in a tree!
    95. Not in a car! Sam! Let me be!
    96. I would not, could not, in a box.
    97. I could not, would not, with a fox.
    98. I will not use it with a mouse
    99. I will not use it in a house.
    100. I will not use it here or there.
    101. I will not use it anywhere.
    102. I do not like it, Sam-I-am.
    103.  
    104.  
    105. Say!
    106. In the dark?
    107. Here in the dark!
    108. Would you, could you, in the dark?
    109.  
    110. I would not, could not,
    111. in the dark.
    112.  
    113. Would you, could you,
    114. in the rain?
    115.  
    116. I would not, could not, in the rain.
    117. Not in the dark. Not on a train,
    118. Not in a car, Not in a tree.
    119. I do not like it, Sam, you see.
    120. Not in a house. Not in a box.
    121. Not with a mouse. Not with a fox.
    122. I will not use it here or there.
    123. I do not like it anywhere!
    124.  
    125. You do not like
    126. metro modern ui?
    127.  
    128. I do not
    129. like it,
    130. Sam-I-am.
    131.  
    132. Could you, would you,
    133. with a goat?
    134.  
    135. I would not,
    136. could not.
    137. with a goat!
    138.  
    139. Would you, could you,
    140. on a boat?
    141.  
    142. I could not, would not, on a boat.
    143. I will not, will not, with a goat.
    144. I will not use it in the rain.
    145. I will not use it on a train.
    146. Not in the dark! Not in a tree!
    147. Not in a car! You let me be!
    148. I do not like it in a box.
    149. I do not like it with a fox.
    150. I will not use it in a house.
    151. I do not like it with a mouse.
    152. I do not like it here or there.
    153. I do not like it ANYWHERE!
    154.  
    155. I do not like
    156. metro modern ui!
    157.  
    158. I do not like it,
    159. Sam-I-am.
    160.  
    161. You do not like it.
    162. SO you say.
    163. Try it! Try it!
    164. And you may.
    165. Try it and you may I say.
    166.  
    167. Sam!
    168. If you will let me be,
    169. I will try it.
    170. You will see.
    171.  
    172. Sam!
    173. Now that I have tried it,
    174. Now you will see,
    175. I still do not like metro modern ui!
    176. I do not!! I do not like it, Sam-I-am!
    177. So now you let me be!
    178. And I still would not use it in a boat!
    179. And I still would not use it with a goat...
    180. And I still will not use it in the rain.
    181. And I still will not use it in the dark.
    182. And I still will not use it on a train.
    183. And I still will not use it in a car.
    184. And I still will not use it in a tree.
    185. It still is no good, not good you see!
    186.  
    187. So I still will not use it in a box.
    188. And I still will not use it with a fox.
    189. And I still will not use it in a house.
    190. And I still will not use it with a mouse.
    191. And I still will not use it here and there.
    192. Say! I still will not use it ANYWHERE!
    193.  
    194. I still do not like
    195. metro modern ui!
    196. Sam-I-am
    197.  
     
    Last edited: Oct 28, 2013
  44. TylerPerry

    TylerPerry

    Joined:
    May 29, 2011
    Posts:
    5,577
    That didn't work... it was meant to rhyme and it didn't... this is madness!
     
  45. im

    im

    Joined:
    Jan 17, 2013
    Posts:
    1,393
    i failed poety ;)
     
  46. npsf3000

    npsf3000

    Joined:
    Sep 19, 2010
    Posts:
    3,832
    There's one out there that deals with tens of thousands of units... but who cares about facts when hyperbole suffices?
     
  47. TylerPerry

    TylerPerry

    Joined:
    May 29, 2011
    Posts:
    5,577
    What game?
     
  48. angrypenguin

    angrypenguin

    Joined:
    Dec 29, 2011
    Posts:
    12,039
    I could be wrong, but didn't even the community's most vocal opponent of the current GC system end up deciding that it was better to pursue the ability to eliminate allocation than improve collection?
     
  49. MarigoldFleur

    MarigoldFleur

    Joined:
    May 12, 2012
    Posts:
    1,353
    Yeah, great.

    So what about third party assets? What about the increased dev time for lower power hardware targets? Yes, limiting allocation is a good idea, but that doesn't change how awful Unity's GC is.
     
  50. im

    im

    Joined:
    Jan 17, 2013
    Posts:
    1,393
    re: Unity's GC

    isnt it mono gc

    or did unity write their own gc and not use mono gc