1,932 karma · joined March 8, 2016
To restate, if you have a workload where you iterate over your collection ~500 times, and remove an element from the middle ~1000 times, an array will usually outperform a linked list on a modern computer, no matter the size of the list.
It is not until you do removes/adds far more often, and far from the end of the collection, that the linked list will perform better overall.
When the only source of latency is the extra ~16ms added by the composting, you likely can't feel it, but it adds up to other sources of latency that can make things feel bad more often. Such as:
-latency added by text editors depending on their quality and the amount of work they are doing (colors, intellisense, file size, etc).
-latency added by keyboards, some are worse than others
-latency added by monitors. Good ones are in the 1ms range but bad ones can be as high as 40
Sadly the latency on all of these fronts has generally been trending higher as computers have gotten more powerful.
Impartiality can impart political bias if the facts happen to lean one way or the other, as they will from time to time.
Then people with ~500 mile routes that can charge at both ends. grow from there.
Can you maybe provide some back of the napkin math on why not, or a link to someplace that has done this?
It would be, but often times the lack of explicit control causes you to need more verbosity in Java to get around it, because the JIT isn't all knowing. For instance say you want an array of 2D vectors (x,y) and you want them in line in the array for data locality. In C# you just make Vector a struct, and put the structs in the array. In Java you would have to just put float primitives in the array and alternate the x and y and keep track of it by hand. Minecraft suffers greatly from this.
As well, Java won't do anything but the most trivial automatic vectorization, and only on integers, and SIMD can be a huge win at times. I'm looking forward to more complete support droping for .net
>Benchmark game also lacks the benchmark the Mono blog post is all about - developer iteration time.
I don't think you parsed the conversation correctly.
There are still types of cheats that remain possible, like aimbots. Nothing can be done about that.
Benchmarkgame scores reached basically parity between java and C# once .net core 2.0 dropped
.NET selling points:
* you can do some SIMD explicitly, more is coming
* you have control over when things are stack allocated or not. structs, stackalloc, slices
* you have unsigned ints
Yet, there wasn't any politics in it, was tehre?
>As for the article itself, I find it incredibly odd how worked up people get over this stuff. The vitriol of the article is quite frustrating to get over.
I find the people who find it odd when people get worked up about elaborate scheming, odd.
That only kicks in for people with IQs >= 120 and good mental self control. So basically never.
How useful they are depends greatly on what you are doing, and programmers do a great many different things. For many kinds of library development, they can save you massive amounts of time and code, and/or lead to much better performance vs the workarounds available.
I wonder how many people who prefer Go without generics are coming from C++ templates, or Java generics, vs C# or F# generics.