Author Topic: Scorched Earth and Fabricators  (Read 10845 times)

Offline LaughingThesaurus

  • Master Member Mark II
  • *****
  • Posts: 1,723
Re: Scorched Earth and Fabricators
« Reply #30 on: March 29, 2013, 09:47:31 pm »
Not to derail the topic, but any time anybody mentions C# I think of the scale of C#. Then somebody goes and mentions F#, which I didn't even know existed. And, you know what? The key of F# major and C# major are both horrible because every single possible black key is played in those keys.

This post was actually brought to you by me playing my piano a little bit to double check that.

Offline contingencyplan

  • Full Member
  • ***
  • Posts: 147
Re: Scorched Earth and Fabricators
« Reply #31 on: March 29, 2013, 10:24:03 pm »
Yea, we don't use goto or whatever, but I'm sure some of the code in our games is war-crimes material when looked at from a "good programming practices" standpoint


Ah, but the big question is whether you use break and continue.
It's worse than that.  I've been known to do this:

Code: [Select]
for(blah;blah;blah)
{
    //...
    switch(blah)
    {
        case blah:
            continue;
    }
    //...
}

Bwahahaha!

OH GOD MY EYES! KILL IT WITH FIRE!! KILL IT WITH FIIIIIRRRRREEEEEEEEEE!!!!!!!!!!ten

But seriously, that's when I'd ask a student something along the lines of "describe the purpose and outcome code to me in one sentence without using the words 'while', 'if', or similar," followed by "now demonstrate that your outcome achieves your purpose." :)



Not to derail the topic, but any time anybody mentions C# I think of the scale of C#. Then somebody goes and mentions F#, which I didn't even know existed. And, you know what? The key of F# major and C# major are both horrible because every single possible black key is played in those keys.

This post was actually brought to you by me playing my piano a little bit to double check that.

Hahahahaha, that's great / horrible. :D How often do composers write songs in those keys, in your experience?

And F# is a functional language (derived from OCaml) on .NET. The language snob in me prefers Haskell from my (limited) experience with both, but if I was going to tackle a real programming problem, I'd probably use F#, in large part because it can interoperate with C# for when you need to do things like I / O and user interaction. I haven't seen enough on how easy that interaction is, though; I just know it's one of its touted / praised features.


Side note: is Insert Quote broken in the forums too?  :o

Offline keith.lamothe

  • Arcen Games Staff
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,505
Re: Scorched Earth and Fabricators
« Reply #32 on: March 29, 2013, 10:36:32 pm »
But seriously, that's when I'd ask a student something along the lines of "describe the purpose and outcome code to me in one sentence without using the words 'while', 'if', or similar," followed by "now demonstrate that your outcome achieves your purpose." :)
The purpose is to perform an action on certain items of a collection, but not all of them :) 

That example isn't quite what I do because there'd generally be more than one case in the switch that would lead to the continue.  Otherwise I'd just use if(blah)continue; unless I expected to need to add more cases later.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline contingencyplan

  • Full Member
  • ***
  • Posts: 147
Re: Scorched Earth and Fabricators
« Reply #33 on: March 29, 2013, 10:44:32 pm »
But seriously, that's when I'd ask a student something along the lines of "describe the purpose and outcome code to me in one sentence without using the words 'while', 'if', or similar," followed by "now demonstrate that your outcome achieves your purpose." :)
The purpose is to perform an action on certain items of a collection, but not all of them :) 

That example isn't quite what I do because there'd generally be more than one case in the switch that would lead to the continue.  Otherwise I'd just use if(blah)continue; unless I expected to need to add more cases later.


Is there some reason that you wouldn't use LINQ to accomplish the same?

Offline keith.lamothe

  • Arcen Games Staff
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,505
Re: Scorched Earth and Fabricators
« Reply #34 on: March 29, 2013, 10:55:52 pm »
LINQ is horribly inefficient?

AIW 1.0 actually used a fair bit of it, I think.  Chris (and I, actually) comes from an enterprise-db background.  We both wanted to use stuff like LINQ when we got into games.

Haha, that didn't last long.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline LaughingThesaurus

  • Master Member Mark II
  • *****
  • Posts: 1,723
Re: Scorched Earth and Fabricators
« Reply #35 on: March 29, 2013, 10:56:32 pm »
I don't really know. I've actually just started with piano this semester, about 10 weeks ago. I've gone a fair bit above and beyond where we're really expected to be, but I do know for a fact that the more sharps/flats there are in a key, the worse it is to really read the sheet music written in that key. I haven't seen too many key signatures that are crazy on the sharps and flats, but Mark Hayes is apparently quite a fan of those. We've been reading his music in Concert Choir, and I imagine it's just a little bit of a nightmare to play in.

Offline contingencyplan

  • Full Member
  • ***
  • Posts: 147
Re: Scorched Earth and Fabricators
« Reply #36 on: March 30, 2013, 09:47:15 pm »
LINQ is horribly inefficient?

AIW 1.0 actually used a fair bit of it, I think.  Chris (and I, actually) comes from an enterprise-db background.  We both wanted to use stuff like LINQ when we got into games.

Haha, that didn't last long.


Were y'all able to determine (and do you remember) what the cause of the inefficiencies was? Was it just because the technology is so new that optimizations don't really exist for it, or was it a more fundamental problem with LINQ?

Offline keith.lamothe

  • Arcen Games Staff
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,505
Re: Scorched Earth and Fabricators
« Reply #37 on: March 30, 2013, 10:14:40 pm »
Were y'all able to determine (and do you remember) what the cause of the inefficiencies was? Was it just because the technology is so new that optimizations don't really exist for it, or was it a more fundamental problem with LINQ?
Well, generally speaking things that have to create iterators or create anonymous methods (or really even reference virtual function tables)... it's just not as fast as array access.  By far.  And if the critical path of the application involves looping over this particular collection and every instruction added to that inner loop body is a significant performance cost...

In obviously-not-performance-critical stuff I've been known to use delegates in a car-like fashion instead of my earlier example's approach.

Also, when we switched from .NET/SlimDX to Unity, which uses Mono, I think we lost a lot of .NET's optimizations.  For one the garbage collector was causing massive frame skip all of a sudden, which was easily traced to our use of "foreach" instead of "for".  Once we removed the iterator-creating-and-discarding foreach and relied on for, the vast majority of our "transient" heap allocation simply went away.  I really prefer foreach for a lot of reasons, but I can't justify multiple-times-a-minute frame/music stutter just so I can have that (it was driving a number of people here nuts).

So, in short:
- There are a lot of places where every instruction counts.  We've learned by experience that we cannot count on the compiler/JIT/CLR/whatever to reduce even foreach into its logical equivalent in minimum-number-of-instructions, much less something like LINQ.
- Avoiding transient heap allocation is critical to avoiding garbage collection, and avoiding garbage collection is critical to the user experience.

Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!

Offline Hearteater

  • Core Member
  • *****
  • Posts: 2,334
Re: Scorched Earth and Fabricators
« Reply #38 on: March 30, 2013, 11:44:51 pm »
Is Mono's foreach implementation really that bad, or is it just the version of Mono you are forced to use right now?  I'm looking at MonoGame right now since XNA is being quietly strangled in its sleep by Microsoft and I'm curious about the performance difference between the two C# implementations.

Offline keith.lamothe

  • Arcen Games Staff
  • Arcen Staff
  • Zenith Council Member Mark III
  • *****
  • Posts: 19,505
Re: Scorched Earth and Fabricators
« Reply #39 on: March 31, 2013, 12:39:36 am »
That was an earlier version of Unity, which was using an earlier version of Mono.  I haven't specifically retested since.

If you'd like to try, I think something like this should do the trick:

Code: [Select]
// have some 100 item collection

GC.Collect();

Int64 step1 = GC.GetTotalMemory( false );

for(int i = 0; i < 100000; i++)
{
    for(int j = 0; j < 100; j++)
    {
         Object obj = collection[j];
         // do non-allocating operation X with obj
    }
}

Int64 step2 = GC.GetTotalMemory( false );

for(int i = 0; i < 100000; i++)
{
    foreach(obj in collection)
    {
         // do non-allocating operation X with obj
    }
}

Int64 step3 = GC.GetTotalMemory( false );

GC.Collect();

Int64 step4 = GC.GetTotalMemory( false );

// somehow output step1, step2, step3, and step4

If the problem is still there, step1 and step2 should be very similar, step3 should be at least somewhat higher, and step4 should be lower.

GC might happen between step2 and step3's measurement, of course.  A more rigorous experiment would be needed to figure out more exactly how bad it is.
Have ideas or bug reports for one of our games? Mantis for Suggestions and Bug Reports. Thanks for helping to make our games better!