This is great news! As a long-time CACM subscriber, I highly recommend it! There's a lot of breadth across Computer Science topics and the in-depth articles in most issues are v good! I only wish I had more time for it..
> with each allocation limited to 1/4th of the available resources so not individual peak can choke the system.
This assumes that the scheduled workloads are created equal which isn't the case. The app owners do not have control over what else gets scheduled on the node which introduces uncontrollable variability in the performance of what should be identical replicas and environments. What helps here is .. limits. The requests-to-limits ratio allows application owners to reason about the variability risk they are willing to take in relation to the needs of the application (e.g. imagine a latency-sensitive workload on a critical path vs a BAU service vs a background job which just cares about throughput -- for each of these classes, the ratio would probably be very different). This way, you can still overcommit but not by a rule-of-thumb that is created centrally by the cluster ops team (e.g. aim for 1/4) but it's distributed across each workload owner (ie application ops) where this can be done a lot more accurately and with better results.
This is what the parent post is also talking about.
1/4th was merely an example for one resource type, and a suitable limit may be much lower depending on the cluster and workloads. The point is that a limit set to 1/workloads guarantees wasted resources, and should be set significantly higher based on realistic workloads, while still ensuring that it takes N workloads to consume all resource to average out the risk of peak demand collisions.
> This assumes that the scheduled workloads are created equal which isn't the case.
This particular allocation technique benefits from scheduled workloads not being equal as equality would increase likelihood of peak demand collisions.
Indeed, and that's why there are a couple of startups working on new chips and why Google has the TPU. Here's a nice technical talk from Graphcore's CTO about that https://youtu.be/Gh-Tff7DdzU
Was at that talk and it looks very interesting, the team has delivered before.
They just raised more money too - I just wonder how painless the developer experience will be with using their drivers with latest versions of your chosen DL framework, and how price/perf will compare with DL specific tensor processor/GPU hybrids like Volta.
It's impressive how fast TensorFlow has become this popular (judging not only by the number of stars it has but also by the number of other projects in that list related to TF)
I can't recommend this video because I haven't watched it yet but looking at the slides it looks like a good survey talk about generative models and an intro to DCGAN
https://www.youtube.com/watch?v=KeJINHjyzOU
Nitpick: Paxos is a consensus protocol, not " a protocol for state machine replication in an asynchronous environment that admits crash failures.".
Consensus can be used for SMR, atomic broadcast, leader election. One can argue all of these replicate a sort of state machine. However, that dilutes the meaning of state machine replication -- replication of state with durability and performance in mind
The article is an example of using an anecdote ("During our course, the customer remarked that they had a real issue with this new Java 7 and 8 approach to substrings") and a skewed microbenchmark to extrapolate to general advice.
It does address common real scenarios. However, it also causes issues for other common real scenarios. For instance, say you have a CSV parser where you generally only look at a few columns. Under the old system, it wasn't crazy to implement this by, for each field, checking if any unescaping is necessary, and if not (generally the common case) doing a substring. This produces some garbage, of course, but manageable amounts. This approach abruptly gets _far_ slower under Java 7.
I can see why they made the change, but it absolutely did cause problems for real-world use-cases.
The way the change was distributed (in a bugfix release) and (mis)communicated was completely wrong, I definitely agree with that.
As for the parsing example, yes, that's one way to implement this but definitely not the only right one -- if you care only about a couple of fields from a massive string, it depends on your application domain whether you can tolerate the additional memory bloat. What I like about the current behaviour is that the method is less surprising and more GC friendly
Oh, there are definitely other approaches to the problem I mentioned (and in fact approaches which are better than the naive split even under Java 6). Changing it out from under people should have been done a lot more carefully, though.
