Bram Cohen

Classically speaking, it's hard to get linear scaling for a large number of cores. Eg, on a small, 128 core machine, one algorithm I did recently gives maximum throughput with 15 cores, and that only gives a 10x speedup. To make effective use of all 128 cores I would have to pay a lot more attention to how the data flow maps to the architecture. That's hard. For example, one of the older pieces of hardware used a ring-based topology, which was more appropriate for a force decomposition, while another network architecture made a spatial decomposition easier. And on that old ring-based topology system, the previous developers could program the network chip to handle I/O while the CPU was doing the dynamics, in order to eek out even more performance.

In general, if you scale by more than one or two orders of magnitude then you're going to run into new, unexpected problems.

In one project I worked on, the code was fast on all of the test sets, but when scaled up to the entire data set it was unexpectedly slow. We traced that down to a logger which we hadn't realized was enabled. In your code you might find that a minor piece of code used order n-squared time but because of data partitioning, it has minimal impact.

Or you might find that you have a barrier, where everything is supposed to be synchronized. (Eg, once every 1,000 time steps you rebalance the system load.) A few stragglers might not affect small system sizes, but cause 50% slowdowns with large numbers of CPUs. You…

There is a lot to be said for the entirety of your question, but i'll try to focus on this since it stood out to me (plus the interest of time):

>System design rounds require me to solve problems that the top engineers in the world spend months on. One question I was asked was "How do you make sure that a celebrity's tweet reaches all of her followers in less than 3 seconds?". I had no idea, I have never handled that kinda scale. In fact most of my work experience is kinda vanilla and boring, so I generally have nothing much to draw on or much to talk about.

System Design rounds are going to be difficult. The idea isn't to give a correct, complete answer. It's to see how well you can reason about a hazy problem based on your current knowledge. Bram Cohen who wrote BitTorrent has this to say:

"My suggestion for learning software architecture is to practice. Obviously you can't practice it by doing hundreds of projects, because each one of them takes too long, but you can easily design a hundred architectures for problems which only exist on paper, and where you strive to just get the solution to work on paper. Start by modifying the requirements of a problem you're working on. What if the amount of bandwidth or CPU was a hundredth what it currently is? What if it were a thousand times? A million? What if you had a thousand times as much data? A million? A billion? What if the users were untrusted and you had to either prevent them from damaging the system or have a means…

It's interesting that Bram (I assume it's still Bram's show over there) has finally gone with a new streaming-optimized protocol design. We argued about it years ago.

Here's Bram in 2004 arguing that live streaming is a niche market: http://bramcohen.livejournal.com/4294.html

In the comments, "streamerp2p" is discussed, which I used as the basis for a proposal for live radio station streams along with Speex, back ~2005, when bandwidth was expensive. It's still around, apparently: http://www.streamerp2p.com/

Bittorrent itself can do streaming of static content: just request the blocks in order. It can also do streaming of live content if you chunk the live content and have an out-of-band way to update the torrent you're looking for, but that's not great.

In my proposal I mention some other systems as well:

Peercast: http://web.archive.org/web/20060207013338/http://www.peercast.org/ (defunct, Internet Archive link)

P2P-Radio: http://p2p-radio.sourceforge.net/ (defunct)

Allcast: http://web.archive.org/web/20060805040005/http://allcast.com/ (defunct, Internet Archive link)

Chaincast (dead and blocked from IA)

Abacast: http://web.archive.org/web/20061017041905/http://www.abacast.com/ (IA link, they're still around but now cloud-based)

Xiph's IceShare: http://wiki.xiph.org/IceShare (defunct)

Robert Haarman's StreamDist prototype: http://inglorion.net.nyud.net:8090/software/#streamdist

Andrew Brampton's research and prototype:…

If you read the comments one reason FreeNode is in disarray is because Rob Levin who ran the site died in a bicycling accident a few years ago.

In fact the chaos and drama at FreeNode might be the real story here.

http://bramcohen.livejournal.com/72298.html?thread=1000554#t1000554

Fragglet writes (in the comments):

"This shouldn't be surprising to anyone with any experience of Freenode. Freenode is a perfect example of how open source projects tend to acquire the personality of their founder. In the case of Freenode, that founder was Rob Levin, famous for his online begging over wallops and for being completely incompetent in general. Levin's incompetence, begging and dictatorial style where he branded everyone who disagreed with him a "troll" gradually alienated all the sensible and technically skilled people from the network staff until the only people left were his equally incompetent sycophantic underlings.

"When Levin died several years ago as a result of his own stupidity (riding a bike without a helmet), they took over. I haven't heard of mquin before but it looks like the cycle continues.

"Your best option is to close the Freenode channel and move to OFTC, the staff of which consist mostly of the sensible and technically skilled people who left Freenode."

Here are some links with more details,

http://www.theregister.co.uk/2003/01/29/buy_a_piece_of_net/

http://antisec.wordpress.com/2006/06/27/eyeballing-rob-levin/

IMHO the limiting factor can be described as "semantic density". If you look at non-LCS diff algorithms like patience diff [1] and think about where it falls down, its on cases where its very arguable that the code is poor - too much duplication therefore low semantic density. I think (and am attempting to further this at work for non-code) that the effective key is to do something like patience diff on characters but looking at the context of the individual characters when determining whether they are unique.

The benefit here is that you don't need to know about the parse tree, don't depend on special characters to delimit elements (newlines), and don't get LCS type diffs that aren't based on any sort of semantic intuition beyond that the minimal change is probably what was meant.

[1] http://bramcohen.livejournal.com/73318.html

https://bramcohen.livejournal.com/4563.html ... the founder of bittorent.

Ill add a personal note. Being a good professional programmer is also about understanding the context of your program. You will not always have the time to optimize for performance. You will not always have the time to refactor functionality to make it more modular for further variety. Sometimes you will need to skip test becuase deadline says it should be done yesterday. Learn to not be emotionally tied to the code. Get your job done, to the best quality you can for the time you have allotted. Dont be made if its not perfect. But during the train ride or in the shower think about how to make it better. This process of just grasping with the ideas of clean code are good training for when you have to approach a similar problem on the fly.