3 ms·
Difficult to say. Writing in C doesn't magically make code run faster, and it's entirely possible to get abysmal performance compared to a better implementation
by 10098 13y ago
Difficult to say. Writing in C doesn't magically make code run faster, and it's entirely possible to get abysmal performance compared to a better implementation in a high-level language.
That being said, it probably wouldn't be too difficult to make something better in terms of performance than minecraft, because its perceived perf sucks now as far as I can tell from running it on my machine: sometimes rendering lags, I regularly see mobs "suspended" in the air while the terrain renders (and yes, this happens within "old" chunks too, so I can't say that terrain is being generated or something like that), and I'm not even on weak hardware, it's a gaming laptop that runs modern AAA titles smoothly. Not sure what the source of these problems is, maybe my drivers, maybe mojang screwed up. I didn't notice these things happening on earlier versions which I ran on a fairly weak linux machine with a crappy intel graphics chip.
- tmikaeld 13y agoI bought Minecraft very early, and the more "features" that they added the worse the performance got. Adding shaders and better lighting as they are doing now, will make my gaming computer go to a crawl completely. Though it's quite known that opengl performance on java is lacking and it does not seem to have any easy fixing.
- coldtea 13y ago>Difficult to say. Writing in C doesn't magically make code run faster, and it's entirely possible to get abysmal performance compared to a better implementation in a high-level language. That's the theory, but in practice, the kind of programmer that is competent enough to pull it off in C, is also the kind of programmer that will give it better performance than the one writing it in some not very game-suitable higher level language (say Python or Java).
- pkolaczk 13y agoIt is still difficult to say. IMHO C at scale requires often trading performance for architectural simplicity. E.g. relying on function pointers for indirection (or switch) or passing things by value / deep copy to simplify memory management are techniques which would often degrade performance than boost it, relative to Java. In real big code, you have to do some higher-level abstractions or your project is going to be unmaintainable spaghetti mess, and it is arguable if C lets you build them in the most performant manner.
- coldtea 13y agoI've never really seen any Java project for high performance stuff outperform a C/C++ based on. Visualization tools, video processing tools, multimedia tools, games, etc -- all Java examples I've seen come worse off that the C/C++ equivalents. It's true that in large scale C you often trae performance for architectural simplicity. But in a higher level you trade performance for everything, even the most basic operation has some added complexity layer. And you don't even have as much say as where you'd trade performance for architectural simplicity in, as you do in C/C++, since some parts you just can't do without.
- erichocean 13y agoSame...until the GC kicks in. Then the app locks up for 60+ seconds at a time every few hours, at which point the developers start moving anything memory intensive out of Java to avoid the pauses, and/or reduce their severity (c.f. Cassandra). At that point, is it really Java? You might as well use a scripting language to integrate with all that C...
- pkolaczk 13y agoYes, Cassandra is Java, even if a few tiny parts were moved off-heap. And no, the off-heap parts aren't programmed in C nor C++, it is still Java all the way down. Scripting language + C is a valid solution for many problems, IMHO often much better than a jack-of-all-trades-master-of-none solution like C++.
- frowaway001 13y ago> Then the app locks up for 60+ seconds at a time every few hours Given that the GC can generally process 1GB of live objects per second, I'd love to see an example where you have been working with 60GB+ heaps.
- pkolaczk 13y agoAnd this is not taking into account that modern GCs do most or all of the work either without stopping the mutator (CMS, C4) or incrementally (G1), in smaller chunks. Times of STW collectors are long gone.