5 ms·

There is an android native interface. http://developer.android.com/tools/sdk/ndk/index.html http://developer.android.com/tools/sdk/ndk/index.html Games could b

There is an android native interface. http://developer.android.com/tools/sdk/ndk/index.html http://developer.android.com/tools/sdk/ndk/index.html Games could be written in Java. Just intelligently schedule garbage collection and in return you get to use a very fast safe, well-optimized JITed virtual machine. They won't be, of course, they'll be written in NDK because the culture of the game industry is a powerful one, and one that takes pride in their ways. It would be like telling a race car enthusiast that continually-variable transmission is better for racing because even though it's less efficiant it allows the driver to focus on driving and is always in the exact gear needed. The driver would never except this because in their mind they are an amazing driver and manual makes them faster because it is more efficient and makes them feel cool.

pcwalton 13y ago
> They won't be, of course, they'll be written in NDK because the culture of the game industry is a powerful one, and one that takes pride in their ways. It would be like telling a race car enthusiast that continually-variable transmission is better for racing because even though it's less efficiant it allows the driver to focus on driving and is always in the exact gear needed. The driver would never except this because in their mind they are an amazing driver and manual makes them faster because it is more efficient and makes them feel cool. The problems of concurrent garbage collection in games are not imaginary, as you seem to be implying. Keep in mind that 60 FPS allows a maximum of 16 ms of GC per frame, and that's assuming the game has no work to do at all. Turn on the GC profiling sometime in your browser of choice and look at the numbers sometime; then extrapolate that to the slower CPUs and RAM on mobile and you can see why this can be a cause for concern.
- deleted 13y ago
  [deleted]
- DannyBee 13y ago
  but, er, browser gc's are not tuned for this purpose at all, so not sure what that tells you. For a console, it's actually an easier task, because you are not as worried about CPU usage (in the sense that if you use too much CPU, you kill the battery) Metronome, and other garbage collectors, can do consistent bounded near-real or real time time collection with bounded CPU usage. They can hit 6ms without too much trouble.
  - pcwalton 13y ago
    > but, er, browser gc's are not tuned for this purpose at all, so not sure what that tells you. It seems to me that the goals of browser GC's are essentially the same as those of Dalvik: allow Web pages or phone apps to hit 60 FPS. To this end both SpiderMonkey and V8 have incremental GC's. (They actually have an easier time of things because they don't have to deal with multiple threads sharing a single heap.) SM shoots for 7 ms for incremental time slices, as I recall, but in practice the major collections can lead to pauses longer than that. Incremental isn't a panacea in practice; in high allocation or high-CPU-load scenarios you either get pauses if you're soft-real-time or you starve the mutator for resources (which can drop the frame rate of the game) if you're hard-real-time. Ironically, decreasing the time slice can sometimes make the pauses worse, because when you're in an IGC slice more stuff is barriered. > Metronome, and other garbage collectors, can do consistent bounded near-real or real time time collection with bounded CPU usage. Dalvik doesn't use Metronome (or Azul C4, ...). It uses a concurrent GC for minor collections but sometimes has to stop the world for major collections, last I looked (granted, my knowledge is ICS only, so perhaps there have been improvements since then). (Note that I'm not trying to argue that GC's are bad, or that Dalvik's GC is bad, or that a sufficiently good GC wouldn't be good enough for most games; those are questions that would generate more heat than light to debate. I'm simply pointing out that game developers' concerns about Dalvik's GC are not unfounded or imaginary.)
- mistercow 13y ago
  We're getting off topic here, but in what way is a CVT less efficient?
  - asperous2 13y ago
    As a whole it is more efficient, because it always picks a ratio that maximizes torque. When I talk to car enthusists, they always emphasize that it is less efficient, because for each specific ratio, there is more overhead (belts, etc.) than a gear. The point I am trying to make, is that in the real world using Java is like using an automatic: it allows you to focus on the big picture while it optimizing the little bits for you the best it can.
- pjmlp 13y ago
  John Carmack seems to have other opinion https://twitter.com/ID_AA_Carmack/status/342324071004008448 https://twitter.com/ID_AA_Carmack/status/342324071004008448
  - throwaway2048 13y ago
    games are not aiming to be 99.999% uptime reliable software.
    - kayoone 13y ago
      are they not ? If your game crashes constantly no console vendor will let you have it on their platform and PC gamers are also turned off immensly by games crashing. Imo any game developer has to avoid it at all costs.
      - dagw 13y ago
        99.999% means roughly 30 seconds of downtime a month. If you play 4 hours a day every day, that means two periods of 30 second downtime a year. I can't imagine any game even trying to reach that sort of stability. It would be a complete waste of time and resources
        kayoone 13y ago
        you just downvoted me because games dont have 99.999% (in the sense of the word) uptime, which is not what i meant anyway... The thing is, crashes are not acceptable and so measures need to be taken, which is what Carmacks original quote is referring to.
  - pcwalton 13y ago
    It's hard to read into a tweet, but I'm pretty sure that he was not saying that the performance of a dynamically typed, garbage collected language will be equivalent to the performance of optimized, tuned C and C++.
    - 13y ago
shock-value 13y ago
pcwalton already explained that you're underestimating the burden of garbage collection (and I'd add to that that the speed of execution matters more than you realize too). But another real factor is the fact that mountains of code, including complete game engines, have already been written in native languages. Why throw all that out just to program in a language like Java (itself certainly not without its warts)?
- wavefunction 13y ago
  This is assuming you're talking about "twitch" gaming. There's a huge market out there for games that can be written as inefficiently as necessary, since the casual audience is just looking for a diversion from whatever they're doing IRL. It seems like hard-core gamers and game developers forget that pretty frequently.
  - objclxt 13y ago
    ...this may be true, but there's also a huge market for games that run on iOS and Android. And since iOS doesn't support Java, but Android does support C/C++ through the NDK, it makes complete sense to go down that road.
EpicEng 13y ago
I'm curious; how many games have you written? I mean, real games which really push the hardware? Non-deterministic GC sweeps are a non-starter, and not being able to tweak out that last bit of performance to boost your frame rate when needed is a massive technical hurdle. It's just unnecessary. You can write "safe" C and C++, you just have to know what you are doing to begin with. Also, don't forget about the massive amount of native frameworks that have been developed already. Why rewrite an engine which already exists just so you can use Java?
- asperous2 13y ago
  If studios started making games in Java then they would develop more engines for Java. There are a lot of libraries in Java as well. Java has its faults, but it's a higher level language than C++, and that lets people write code in it more quickly.
  - pandaman 13y ago
    Modern game budgets are in range of tens of millions, if Java really gave any significant advantage e.g. 1 month off 24 months project it would be a value of a million or more. Studios would be all over Java just for that reason.
  - drawkbox 13y ago
    The only two really big games made with Java are Minecraft original and Runescape original (still a huge MMO on the web). However most have ported away to reach more platforms. Java is no longer a good option on the web really even. Memory management is a huge problem pushing performance. You can still write efficient Java by doing things like no newing of object in ticks and stack arrays but gamedev is heavy in management of memory access/organization, stack vs heap allocation and other things that take lots of work or are too hard to control in Java or other GC platforms (C#). Though there were a ton more XNA games (C#) than Java even today but that has since been discontinued. Windows Phone 7 also limited its potential due to no native access and requiring XNA only games. Android didn't really take off in games until the NDK in Android 2.3 which was deemed a game developers OS. iOS had it right since the first SDK allowing C/C++ and Objective-C or Objective-C++ which allows mixed that I have seen in all custom engines for iPhone.
asperous2 13y ago
Here is a source that talks about this issue in more detail: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.66.2107&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.66....

pcwalton 13y ago

> They won't be, of course, they'll be written in NDK because the culture of the game industry is a powerful one, and one that takes pride in their ways. It would be like telling a race car enthusiast that continually-variable transmission is better for racing because even though it's less efficiant it allows the driver to focus on driving and is always in the exact gear needed. The driver would never except this because in their mind they are an amazing driver and manual makes them faster because it is more efficient and makes them feel cool. The problems of concurrent garbage collection in games are not imaginary, as you seem to be implying. Keep in mind that 60 FPS allows a maximum of 16 ms of GC per frame, and that's assuming the game has no work to do at all. Turn on the GC profiling sometime in your browser of choice and look at the numbers sometime; then extrapolate that to the slower CPUs and RAM on mobile and you can see why this can be a cause for concern.

deleted 13y ago
[deleted]
DannyBee 13y ago
but, er, browser gc's are not tuned for this purpose at all, so not sure what that tells you. For a console, it's actually an easier task, because you are not as worried about CPU usage (in the sense that if you use too much CPU, you kill the battery) Metronome, and other garbage collectors, can do consistent bounded near-real or real time time collection with bounded CPU usage. They can hit 6ms without too much trouble.
- pcwalton 13y ago
  > but, er, browser gc's are not tuned for this purpose at all, so not sure what that tells you. It seems to me that the goals of browser GC's are essentially the same as those of Dalvik: allow Web pages or phone apps to hit 60 FPS. To this end both SpiderMonkey and V8 have incremental GC's. (They actually have an easier time of things because they don't have to deal with multiple threads sharing a single heap.) SM shoots for 7 ms for incremental time slices, as I recall, but in practice the major collections can lead to pauses longer than that. Incremental isn't a panacea in practice; in high allocation or high-CPU-load scenarios you either get pauses if you're soft-real-time or you starve the mutator for resources (which can drop the frame rate of the game) if you're hard-real-time. Ironically, decreasing the time slice can sometimes make the pauses worse, because when you're in an IGC slice more stuff is barriered. > Metronome, and other garbage collectors, can do consistent bounded near-real or real time time collection with bounded CPU usage. Dalvik doesn't use Metronome (or Azul C4, ...). It uses a concurrent GC for minor collections but sometimes has to stop the world for major collections, last I looked (granted, my knowledge is ICS only, so perhaps there have been improvements since then). (Note that I'm not trying to argue that GC's are bad, or that Dalvik's GC is bad, or that a sufficiently good GC wouldn't be good enough for most games; those are questions that would generate more heat than light to debate. I'm simply pointing out that game developers' concerns about Dalvik's GC are not unfounded or imaginary.)
mistercow 13y ago
We're getting off topic here, but in what way is a CVT less efficient?
- asperous2 13y ago
  As a whole it is more efficient, because it always picks a ratio that maximizes torque. When I talk to car enthusists, they always emphasize that it is less efficient, because for each specific ratio, there is more overhead (belts, etc.) than a gear. The point I am trying to make, is that in the real world using Java is like using an automatic: it allows you to focus on the big picture while it optimizing the little bits for you the best it can.
pjmlp 13y ago
John Carmack seems to have other opinion https://twitter.com/ID_AA_Carmack/status/342324071004008448 https://twitter.com/ID_AA_Carmack/status/342324071004008448
- throwaway2048 13y ago
  games are not aiming to be 99.999% uptime reliable software.
  - kayoone 13y ago
    are they not ? If your game crashes constantly no console vendor will let you have it on their platform and PC gamers are also turned off immensly by games crashing. Imo any game developer has to avoid it at all costs.
    - dagw 13y ago
      99.999% means roughly 30 seconds of downtime a month. If you play 4 hours a day every day, that means two periods of 30 second downtime a year. I can't imagine any game even trying to reach that sort of stability. It would be a complete waste of time and resources
      - kayoone 13y ago
        you just downvoted me because games dont have 99.999% (in the sense of the word) uptime, which is not what i meant anyway... The thing is, crashes are not acceptable and so measures need to be taken, which is what Carmacks original quote is referring to.
- pcwalton 13y ago
  It's hard to read into a tweet, but I'm pretty sure that he was not saying that the performance of a dynamically typed, garbage collected language will be equivalent to the performance of optimized, tuned C and C++.
  - 13y ago

shock-value 13y ago

pcwalton already explained that you're underestimating the burden of garbage collection (and I'd add to that that the speed of execution matters more than you realize too). But another real factor is the fact that mountains of code, including complete game engines, have already been written in native languages. Why throw all that out just to program in a language like Java (itself certainly not without its warts)?

wavefunction 13y ago
This is assuming you're talking about "twitch" gaming. There's a huge market out there for games that can be written as inefficiently as necessary, since the casual audience is just looking for a diversion from whatever they're doing IRL. It seems like hard-core gamers and game developers forget that pretty frequently.
- objclxt 13y ago
  ...this may be true, but there's also a huge market for games that run on iOS and Android. And since iOS doesn't support Java, but Android does support C/C++ through the NDK, it makes complete sense to go down that road.

EpicEng 13y ago

I'm curious; how many games have you written? I mean, real games which really push the hardware? Non-deterministic GC sweeps are a non-starter, and not being able to tweak out that last bit of performance to boost your frame rate when needed is a massive technical hurdle. It's just unnecessary. You can write "safe" C and C++, you just have to know what you are doing to begin with. Also, don't forget about the massive amount of native frameworks that have been developed already. Why rewrite an engine which already exists just so you can use Java?

asperous2 13y ago
If studios started making games in Java then they would develop more engines for Java. There are a lot of libraries in Java as well. Java has its faults, but it's a higher level language than C++, and that lets people write code in it more quickly.
- pandaman 13y ago
  Modern game budgets are in range of tens of millions, if Java really gave any significant advantage e.g. 1 month off 24 months project it would be a value of a million or more. Studios would be all over Java just for that reason.
- drawkbox 13y ago
  The only two really big games made with Java are Minecraft original and Runescape original (still a huge MMO on the web). However most have ported away to reach more platforms. Java is no longer a good option on the web really even. Memory management is a huge problem pushing performance. You can still write efficient Java by doing things like no newing of object in ticks and stack arrays but gamedev is heavy in management of memory access/organization, stack vs heap allocation and other things that take lots of work or are too hard to control in Java or other GC platforms (C#). Though there were a ton more XNA games (C#) than Java even today but that has since been discontinued. Windows Phone 7 also limited its potential due to no native access and requiring XNA only games. Android didn't really take off in games until the NDK in Android 2.3 which was deemed a game developers OS. iOS had it right since the first SDK allowing C/C++ and Objective-C or Objective-C++ which allows mixed that I have seen in all custom engines for iPhone.

asperous2 13y ago

Here is a source that talks about this issue in more detail: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.66.2107&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.66....