I think it's weird that some people have a fascination with humanoid robots in the first place. seems like most Japanese robot efforts (at least those that make the press here) are in that vein. sure, there's a golden place in the future for replicants and sex slaves, but to me those seem like fairly narrow niches. if I'm designing robots with the goal of getting useful stuff done, I certainly wouldn't start with a humanoid layout, with all respect to evolution;)
I admit it, all the Japanese robot coverage I see is either kawai-oriented or thinly-veiled sex-slave oriented (or both). no doubt that only reflects my taste in paper an online media...
the real news here is not the extra couple cores, but coherency snooping. this feature will make 4/8s machines far more attractive; it doesn't hurt that with 48 cores and 32 ddr3/1333 dimms, you have quite a monster. _and_ incidentally something that Intel can't currently answer.
there's no question that nehalem has put a serious dent in the market, but Intel's going quite slow in rolling out higher-end products. yes, a nehalem socket delivers about 50% more bandwidth than a current opteron socket, but show me the 8s nehalem machines. nehalem-ex is coming, but how soon and at what price?
one thing I haven't seen is any attempt to measure real SMP performance on new-gen chips. I don't mean something like Stream or VMs, where there is no real sharing inherent to the workload. how long does it take to exchange a _contended_ lock between cores (in the same socket vs remote)?
finally, the real question is whether there is actual demand for more-core chips. I'm in HPC, and we always want more, and throw good money. but it has to be smart more - the 6-core core2, for instance, was just asinine because even 2c core2 is drastically memory-bandwidth-starved. nehalem-ex seems quite promising, but if it's cheaper to cluster dual-socket machines rather than pay the premium for 4s's, the 4s market will be stunted and less successful in a self-fulfilling way...
nah. bank people can be as short-sighted as any other human, prone to compromises without sufficient worst-case thinking. notice the economy recently?
the problem isn't just quantitative (so to speak), but rather qualitative: people who work on bank protocols need to study math and CS, not actuarial/stats/accounting. good protocols hold water and can be upgraded without disruption as components become unacceptably weak.
I work for a large academic HPC organization which operates ~10k cores. our typical config has 2G/core, so we have a lot of dimms, all ECC. the majority of our systems have no corrected errors (CE); a few have modest rates (few hundred/day). we replace dimms which cause either uncorrected errors or > 1k CE/day. these are typically 8 GB machines with 1G ecc dimms - the bios hides details like whether the ECC is chipkill or not, or whether it's scrubbing. but the fact that large samples of COTS dimms generate no ECCs implies that a smaller-memory desktop stands a good chance of operating without random corruption. dimms are from Micron; systems are 1U servers in pretty decent machinerooms, at close to sealevel.
PIO means that each byte/word of data requires an in or out instruction. this was common in older peripherals, including parallel ports, ancient ATA, even some NICs.
DMA simply means that the device controller writes into a main-memory buffer (or reads from).
try this: start every interaction by assuming you know nothing and that they're right. they probably _are_ in most cases, but finding out is the problem. taking this stance will give you a better chance of engaging them. you have a little knowledge in their domain, so strive to keep it from being dangerous. sure, you have other knowledge (and constraints and commitments) but everyone is better off with a cooperation rather than hierarchy. hierarchy inevitably breeds resistance, ignorance, conflict, etc.
I thought gridders finally got tired of banging their heads against the facts of latency and bandwidth. well, at least people usually talk about cloud in the same breath as SOA - that is, incredibly loosely coupled, not anything at all like clustering.
ironically, as individual computers get faster, it becomes less and less attractive to do grids, since during the 10ms it takes to talk to even a nearby city, an entry-level server could have computed over a gigaflop. eventually, it doesn't make sense to even _try_ cooperating across that kind of imbalance.
saying 15krpm = 300 iops is indeed traditional, but reflects the conventional filesystem layout. if you have an empty track, you can log at whatever your disk bandwidth is - that is, precisely _not_ wait for a particular spot to come around again.
zero deficit? no - the US needs to run a large surplus for more than a few years to pay back those past deficits. merely stopping the deficit is not nearly good enough.
first, calculate your dissipation - get a power meter and measure the draw of your hardware at the wall. 1 kW = 3412 BTU; 1 ton = 12000 BTU; 1 ton = 3.517 kW. if your AC isn't big enough for your dissipation, no amount of sheet metal will help.
if you have enough cooling capacity, then your problem is that you're not segregating your hot and cold air properly. all commodity servers are designed for hot/cold aisles - that is, the front of the rack needs to be pure cold air supply from the chillers. hot air needs to be kept from reaching the front-of-rack. blanking panels avoid wasting cold air by flowing through the rack.
no - top exhausts appeal to people, but the fact is that servers are based on front-to-back airflow. that means that the whole front of the rack needs to be either exposed servers or blanking panels, and you must exhaust from the back of the rack. if you want to add a big duct to the back (probably have to be about 2 feet deep), you could direct the hot air up. but there's a reason real machinerooms have segregated hot and cold aisles. bouyancy is great, but doesn't move air like a rack full of fans...
of course, if your heat density is low (say, 10KW/rack), none of this matters much.
around 1982 I actually obtained a science-fair-like kit from some big-name old corporation - let's say Bell or GE. it contained silicon wafers, paint-on dopant material and a tiny ceramic widget that screwed into a light socket (diffusion furnace). it was already hard to scrape up info on how to get the kit, and they probably stopped distributing them for liability reasons. iirc, I had to supply my own hydrofluoric acid that was part of the metalization step. I can't remember whether the cells I made actually worked;)
all your base are belong to us, and your acids too.
the real question is whether the US's current direction will change after the election. I have a feeling that even if Obama wins, it won't be easy to turn around the train...
is this some new category of competition, like "fastest-ever cluster with blue cabling"?
the software on a cluster should, ideally, get out of the way of the jobs as completely and quickly as possible. it's hard to imagine windows doing that, let alone offering some advantage over the incumbent OS (Linux). in spite of smelling a bit like jato-equipped pigs, "because we can" doesn't really seem like a good rationale here.
the whole IP thing needs to get back to basics: my recording of a movie does not, by itself, hurt the creator of it. if I go and sell the copy, sure. but the argument that my recording deprives the creator of potential revenue is absurd. me being cheap also deprives them of revenue, or my taste in movies.
copyrights are not about maximizing the media companies' revenue - just about preventing _commercial_ rip-offs.
Intel and other chip vendors are pushing the manycore vision as The True Path Forward. this is disingenuous, since it's merely the easy path forward for said chip vendors. everyone agrees "morecore" will be common in the future, but 1k cores? definitely not clear. is it even meaningful to call it shared-memory programming if you have 1k cores? it's not as if 1k cores can ever sanely share particular data, at least not if it's ever written. and what's the value of 1k cores all sharing the same RO data?
this is not to say that there's no good work to be done, especially in programming tools. but you can do this all today, with current hardware, even uniprocessor hardware. after all, it's _always_ most interesting to debug parallel programs on hardware platforms that do parallelism poorly, since that exaggerates your hotspots.
IMO, we'll be putting cpus into dram chips before we have widespread manycore chips.
216-cores is no longer anything more than a small cluster. if you wanted, you could do it with just 10 very mundane 2-socket, quad-core chips - less than a 2-foot stack of nodes! this one sounds like a 54-node 2x2 cluster, which would be about a rack and a half, and set you back about $100k (more depending on how fancy you get with interconnect, storage, etc.)
to put it another way: it's a long way from even the bottom of the top500 list.
being GPL means, most of all, that there is no protection against forks. after all, GPL _is_ the ability to fork (ignore RMS's politics and all the other noise.)
how do you avoid forks? by being on the right side - everyone pulls in slightly different directions, and any project would be a mess if it accepted all of them. it's also not just a matter of choosing - ideally, if a fork is threatened, the mainstream would trump the fork. that is, instead of some little feature X, develop a bigger, more general thing that is a superset of X. turn the fork into a trivial an unappealing, limited special case. I'm not advocating hyper-featurism, but to embrace big-picture generalizations.
162 cpu-years just isn't a big deal - any resonably sound researcher could get that many cycles for free at quite a number of HPC centers.
the real problem with this particular molehill is that readers come to assume that the trivial fringe of HPC (embarassingly parallel stuff like folding) is what it's all about. EP codes are the boring special case - the reason HPC centers exist is mainly to support studies which cannot be run on a bunch of boxes networked with string.
worse yet is the impression that grid actually solves some problem, and especially that it makes computation fungible (like the electrical grid - plug in anywhere, it's all the same KWh.)
it's not HPC if you care about a measley 8 cores;)
seriously, the magic of HPC is in how you do the interconnect fabric, since that's the only way you can scale. 8 cores is nice, SMT is nice, but what if your program needs 4TB of ram to run at all and 1K cores in order to finish this year, and each thread communicates every 100 us with unpredictable, nonlocal other threads?
it's simply false that more-slower-threads are a panacea, and it's not the case that end-users primarily care about flops/watt. but there's a substantial market which is not performance limited (web hosting, desktops) for which both multithreading and slow-but-cool are wins.
If an isp wants to do this, I think they should simply loose any common-carrier status. that is, deep inspection means that they become responsible for content: accomplices in any crime committed via that traffic.
your examples are telling. mysql provides a nice builtin mechanism for handling several: it will auto-update timestamp fields (updated_on), and the builtin enum type is far nicer than attribute constraints...
I don't follow your argument on security - using the values() syntax is an easy way to avoid concatenation. the premise of trusting the DB to handle all security seems terribly mistaken to me.
the US IP system you see today is certainly not 200 years of success - in fact, the founding fathers wouldn't recognize it. they also wouldn't, IMO, consider it at all successful. it's not even clear whether we could have gotten to where we are today (western sci/tech success) if today's system _had_ been in place since the 1700's. dramatically many fundamentals of today's world would never have happened, or at least not happened in any recognizably similar way. (Unix, internet, X, browsers, ICs, transistors, computers, software, compilers, etc.)
Slashdot Mirror
I think it's weird that some people have a fascination with humanoid robots in the first place. seems like most Japanese robot efforts (at least those that make the press here) are in that vein. sure, there's a golden place in the future for replicants and sex slaves, but to me those seem like fairly narrow niches. if I'm designing robots with the goal of getting useful stuff done, I certainly wouldn't start with a humanoid layout, with all respect to evolution ;)
I admit it, all the Japanese robot coverage I see is either kawai-oriented or thinly-veiled sex-slave oriented (or both). no doubt that only reflects my taste in paper an online media...
there's no Uncanny Valley for Roombas.
the real news here is not the extra couple cores, but coherency snooping. this feature will make 4/8s machines far more attractive; it doesn't hurt that with 48 cores and 32 ddr3/1333 dimms, you have quite a monster. _and_ incidentally something that Intel can't currently answer.
there's no question that nehalem has put a serious dent in the market, but Intel's going quite slow in rolling out higher-end products. yes, a nehalem socket delivers about 50% more bandwidth than a current opteron socket, but show me the 8s nehalem machines. nehalem-ex is coming, but how soon and at what price?
one thing I haven't seen is any attempt to measure real SMP performance on new-gen chips. I don't mean something like Stream or VMs, where there is no real sharing inherent to the workload. how long does it take to exchange a _contended_ lock between cores (in the same socket vs remote)?
finally, the real question is whether there is actual demand for more-core chips. I'm in HPC, and we always want more, and throw good money. but it has to be smart more - the 6-core core2, for instance, was just asinine because even 2c core2 is drastically memory-bandwidth-starved. nehalem-ex seems quite promising, but if it's cheaper to cluster dual-socket machines rather than pay the premium for 4s's, the 4s market will be stunted and less successful in a self-fulfilling way...
nah. bank people can be as short-sighted as any other human, prone to compromises without sufficient worst-case thinking. notice the economy recently?
the problem isn't just quantitative (so to speak), but rather qualitative: people who work on bank protocols need to study math and CS, not actuarial/stats/accounting. good protocols hold water and can be upgraded without disruption as components become unacceptably weak.
I work for a large academic HPC organization which operates ~10k cores. our typical config has 2G/core, so we have a lot of dimms, all ECC. the majority of our systems have no corrected errors (CE); a few have modest rates (few hundred/day). we replace dimms which cause either uncorrected errors or > 1k CE/day. these are typically 8 GB machines with 1G ecc dimms - the bios hides details like whether the ECC is chipkill or not, or whether it's scrubbing. but the fact that large samples of COTS dimms generate no ECCs implies that a smaller-memory desktop stands a good chance of operating without random corruption. dimms are from Micron; systems are 1U servers in pretty decent machinerooms, at close to sealevel.
PIO means that each byte/word of data requires an in or out instruction. this was common in older peripherals, including parallel ports, ancient ATA, even some NICs.
DMA simply means that the device controller writes into a main-memory buffer (or reads from).
USB is not PIO.
try this: start every interaction by assuming you know nothing and that they're right. they probably _are_ in most cases, but finding out is the problem. taking this stance will give you a better chance of engaging them. you have a little knowledge in their domain, so strive to keep it from being dangerous. sure, you have other knowledge (and constraints and commitments) but everyone is better off with a cooperation rather than hierarchy. hierarchy inevitably breeds resistance, ignorance, conflict, etc.
I thought gridders finally got tired of banging their heads against the facts of latency and bandwidth. well, at least people usually talk about cloud in the same breath as SOA - that is, incredibly loosely coupled, not anything at all like clustering.
ironically, as individual computers get faster, it becomes less and less attractive to do grids, since during the 10ms it takes to talk to even a nearby city, an entry-level server could have computed over a gigaflop. eventually, it doesn't make sense to even _try_ cooperating across that kind of imbalance.
saying 15krpm = 300 iops is indeed traditional, but reflects the conventional filesystem layout. if you have an empty track, you can log at whatever your disk bandwidth is - that is, precisely _not_ wait for a particular spot to come around again.
zero deficit? no - the US needs to run a large surplus for more than a few years to pay back those past deficits. merely stopping the deficit is not nearly good enough.
first, calculate your dissipation - get a power meter and measure the draw of your hardware at the wall. 1 kW = 3412 BTU; 1 ton = 12000 BTU; 1 ton = 3.517 kW. if your AC isn't big enough for your dissipation, no amount of sheet metal will help.
if you have enough cooling capacity, then your problem is that you're not segregating your hot and cold air properly. all commodity servers are designed for hot/cold aisles - that is, the front of the rack needs to be pure cold air supply from the chillers. hot air needs to be kept from reaching the front-of-rack. blanking panels avoid wasting cold air by flowing through the rack.
no - top exhausts appeal to people, but the fact is that servers are based on front-to-back airflow. that means that the whole front of the rack needs to be either exposed servers or blanking panels, and you must exhaust from the back of the rack. if you want to add a big duct to the back (probably have to be about 2 feet deep), you could direct the hot air up. but there's a reason real machinerooms have segregated hot and cold aisles. bouyancy is great, but doesn't move air like a rack full of fans...
of course, if your heat density is low (say, 10KW/rack), none of this matters much.
around 1982 I actually obtained a science-fair-like kit from some big-name old corporation - let's say Bell or GE. it contained silicon wafers, paint-on dopant material and a tiny ceramic widget that screwed into a light socket (diffusion furnace). it was already hard to scrape up info on how to get the kit, and they probably stopped distributing them for liability reasons. iirc, I had to supply my own hydrofluoric acid that was part of the metalization step. I can't remember whether the cells I made actually worked ;)
all your base are belong to us, and your acids too.
the real question is whether the US's current direction will change after the election. I have a feeling that even if Obama wins, it won't be easy to turn around the train...
is this some new category of competition, like "fastest-ever cluster with blue cabling"?
the software on a cluster should, ideally, get out of the way of the jobs as completely and quickly as possible. it's hard to imagine windows doing that, let alone offering some advantage over the incumbent OS (Linux). in spite of smelling a bit like jato-equipped pigs, "because we can" doesn't really seem like a good rationale here.
the whole IP thing needs to get back to basics: my recording of a movie does not, by itself, hurt the creator of it. if I go and sell the copy, sure. but the argument that my recording deprives the creator of potential revenue is absurd. me being cheap also deprives them of revenue, or my taste in movies.
copyrights are not about maximizing the media companies' revenue - just about preventing _commercial_ rip-offs.
Intel and other chip vendors are pushing the manycore vision as The True Path Forward. this is disingenuous, since it's merely the easy path forward for said chip vendors. everyone agrees "morecore" will be common in the future, but 1k cores? definitely not clear. is it even meaningful to call it shared-memory programming if you have 1k cores? it's not as if 1k cores can ever sanely share particular data, at least not if it's ever written. and what's the value of 1k cores all sharing the same RO data?
this is not to say that there's no good work to be done, especially in programming tools. but you can do this all today, with current hardware, even uniprocessor hardware. after all, it's _always_ most interesting to debug parallel programs on hardware platforms that do parallelism poorly, since that exaggerates your hotspots.
IMO, we'll be putting cpus into dram chips before we have widespread manycore chips.
216-cores is no longer anything more than a small cluster. if you wanted, you could do it with just 10 very mundane 2-socket, quad-core chips - less than a 2-foot stack of nodes! this one sounds like a 54-node 2x2 cluster, which would be about a rack and a half, and set you back about $100k (more depending on how fancy you get with interconnect, storage, etc.)
to put it another way: it's a long way from even the bottom of the top500 list.
being GPL means, most of all, that there is no protection against forks. after all, GPL _is_ the ability to fork (ignore RMS's politics and all the other noise.)
how do you avoid forks? by being on the right side - everyone pulls in slightly different directions, and any project would be a mess if it accepted all of them. it's also not just a matter of choosing - ideally, if a fork is threatened, the mainstream would trump the fork. that is, instead of some little feature X, develop a bigger, more general thing that is a superset of X. turn the fork into a trivial an unappealing, limited special case. I'm not advocating hyper-featurism, but to embrace big-picture generalizations.
you can run MD on unpartitioned full disks, not just partitions.
162 cpu-years just isn't a big deal - any resonably sound researcher could get that many cycles for free at quite a number of HPC centers.
the real problem with this particular molehill is that readers come to assume that the trivial fringe of HPC (embarassingly parallel stuff like folding) is what it's all about. EP codes are the boring special case - the reason HPC centers exist is mainly to support studies which cannot be run on a bunch of boxes networked with string.
worse yet is the impression that grid actually solves some problem, and especially that it makes computation fungible (like the electrical grid - plug in anywhere, it's all the same KWh.)
it's not HPC if you care about a measley 8 cores ;)
seriously, the magic of HPC is in how you do the interconnect fabric, since that's the only way you can scale. 8 cores is nice, SMT is nice, but what if your program needs 4TB of ram to run at all and 1K cores in order to finish this year, and each thread communicates every 100 us with unpredictable, nonlocal other threads?
it's simply false that more-slower-threads are a panacea, and it's not the case that end-users primarily care about flops/watt. but there's a substantial market which is not performance limited (web hosting, desktops) for which both multithreading and slow-but-cool are wins.
If an isp wants to do this, I think they should simply loose any common-carrier status. that is, deep inspection means that they become responsible for content: accomplices in any crime committed via that traffic.
your examples are telling. mysql provides a nice builtin mechanism for handling several: it will auto-update timestamp fields (updated_on), and the builtin enum type is far nicer than attribute constraints...
I don't follow your argument on security - using the values() syntax is an easy way to avoid concatenation. the premise of trusting the DB to handle all security seems terribly mistaken to me.
the US IP system you see today is certainly not 200 years of success - in fact, the founding fathers wouldn't recognize it. they also wouldn't, IMO, consider it at all successful. it's not even clear whether we could have gotten to where we are today (western sci/tech success) if today's system _had_ been in place since
the 1700's. dramatically many fundamentals of today's world would never have happened, or at least not happened in any recognizably similar way. (Unix, internet, X, browsers, ICs, transistors, computers, software, compilers, etc.)