So, basically, you'd move most of the work from the read side to the write side (with an unacknowledged application of the Nagle algorithm in the first paragraph). Well and good, but are you sure that's a good idea? Are you sure the Facebook engineers didn't consider and reject it because (a) it's actually more work total and (b) their access patterns indicate that they should be trying to offload the write side? It's very easy to come up with an architecture that you think (in a near vacuum of actual data or relevant experience) will work better, and conclude that they must be fools for having made the wrong tradeoff. Isn't it at least possible that they actually understand the tradeoffs and applicable technologies quite well, and that we might be able to learn something from the choices they made? Even if we don't actually believe that, it can be a useful mental exercise. Ditto for the folks who designed Dynamo, or PNUTS, or anything else in this area. Many of the objections and alternatives I'm seeing here are explicitly addressed in the papers these folks have written, and it's definitely worthwhile to look those up no matter what verdict you eventually hand down to us mere mortals.
Here's a tip from a *real* pro: some concepts don't scale. Take strictly sequential execution (please!) as an example. That's clearly a concept, not an implementation, and yet it clearly conflicts with scalability - i.e. maintaining a ratio of output to some factor X as X increases. In this case X could be records or bytes per second, or number of clients, or network latency. In all of those cases, a point is quickly reached - still well within a normal range of interest - where sequential execution fails. Concept? Check. Doesn't scale? Check. Q.E.D. Back to school, n00b.
Don't know why that got posted as AC. I *was* logged in; maybe/. isn't handling these sorts of consistency issues as well as if they'd used an appropriate storage system.;) In any case, I do stand behind what I said.
Yeah, except for the part where you get to run your own OS. And the part where it often costs *less* than running your own servers. And the part where it's composed of multiple machines and can be scaled incrementally. And the part where you can integrate functionality between multiple clouds including those you run privately. And the part where you and everyone else access it through a network that hadn't even been imagined in the old mainframe days. Except for just about everything, you're right. Very insightful.
The fact is that government did move to prop up many mainframe makers, and even more so with the makers of supercomputers which long ago displaced mainframes as the largest and most expensive systems. It's still happening today. Go look at the Top 500 lists, and you'll see that practically all of the top systems are government-owned. Thinking Machines would never have gotten off the ground without extensive government support, Cray/SGI wouldn't have survived the 90s, and let's not forget DARPA's contributions. Government has contributed positively to innovation in computing, not caused it to stagnate.
If the government had shown any inclination to get involved in the auto industry the way they have been involved in computing, we'd all be driving all-electric or hydrogen-fueled cars today, supported by an appropriate recharging/refueling infrastructure and complemented by a robust cargo/mass-transit infrastructure. Grove's an idiot.
...there are two caveats. One is that "executable specification in Haskell" is a bit of a dodge. It means that they have effectively verified the translation from Haskell to C, but if there are bugs in the Haskell then there will be bugs in the C as well (in fact this is part of what they've proven). They admit as much at the very top of http://ertos.nicta.com.au/research/l4.verified/proof.pml, but it still leaves the question of why this is any better than simply rewriting the microkernel in Haskell. If the benefit of a concise and abstract specification is lost, what's left?
The second major caveat is that they had to leave out some features that they couldn't verify. Most significant is that they didn't verify multi-core - by which it seems they mean multi-processor, but "multi-core" is the much hipper word. Since even laptops are multi-processor now, this limits applicability until they take the next step. With all of these shortcuts, though, if you look at the list of what they did manage to verify - mostly pointer errors and overflows - it's not clear that it couldn't have been done with a more real-code-oriented tool such as the Stanford Checker or sparse.
Spawning threads to handle isolated tasks within a single address space isn't all that hard. Handling interrelated tasks across more processors than could possibly share one address space, doing it correctly so it doesn't have deadlocks or race conditions, distributing the work so there aren't performance-killing bottlenecks even in a non-trivial system topology handling an ever-varying work distribution, etc. . . . that's where things get just a bit more challenging, and what the newer crop of languages are supposed to handle. Personally I don't think they help all that much with more than a small class of problems (mostly those that are heavily oriented toward dealing with some kind of regular array), but it's silly to dismiss them without even understanding their problem domain.
On a slightly different note, BTW, parallel programming hasn't become more difficult. It has merely become more common. Whereas it used to be the domain of a few with proper training, now a whole bunch of barely-competent schleps are trying to do it as well. They see pthread_create and it blows their mind, and they think now they're masters of parallel programming, hardly aware that creating threads is to parallel programming what the "if" statement is to programming in general - the very first door you have to go through, before you can even realize how much more there is to know.
I know other people have suggested it, but I'll reiterate what they've said. (It's the Slashdot way, after all.) Set up a virtual machine for them. Let them play in the virtual machine to their hearts' content. Reimage it as often as you need, since it doesn't take long. The only person using your host OS on a laptop should be you because you're the host; everybody else is a guest and should use a guest OS.
We're reinventing the kernel-userland split, and for no good reason.
Thank you for saying that. The purpose of a multi-tasking multi-user OS is to allow running multiple applications with full isolation from one another. If we need some other piece of software - like a VM hypervisor - to do that, then the OS has failed in its duty. But wait, some people say, it's not just about multiplexing hardware, it's about migration and HA and deploying system images easily. These are also facilities the OS should be providing. Again, if we need some other piece of software then the OS has failed.
One could argue that we've evolved to a point where the functions of an OS have been separated into two layers. One layer takes care of multiplexing the hardware; the other takes care of providing an API and an environment for things like filesystems. Better still, you get to mix and match instances of each layer. OK, fine. Given the Linux community's traditional attitude toward layering (and microkernels, which this approach also resembles) it's a bit inconsistent, but fine. That interpretation does raise some interesting questions, though. People are putting a lot of thought into where drivers should live, and since some drivers are part of "multiplexing the hardware" then it would make sense for them to live in the hypervisor with a stub in the guest OS - just as is being done, I know. But what about the virtual-memory system? That's also a form of hardware multiplexing, arguably the most important. If virtualization is your primary means of isolating users and applications from one another, why not put practically all of the virtual-memory functionality into the hypervisor and run a faster, simpler single-address-space OS on top of that?
If we're going to delegate operating-system functionality to hypervisors, let's at least think about the implications and develop a coherent model of how the two interact instead of the disorganized and piecemeal approaches we see now.
Excluded by definition. If someone can show something important that's going on behind the scenes, i.e. actually going on and not supposed to be going on according to the spec, then they have shown greater operational knowledge. That's not the scenario I was addressing. "That's not how I wrote the spec" is not the crushing blow it was presented to be. "That's not how I implemented it" would be much more telling. Nobody runs the spec.
According to the story, the bug was in Josh's code. Where I come from, you don't get much credit for fixing a bug you created, especially if it took two days of eroding customer perception before you did it. Further, the description of the convoluted code and missing documentation suggest that such problems should have been expected. This is not a guy who wrote great code and then demonstrated brilliance fixing a customer problem. It's a guy who wrote crappy code and then fixed it later than he should have.
OK, so it's a bad example, but that doesn't necessarily invalidate the whole line of inquiry. There's still a real phenomenon of brilliant programmers who are also disruptive. The solution is to tell the person that they can't rely on history, that every single instance of flouting the rules will be evaluated on its own merits. If they're right every single time that their actions are justified by creating an overall good for the company, they'll be OK. If they're wrong just once and it's an action that would lead to anyone else being fired then they'll be fired too. If they're not capable of working through the implications of that simple policy and modifying their behavior accordingly, then they're really not that smart after all and you're better off without them. We are all responsible not only for our own individual deliverables but for the effect we have on others around us. Reward people for the good things that they do, and penalize them for the bad things. If they're rational, they'll adjust.
At this point the senior programmer grins and says... "Well, that's not how I wrote the specification". He then gave a 20 minute lecture on how it actually works.
Nope, sorry. Operational experience trumps specs every time, especially in networking. I'm naturally inclined to side with the oldster and join in the kid-bashing, but I've seen too many cases where following the spec instead of actual current practice was a colossal mistake. Without knowing more of the details, I'd go with the kid in most cases like this.
Well, I've seen an awful lot of situations where two guys are doing exactly the same job but one guy is getting paid a whole lot more because of "seniority".
You have a valid point, as do several of those who've already responded. I'd like to add one more justification for the difference: risk. Yeah, maybe two people end up doing exactly the same job, but when tenures are as short as they are in our field pay is mostly a function of initial salary. To explain differences in initial salary, you have to look not at eventual outcomes but at the moment of hiring. At that moment, one of the big factors is risk. People pay a premium to eliminate risk, and the person who can certainly do a job is worth a premium over someone who might be able to. That same principle also applies to other things each candidate/employee might do. Business needs change all the time. Of two people doing the same job this month, the lower-experience lower-pay employee might be able to do other relevant kinds of coding but the higher-experience one is in part higher paid because of two or three known and proven relevant skills. That's worth something in terms of insurance, even if it none of those skills are being brought to bear at one particular moment.
Yes, sometimes people are paid more or less than they turn out to deserve. Most of the time the necessary adjustments get made, so by the time everyone's been in the business for ten years it's likely that they will have found their true relative worth. Sometimes such injustices persist indefinitely, as happens in all walks of life, but they can't reasonably be eliminated and most attempts result in even graver injustices elsewhere. You think it's bad making less than someone else just because they have a few more years' experience? Try making less than someone else just because they were hired when salaries throughout the industry were higher than when you were hired a few years previously. Try being asked to hold their hand and teach them all the things that are specific to your company and your project, knowing that. (I actually haven't been in that position myself, but I've seen it and I'm sure it really sucks.) Paying people more for seniority isn't perfect, but it's part of an overall system that works pretty well. I'd love to hear about any alternative that worked better without that feature.
It looks like you're trying to create a slideshow about me. Would you like to...
...include the paparazzi pictures of me at the nude beach?
..find a lawyer for when Microsoft claims this violates their copyright?
...show everyone how super-duper-elite you are by complaining about me even though they you've never actually seen me for real because your middle school doesn't use Office?
think going to UDP would be cool for another reason: there's not all the setup and teardown for connection. If 200 people each request the same block from me in a minute, do I really want to have to go through something like 'hi can I talk to you, what port should I use, hey here it comes, do you have it, ok, I'm done talking to you go away', or should I just shovel it out?
The setup and teardown in TCP itself isn't all that expensive. What's expensive is usually the setup and teardown to deal with NAT, a problem that's at least as bad with UDP as with TCP. In particular, with a UDP-based protocol that it doesn't understand the NAT box won't know when the conversation ended, so it'll just keep state around until some long-ish timeout, so you're going to be stressing it even more than you would have been with TCP.
It's possible to improve on TCP. Many have done it, and the result is . . . TCP. Watch any modern Linux box boot and you'll see a bunch of congestion-control modules being loaded, none of which were dreamed of in the early days of Nagle and Van Jacobson, but they're all TCP. This being slashdot, a whole bunch of people are talking about how they can do better than TCP because "TCP hasn't changed in twenty years" - and then they wonder why people who've actually worked on this stuff roll their eyes. The way to improve something is to understand what has been already tried, and then try something new.
I don't know if the BitTorrent guys are really improving on TCP or just offering the millionth painful re-learning of its lessons (with us as their guinea pigs) but some of the comments e.g. about using latency to measure congestion suggest it's the latter. I hope I'm wrong.
I don't find myself wishing machines had souls. Now, a sense of humor, that would be something worth wishing for, so would a conscience, but not a soul.
(Also wondering whether Ray Kurzweil has any of the above. Let's work on that one first.)
Frankly, I find it a bit discouraging that making light of maladjusted individuals seems to rank fairly high on so many people's list of acceptable pastimes. It's quite cruel.
Of course, the irony is that those who laugh loudest are themselves quite maladjusted
So, you just took the time to compose a Slashdot post about how looking down at others is a sign of maladjustment, and you want to talk about irony? Please, do go on. I look forward to hearing why it's better to look down on others with a frown than with a smile.
Actually, Linpack is not embarrassingly parallel so it DOES test how well the interconnects work, to some extent.
Yeah, and your head is useful as a hammer to some extent. It's a very small extent in either case, far short of the observation making a dent in the claim it supposedly refutes. Linpack is embarrassingly parallel enough to make it absolutely useless for comparing systems' memory or interconnect speed, which makes it almost entirely useless for comparing those systems' ability to run real-world code outside of an increasingly irrelevant domain.
How can you possibly evaluate supercomputers in any other way except how many mathematical operations can be performed in some reference time?
Simple: you evaluate how much actual work it can perform across the entire system per unit time, where "actual work" means a mix of operations similar to some real application of interest. The whole problem here is that practically no real application is as purely focused on arithmetic operations as Linpack. Even the people who developed Linpack know this, which is why they developed the HPCC suite as its successor. It's composed of seven benchmarks, including some (e.g. stream triad) that mostly stress memory and some (e.g. matrix transpose) that mostly stress interconnects. If you want to get an idea how your application will perform on various machines, you determine what mix of those seven numbers best approximates your application, assign appropriate weights, and then apply those weights to the vendor numbers. Then you negotiate with the two or three most promising vendors to run your application for real. SPEC should have put an end to simplistic "single figure of merit" comparisons, or if not them then TPC, SPC, etc. Sadly, though, there's still always someone who comes along and tries to revive the corpse.
I think it's asinine for an employer to mandate the use of certain tools. What they should worry about is whether the data produced as work product is uniform or at least compatible, regardless of how it's generated. If code follows the coding rules, who cares what editor was used? If a spec is readable and editable by everyone who needs to read and edit it respectively, again, who cares? The problem is that achieving a certain level of file-format compatibility sometimes effectively forces use of a certain tool. Let's look at some examples.
At a previous job, use of emacs was mandated because somebody had developed a set of emacs bindings to insert standard file and function headers etc. Emacs is not my favorite editor but I'm quite comfortable with it, so I didn't find this requirement particularly burdensome, but I still think it was wrong. If somebody had developed an equivalent set of vi macros, or inserted the same headers by hand, the effect would have been the same and how they achieved that effect should not have been the company's business.
Fast forward to another job, where emacs was again mandated in one group, this time because that group used tools that were very finicky about tabs and indentation. This being Slashdot, I know everyone will say to fix the tools and someone else will say to use "indent" with a standard profile, but for the sake of argument let's say that those approaches were infeasible or insufficient. In that case, you'd have a situation where using different tools could yield work product that looked identical in an editor but was not in fact functionally identical, and the most practical way to ensure uniformity of output would be to mandate use of a certain tool. I can't reach a firm conclusion on this one.
What if it was important that IDE workspaces (defining files, build options, etc.) be shareable? This depends heavily on the workflow on that project, but if the workspace is part of the work product and only one tool supports it, then it might not be totally unreasonable to require use of that tool.
What about specs? Everyone can generate PDF, which is great for reading and printing, but what if you want many people to edit the document or attach comments during review? Our doc group uses tools that preclude either of these, and I think that sucks. Many others use Tex/Lyx, which I also find deficient in many ways. The standard workstation builds all include OpenOffice, so if it were up to me that would be the standard (we barely allow Windows on laptops, let alone workstations, so MS Office would not be an option).
What many of these examples have in common is that the functional requirements applied to employees' work product often do end up practically forcing use of a particular tool, but that doesn't mean one should lose sight of the real goal - document compatibility. Requiring everyone to use MS Office, for example, might actually sacrifice document compatibility when half the company switches to a new version of Office and the documents they create are mangled or unreadable for those still using the older version. Been there, done that, more than once. Ditto for people using Mac versions of either Windows or *N*X software, when those versions are subtly different. OmniGraffle sure makes pretty diagrams, but if most people in the company use Linux and they need to be able to modify those diagrams then you'd damn well better save them in a format they can use and if you don't then you're out of line. The goal should be that all code is in a format that everyone needs to edit code should be able to edit, and all specs or manuals is in a format that everyone who needs to edit specs or manuals can edit, all diagrams is in a format that everyone who needs to edit diagrams can edit, etc. What tool you use shouldn't matter except to the degree that your choice of tool affects whether others can pick up your data and run with it.
You also need to make mahomet come to the mountain. The current model is that the mountain (data) comes to mahomet (the processor, the active unit). If you have many cores, you put them "near" different address spaces, and the threads execute on a core "near" the data. If one area of memory gets overcrowded, the data migrates to a cooler area with more free cores. It may sound odd to bulk move the data, but if you are using small enough atoms, there will be fewer mcycles involved in a block copy that in accessing it many times over for processing.
The "bulk moves" you suggest sound a lot like the explicit communication (explicit from the hardware standpoint, not that of the higher-level language or API) that I did. Are we just in violent agreement, or is there some nuance that has gone unmentioned so far?
So you have to split the problem into an enormous number of pieces - much larger than the number of cores. Then you don't communicate explicitly, you just have a task queue. Each core does one micro-task, generating zero or more new microtasks which added to the task queue.
Again, that works only if the problem is inherently capable of being decomposed that far, and that's not usually the case. Also, if the tasks in a program all run on one processor then that program is irrelevant to this discussion, and if they don't then we're back to dealing with communication and contention. Task queues shared between processors have been well known loci of contention in parallel programs since the early SMP days. Many programs written in just the manner you suggest have achieved far less than linear scaling (and have sometimes become worse) because cache/memory contention and context switches stole back most of the gains from having multiple processors. Papers are written about the rare exceptions, but don't represent the day-to-day reality for the people who work on such programs or systems.
such a system could never be written in C or other pure imperative languages. You need Functional Programming, or some other new paradigm, in which the order of execution is divorced from program layout. Which is what the Intel bods are talking about.
That much is true, and the same as what I've said myself before this article came along. Adoption of such paradigms will extend the set of applications that can take advantage of kilocore systems, but it will still be a relatively small set.
Because each core is no longer task switching. Once you have more cores than tasks you can remove all the context switching logic and optimize the cores to run single processes as fast as possible.
OK, so now the piece that's running on each core runs really really fast . . . until it needs to wait for or communicate with the piece running on some other core. If you can do your piece in ten instructions but you have to wait 1000 for the next input to come in, whether it's because your neighbor is slow or because the pipe between you is, then you'll be sitting and spinning 99% of the time. Unfortunately, the set of programs that decompose nicely into arbitrarily many pieces that each take the same time (for any input) doesn't extend all that far beyond graphics and a few kinds of simulation. Many, many more programs hardly decompose at all, or still have severe imbalances and bottlenecks, so the "slow neighbor" problem is very real.
Many people's answer to the "slow pipe" problem, on the other hand, is to do away with the pipes altogether and have the cores communicate via shared memory. Well, guess what? The industry has already been there and done that. Multiple processing units sharing a single memory space used to be called SMP, and it was implemented with multiple physical processors on separate boards. Now it's all on one die, but the fundamental problem remains the same. Cache-line thrashing and memory-bandwidth contention are already rearing their ugly heads again even at N=4. They'll become totally unmanageable somewhere around N=64, just like the old days and for the same reasons. People who lived through the last round learned from the experience, which is why all of the biggest systems nowadays are massively parallel non-shared-memory cluster architectures.
If you want to harness the power of 1000 processors, you have to keep them from killing each other, and they'll kill each other without even meaning to if they're all tossed in one big pool. Giving each processor (or at least each small group of processors) its own memory with its own path to it, and fast but explicit communication with its neighbors, has so far worked a lot better except in a very few specialized and constrained cases. Then you need multi-processing on the nodes, to deal with the processing imbalances. Whether the nodes are connected via InfiniBand or an integrated interconnect or a common die, the architectural principles are likely to remain the same.
Disclosure: I work for a company that makes the sort of systems I've just described (at the "integrated interconnect" design point). I don't say what I do because I work there; I work there because of what I believe.
In science, this is a problem, because even though most scientist are at least proficient in programming (albeit not always adhering to clean coding practices), there are few that know MPI or have the time or will to learn it. In fact, I'm a bit worried. MPI is improving in a much slower rate than compute nodes are getting multicore.
True enough. My company provides an optimized MPI implementation, and it has been said that the whole box was designed to run MPI code well, but personally I've never been much of a fan. I think we need something higher-level, like Cilk or Sequoia or Chapel or E or perhaps even something as yet unthought of. (Links if you want 'em, but I'm feeling a mite lazy right now.)
There doesn't seem to be a lot of focus on it at the moment, most likely because intel can still market their multicore processors without problems.
On the contrary, I think there's a lot going on in this space right now. Maybe there hasn't been as much as there should have been, and actual results might trail need for the next while, but lots of very smart people are taking the problem very seriously. What I'm worried about is that there will be too big a gap between the tools to write massively parallel programs and the tools to analyze or debug or tune them. Then people might all flock to one alternative, and by the time anyone realizes it's actually the worst wrt these other kinds of tools it'll be too late. The last thing we need is a way for more people to write flaky, racy, generally unmaintainable parallel code. Whoever's working on the next generation of parallel languages had better be thinking about these kinds of issues as well as just automated array slicing and such.
Hi, and welcome to slashdot. Yeah, I can see that you have a low ID, which means there's even less excuse for not knowing how things go here. Someone smarmily tries to imply that what I - and, it seems quite likely, you - do as not a "real test of engineering" based on fundamental misunderstandings. I take exception, and express my pique, and at least - unlike most slashdotters - provide some actual information to back up what I'm saying. Where's the problem? At least I'm willing to stand behind what I say, instead of hiding behind pseudonymity.
Linpack is a terrible representation of performance on real HPC applications. Linpack almost exclusively rewards FP ALU throughput, scales almost perfectly on multicores, and requires very little of the interconnect, and has very modest memory bandwidth needs.
Yep. Tell me about it. If the Top 500 used a more realistic benchmark we'd be on it. If the Green 500 didn't require systems to be on the Top 500 first, we'd probably be at or near the top of that list (between BG/P and Roadrunner, at a guess). Even so, I'm not sure Google's systems would do all that well. For one thing, the systems that Google buys have relatively weak FP even within their category. For another, a quick look at the Top 500 details shows that things like memory and interconnect bandwidth do matter. The scaling even among systems using the same processor is not as linear as you make it out to be; Linpack sucks as a measure of deliverable system performance, but it doesn't suck that much. While Google would probably be able to make the list if they tried, "pretty good scores" is questionable and the original claim of them having the largest supercomputer is flat-out false. They don't even get to claim they have the most storage, let alone compute power.
Slashdot Mirror
So, basically, you'd move most of the work from the read side to the write side (with an unacknowledged application of the Nagle algorithm in the first paragraph). Well and good, but are you sure that's a good idea? Are you sure the Facebook engineers didn't consider and reject it because (a) it's actually more work total and (b) their access patterns indicate that they should be trying to offload the write side? It's very easy to come up with an architecture that you think (in a near vacuum of actual data or relevant experience) will work better, and conclude that they must be fools for having made the wrong tradeoff. Isn't it at least possible that they actually understand the tradeoffs and applicable technologies quite well, and that we might be able to learn something from the choices they made? Even if we don't actually believe that, it can be a useful mental exercise. Ditto for the folks who designed Dynamo, or PNUTS, or anything else in this area. Many of the objections and alternatives I'm seeing here are explicitly addressed in the papers these folks have written, and it's definitely worthwhile to look those up no matter what verdict you eventually hand down to us mere mortals.
Here's a tip from a *real* pro: some concepts don't scale. Take strictly sequential execution (please!) as an example. That's clearly a concept, not an implementation, and yet it clearly conflicts with scalability - i.e. maintaining a ratio of output to some factor X as X increases. In this case X could be records or bytes per second, or number of clients, or network latency. In all of those cases, a point is quickly reached - still well within a normal range of interest - where sequential execution fails. Concept? Check. Doesn't scale? Check. Q.E.D. Back to school, n00b.
Don't know why that got posted as AC. I *was* logged in; maybe /. isn't handling these sorts of consistency issues as well as if they'd used an appropriate storage system. ;) In any case, I do stand behind what I said.
Yeah, except for the part where you get to run your own OS. And the part where it often costs *less* than running your own servers. And the part where it's composed of multiple machines and can be scaled incrementally. And the part where you can integrate functionality between multiple clouds including those you run privately. And the part where you and everyone else access it through a network that hadn't even been imagined in the old mainframe days. Except for just about everything, you're right. Very insightful.
The fact is that government did move to prop up many mainframe makers, and even more so with the makers of supercomputers which long ago displaced mainframes as the largest and most expensive systems. It's still happening today. Go look at the Top 500 lists, and you'll see that practically all of the top systems are government-owned. Thinking Machines would never have gotten off the ground without extensive government support, Cray/SGI wouldn't have survived the 90s, and let's not forget DARPA's contributions. Government has contributed positively to innovation in computing, not caused it to stagnate. If the government had shown any inclination to get involved in the auto industry the way they have been involved in computing, we'd all be driving all-electric or hydrogen-fueled cars today, supported by an appropriate recharging/refueling infrastructure and complemented by a robust cargo/mass-transit infrastructure. Grove's an idiot.
...there are two caveats. One is that "executable specification in Haskell" is a bit of a dodge. It means that they have effectively verified the translation from Haskell to C, but if there are bugs in the Haskell then there will be bugs in the C as well (in fact this is part of what they've proven). They admit as much at the very top of http://ertos.nicta.com.au/research/l4.verified/proof.pml, but it still leaves the question of why this is any better than simply rewriting the microkernel in Haskell. If the benefit of a concise and abstract specification is lost, what's left?
The second major caveat is that they had to leave out some features that they couldn't verify. Most significant is that they didn't verify multi-core - by which it seems they mean multi-processor, but "multi-core" is the much hipper word. Since even laptops are multi-processor now, this limits applicability until they take the next step. With all of these shortcuts, though, if you look at the list of what they did manage to verify - mostly pointer errors and overflows - it's not clear that it couldn't have been done with a more real-code-oriented tool such as the Stanford Checker or sparse.
Spawning threads to handle isolated tasks within a single address space isn't all that hard. Handling interrelated tasks across more processors than could possibly share one address space, doing it correctly so it doesn't have deadlocks or race conditions, distributing the work so there aren't performance-killing bottlenecks even in a non-trivial system topology handling an ever-varying work distribution, etc. . . . that's where things get just a bit more challenging, and what the newer crop of languages are supposed to handle. Personally I don't think they help all that much with more than a small class of problems (mostly those that are heavily oriented toward dealing with some kind of regular array), but it's silly to dismiss them without even understanding their problem domain.
On a slightly different note, BTW, parallel programming hasn't become more difficult. It has merely become more common. Whereas it used to be the domain of a few with proper training, now a whole bunch of barely-competent schleps are trying to do it as well. They see pthread_create and it blows their mind, and they think now they're masters of parallel programming, hardly aware that creating threads is to parallel programming what the "if" statement is to programming in general - the very first door you have to go through, before you can even realize how much more there is to know.
I know other people have suggested it, but I'll reiterate what they've said. (It's the Slashdot way, after all.) Set up a virtual machine for them. Let them play in the virtual machine to their hearts' content. Reimage it as often as you need, since it doesn't take long. The only person using your host OS on a laptop should be you because you're the host; everybody else is a guest and should use a guest OS.
Thank you for saying that. The purpose of a multi-tasking multi-user OS is to allow running multiple applications with full isolation from one another. If we need some other piece of software - like a VM hypervisor - to do that, then the OS has failed in its duty. But wait, some people say, it's not just about multiplexing hardware, it's about migration and HA and deploying system images easily. These are also facilities the OS should be providing. Again, if we need some other piece of software then the OS has failed.
One could argue that we've evolved to a point where the functions of an OS have been separated into two layers. One layer takes care of multiplexing the hardware; the other takes care of providing an API and an environment for things like filesystems. Better still, you get to mix and match instances of each layer. OK, fine. Given the Linux community's traditional attitude toward layering (and microkernels, which this approach also resembles) it's a bit inconsistent, but fine. That interpretation does raise some interesting questions, though. People are putting a lot of thought into where drivers should live, and since some drivers are part of "multiplexing the hardware" then it would make sense for them to live in the hypervisor with a stub in the guest OS - just as is being done, I know. But what about the virtual-memory system? That's also a form of hardware multiplexing, arguably the most important. If virtualization is your primary means of isolating users and applications from one another, why not put practically all of the virtual-memory functionality into the hypervisor and run a faster, simpler single-address-space OS on top of that?
If we're going to delegate operating-system functionality to hypervisors, let's at least think about the implications and develop a coherent model of how the two interact instead of the disorganized and piecemeal approaches we see now.
Excluded by definition. If someone can show something important that's going on behind the scenes, i.e. actually going on and not supposed to be going on according to the spec, then they have shown greater operational knowledge. That's not the scenario I was addressing. "That's not how I wrote the spec" is not the crushing blow it was presented to be. "That's not how I implemented it" would be much more telling. Nobody runs the spec.
According to the story, the bug was in Josh's code. Where I come from, you don't get much credit for fixing a bug you created, especially if it took two days of eroding customer perception before you did it. Further, the description of the convoluted code and missing documentation suggest that such problems should have been expected. This is not a guy who wrote great code and then demonstrated brilliance fixing a customer problem. It's a guy who wrote crappy code and then fixed it later than he should have.
OK, so it's a bad example, but that doesn't necessarily invalidate the whole line of inquiry. There's still a real phenomenon of brilliant programmers who are also disruptive. The solution is to tell the person that they can't rely on history, that every single instance of flouting the rules will be evaluated on its own merits. If they're right every single time that their actions are justified by creating an overall good for the company, they'll be OK. If they're wrong just once and it's an action that would lead to anyone else being fired then they'll be fired too. If they're not capable of working through the implications of that simple policy and modifying their behavior accordingly, then they're really not that smart after all and you're better off without them. We are all responsible not only for our own individual deliverables but for the effect we have on others around us. Reward people for the good things that they do, and penalize them for the bad things. If they're rational, they'll adjust.
Nope, sorry. Operational experience trumps specs every time, especially in networking. I'm naturally inclined to side with the oldster and join in the kid-bashing, but I've seen too many cases where following the spec instead of actual current practice was a colossal mistake. Without knowing more of the details, I'd go with the kid in most cases like this.
You have a valid point, as do several of those who've already responded. I'd like to add one more justification for the difference: risk. Yeah, maybe two people end up doing exactly the same job, but when tenures are as short as they are in our field pay is mostly a function of initial salary. To explain differences in initial salary, you have to look not at eventual outcomes but at the moment of hiring. At that moment, one of the big factors is risk. People pay a premium to eliminate risk, and the person who can certainly do a job is worth a premium over someone who might be able to. That same principle also applies to other things each candidate/employee might do. Business needs change all the time. Of two people doing the same job this month, the lower-experience lower-pay employee might be able to do other relevant kinds of coding but the higher-experience one is in part higher paid because of two or three known and proven relevant skills. That's worth something in terms of insurance, even if it none of those skills are being brought to bear at one particular moment.
Yes, sometimes people are paid more or less than they turn out to deserve. Most of the time the necessary adjustments get made, so by the time everyone's been in the business for ten years it's likely that they will have found their true relative worth. Sometimes such injustices persist indefinitely, as happens in all walks of life, but they can't reasonably be eliminated and most attempts result in even graver injustices elsewhere. You think it's bad making less than someone else just because they have a few more years' experience? Try making less than someone else just because they were hired when salaries throughout the industry were higher than when you were hired a few years previously. Try being asked to hold their hand and teach them all the things that are specific to your company and your project, knowing that. (I actually haven't been in that position myself, but I've seen it and I'm sure it really sucks.) Paying people more for seniority isn't perfect, but it's part of an overall system that works pretty well. I'd love to hear about any alternative that worked better without that feature.
It looks like you're trying to create a slideshow about me. Would you like to...
The setup and teardown in TCP itself isn't all that expensive. What's expensive is usually the setup and teardown to deal with NAT, a problem that's at least as bad with UDP as with TCP. In particular, with a UDP-based protocol that it doesn't understand the NAT box won't know when the conversation ended, so it'll just keep state around until some long-ish timeout, so you're going to be stressing it even more than you would have been with TCP.
It's possible to improve on TCP. Many have done it, and the result is . . . TCP. Watch any modern Linux box boot and you'll see a bunch of congestion-control modules being loaded, none of which were dreamed of in the early days of Nagle and Van Jacobson, but they're all TCP. This being slashdot, a whole bunch of people are talking about how they can do better than TCP because "TCP hasn't changed in twenty years" - and then they wonder why people who've actually worked on this stuff roll their eyes. The way to improve something is to understand what has been already tried, and then try something new.
I don't know if the BitTorrent guys are really improving on TCP or just offering the millionth painful re-learning of its lessons (with us as their guinea pigs) but some of the comments e.g. about using latency to measure congestion suggest it's the latter. I hope I'm wrong.
I don't find myself wishing machines had souls. Now, a sense of humor, that would be something worth wishing for, so would a conscience, but not a soul.
(Also wondering whether Ray Kurzweil has any of the above. Let's work on that one first.)
Frankly, I find it a bit discouraging that making light of maladjusted individuals seems to rank fairly high on so many people's list of acceptable pastimes. It's quite cruel. Of course, the irony is that those who laugh loudest are themselves quite maladjusted
So, you just took the time to compose a Slashdot post about how looking down at others is a sign of maladjustment, and you want to talk about irony? Please, do go on. I look forward to hearing why it's better to look down on others with a frown than with a smile.
Actually, Linpack is not embarrassingly parallel so it DOES test how well the interconnects work, to some extent.
Yeah, and your head is useful as a hammer to some extent. It's a very small extent in either case, far short of the observation making a dent in the claim it supposedly refutes. Linpack is embarrassingly parallel enough to make it absolutely useless for comparing systems' memory or interconnect speed, which makes it almost entirely useless for comparing those systems' ability to run real-world code outside of an increasingly irrelevant domain.
Simple: you evaluate how much actual work it can perform across the entire system per unit time, where "actual work" means a mix of operations similar to some real application of interest. The whole problem here is that practically no real application is as purely focused on arithmetic operations as Linpack. Even the people who developed Linpack know this, which is why they developed the HPCC suite as its successor. It's composed of seven benchmarks, including some (e.g. stream triad) that mostly stress memory and some (e.g. matrix transpose) that mostly stress interconnects. If you want to get an idea how your application will perform on various machines, you determine what mix of those seven numbers best approximates your application, assign appropriate weights, and then apply those weights to the vendor numbers. Then you negotiate with the two or three most promising vendors to run your application for real. SPEC should have put an end to simplistic "single figure of merit" comparisons, or if not them then TPC, SPC, etc. Sadly, though, there's still always someone who comes along and tries to revive the corpse.
I think it's asinine for an employer to mandate the use of certain tools. What they should worry about is whether the data produced as work product is uniform or at least compatible, regardless of how it's generated. If code follows the coding rules, who cares what editor was used? If a spec is readable and editable by everyone who needs to read and edit it respectively, again, who cares? The problem is that achieving a certain level of file-format compatibility sometimes effectively forces use of a certain tool. Let's look at some examples.
What many of these examples have in common is that the functional requirements applied to employees' work product often do end up practically forcing use of a particular tool, but that doesn't mean one should lose sight of the real goal - document compatibility. Requiring everyone to use MS Office, for example, might actually sacrifice document compatibility when half the company switches to a new version of Office and the documents they create are mangled or unreadable for those still using the older version. Been there, done that, more than once. Ditto for people using Mac versions of either Windows or *N*X software, when those versions are subtly different. OmniGraffle sure makes pretty diagrams, but if most people in the company use Linux and they need to be able to modify those diagrams then you'd damn well better save them in a format they can use and if you don't then you're out of line. The goal should be that all code is in a format that everyone needs to edit code should be able to edit, and all specs or manuals is in a format that everyone who needs to edit specs or manuals can edit, all diagrams is in a format that everyone who needs to edit diagrams can edit, etc. What tool you use shouldn't matter except to the degree that your choice of tool affects whether others can pick up your data and run with it.
You also need to make mahomet come to the mountain. The current model is that the mountain (data) comes to mahomet (the processor, the active unit). If you have many cores, you put them "near" different address spaces, and the threads execute on a core "near" the data. If one area of memory gets overcrowded, the data migrates to a cooler area with more free cores. It may sound odd to bulk move the data, but if you are using small enough atoms, there will be fewer mcycles involved in a block copy that in accessing it many times over for processing.
The "bulk moves" you suggest sound a lot like the explicit communication (explicit from the hardware standpoint, not that of the higher-level language or API) that I did. Are we just in violent agreement, or is there some nuance that has gone unmentioned so far?
So you have to split the problem into an enormous number of pieces - much larger than the number of cores. Then you don't communicate explicitly, you just have a task queue. Each core does one micro-task, generating zero or more new microtasks which added to the task queue.
Again, that works only if the problem is inherently capable of being decomposed that far, and that's not usually the case. Also, if the tasks in a program all run on one processor then that program is irrelevant to this discussion, and if they don't then we're back to dealing with communication and contention. Task queues shared between processors have been well known loci of contention in parallel programs since the early SMP days. Many programs written in just the manner you suggest have achieved far less than linear scaling (and have sometimes become worse) because cache/memory contention and context switches stole back most of the gains from having multiple processors. Papers are written about the rare exceptions, but don't represent the day-to-day reality for the people who work on such programs or systems.
such a system could never be written in C or other pure imperative languages. You need Functional Programming, or some other new paradigm, in which the order of execution is divorced from program layout. Which is what the Intel bods are talking about.
That much is true, and the same as what I've said myself before this article came along. Adoption of such paradigms will extend the set of applications that can take advantage of kilocore systems, but it will still be a relatively small set.
Because each core is no longer task switching. Once you have more cores than tasks you can remove all the context switching logic and optimize the cores to run single processes as fast as possible.
OK, so now the piece that's running on each core runs really really fast . . . until it needs to wait for or communicate with the piece running on some other core. If you can do your piece in ten instructions but you have to wait 1000 for the next input to come in, whether it's because your neighbor is slow or because the pipe between you is, then you'll be sitting and spinning 99% of the time. Unfortunately, the set of programs that decompose nicely into arbitrarily many pieces that each take the same time (for any input) doesn't extend all that far beyond graphics and a few kinds of simulation. Many, many more programs hardly decompose at all, or still have severe imbalances and bottlenecks, so the "slow neighbor" problem is very real.
Many people's answer to the "slow pipe" problem, on the other hand, is to do away with the pipes altogether and have the cores communicate via shared memory. Well, guess what? The industry has already been there and done that. Multiple processing units sharing a single memory space used to be called SMP, and it was implemented with multiple physical processors on separate boards. Now it's all on one die, but the fundamental problem remains the same. Cache-line thrashing and memory-bandwidth contention are already rearing their ugly heads again even at N=4. They'll become totally unmanageable somewhere around N=64, just like the old days and for the same reasons. People who lived through the last round learned from the experience, which is why all of the biggest systems nowadays are massively parallel non-shared-memory cluster architectures.
If you want to harness the power of 1000 processors, you have to keep them from killing each other, and they'll kill each other without even meaning to if they're all tossed in one big pool. Giving each processor (or at least each small group of processors) its own memory with its own path to it, and fast but explicit communication with its neighbors, has so far worked a lot better except in a very few specialized and constrained cases. Then you need multi-processing on the nodes, to deal with the processing imbalances. Whether the nodes are connected via InfiniBand or an integrated interconnect or a common die, the architectural principles are likely to remain the same.
Disclosure: I work for a company that makes the sort of systems I've just described (at the "integrated interconnect" design point). I don't say what I do because I work there; I work there because of what I believe.