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.
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
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 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
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.
The talk is about the system's design decisions, not about ML. Bits I found interesting:
* Tushar Chandra believes soon ML primitives will be available to application developers just like nowadays distributed and db primitives are becoming available in a standard way
* There was an early design decision for Sibyl not to be build on top of a custom distributed system solution but instead to rely on existing primitives such as MapReduce and GFS.
* 100B+ training examples with 100s features per example, use cases with 50TB of data
* Because logging all the features of each examples can make the logs grow extremely fast and because some features might be experimentally used and come and go, the logs would contain only the example id and then before training the model, the data will be inner joined with the example database/GFS
* Examples were stored as columns (partition by features, each file containing 1 feature for many examples) instead of the more common approach of partitioning per row where you store all features of a batch of examples in the same file. This had great benefits in terms of faster feature transformations, less data to be read because some features were less useful than others, and better compression of the data. Further feature compression achieved by finding all unique feature values and mapping them to numbers in a Huffman encoding way. Total compression achieved was 3-5 times
Towards the end, the talk contains some use cases with big numbers (throughput per core, for e.g.) worth checking out
I've been using HabitRPG on a daily basis since April and overall I find it useful. Things I like:
- by far the thing I like the most is the streak counter on the dailies. It's quite rewarding to see you've done your morning light workout 120+ days in a row -- there's just no chance that you are gonna break that chain just so that you nap 10 more minutes!
- low management overhead - I usually spend 1-2 minutes on the website
- character gamification: getting random food and pet drops and critical chance for gold rewards; upgrading items with that gold -- all of these are completely useless :) but even so, these things do give you a tiny mental push to do that extra remaining task. Health and Experience points have similar effects -- I've had days where my character was low health and it was getting towards the end of the day (you lose health if you missed some dailies), which made me consider whether I could quickly achieve one of the remaining tasks
- distinction between daily tasks that are a 'must' and habits that are 'nice to have' but I don't want to do every day.
I don't use the social aspect of it, so I cannot comment on that.
To me, it seems the same as the distinction made in SICP.
As for DP, I think it also comes very close to being the same as the above two. The one difference I can think of is that with DP you often have access to the entire build-up data structure you are creating, rather than only the latest (previous) level you have with an iterative process.
Somewhat offtopic but I think there's a chance someone here might be able to help.
I had applied through Amazon's website for a graduate position nearly 2 months ago and according to the dashboard, my application is still under review but I have never heard from anyone. I think my application has been stuck in some limbo and is now invisible to HR. I tried looking for a relevant email so that I can follow-up but this has been impossible. Granted, I found a graduate email I had written down 1 year ago but so far haven't had any reply and the email seems deprecated because its not advertised on the website anymore. Even on on-campus events, Amazon recruiters would give only the website address, no emails.
Could anyone perhaps point me to someone I could ask to have a look?
edit: To clarify, I am certain the application has not been rejected. I also do believe I am at least worth looking into hehe ;)