Hello. I am Madhu, a Software Engineer at Resolve AI. We launched our product today. Resolve AI is an AI for production engineers. I will be hanging out here and happy to answer any questions about product/tech.
17 karma · joined March 6, 2012
First off, congratulations on the launch!
I am doing some work around Python tracing using eBPF tools and spending a lot time reading about CPython interpreter and runtime implementation. I came across this Polar Signals blog post[0] last week. Fantastic, fantastic work! I learned a ton about Python internals in just a few minutes that I had completely missed even after reading the code for days. This post also set a benchmark for technical writing for me.
Huge kudos for all the great work! And thank you for sharing all these out!
[0] https://www.polarsignals.com/blog/posts/2023/10/04/profiling...
In the proposal section.
On the other hand, when I think of MIT, the most important contribution to Computer Science that comes to my mind is Seth Gilbert and Nancy Lynch's proof to Brewer's Conjecture, famously called CAP theorem. This proof is so profound, so important to Computer Science and the way we build large-scale computer systems today. And d'uh, it has been left out.
This looks like pure marketing to me. And in some sense misleading.
Also, it comes from the age old debate of whether an Operating System is sufficient to perform a certain type of resource management function or should the application which knows about its own semantics build its own resource manager. One popular incarnation of this is Michael Stonebraker's paper on "Operating system support for database management" - http://www.eecs.harvard.edu/~margo/cs165/papers/stonebraker-... where he discusses if Database management systems should builds its own buffer/caching mechanism or those mechanisms provided by filesystems are good enough. This can be extended to the problem in question now, which is about scheduling of jobs on a huge cluster seen as a single computer.
One of the major reasons (of many others) why we moved Databases to separate machines was because OSes did a bad job at scheduling tasks. Rather than saying bad, I think I should say that it is difficult for the operating systems to understand the types of workloads. However, in this particular case, Google knows a lot more about its workloads and hence can do a better job at scheduling them on the same machine.
Also, it is very important to note that Google has been able to do this because they run 1000s of machines next to each other and everything is distributed. If they can't schedule a task on a particular machine because it is overloaded, they always have the choice of scheduling that task on a next machine in the rack. This may not be the case for most people outside Google. If they are using a single machine to host both the database and the computation itself and if for some reason that machine is already running at its peak, there is no other option than making the tasks to be scheduled wait, because there is no where else to schedule those tasks.
Moving DBs to separate machines was really to keep the utilization at low levels so that there would be cycles available when needed.
EDIT: Typo fixes.
If we could have traded correctness, we could have optimized everything and gone home by now :)
You mean this? https://www.dropbox.com/s/o9wb9k0bbqfc2bw/IMG_20130718_17103...