Remember when they found those skinless bodies in the tree in that movie and one of the guys said it was probably guerrillas who did it? Well, as a kid, I thought he was talking about gorillas.
Martin Short made the same mistake when Kurt Russel told him to watch out for the guerrillas.
In vocal alarm systems, there are practically no costs to producing false alarms.
And a possibility for great reward, as the Blue Jays know well. Bastards love to alarm call right as they're swooping in to the bird feeder.
Anyway, sorry you didn't find it interesting, each to their own.
Yeah, I wouldn't put much stock in the fact that a guy who knows literally nothing about the subject other than what they read in the summary, and is trying to use that vast body of knowledge to prove that they are smarter than researchers in the field, isn't "interested" by his own ill-informed conclusions about what is happening.
That's pretty interesting. So our cells have the ability to repair radiation damage but don't normally bother to try? Any molecular biologists around who would care to explain this in more detail than the aforementioned link? I always thought that ionizing radiation damaged the body on a molecular level beyond any healing ability that it may have.
This was on a site you may be familiar with a while ago. The upshot is, "lethal" doses of radiation may not really cause unrepairable amounts of damage just from the radiation. However when a large number of damaged cells decide to simultaneously die, then that can definitely kill you. Preventing them from committing suicide means any cells that aren't damaged beyond repair have a chance to do so. I'm sure there'd still be a "lethal" dose even if you took this drug, but it'd be much higher.
The suicide mechanism makes a lot of sense if you think about it arising in an environment where single cell mutations/DNA damage that could result in cancer is quite common, but acute radiation poisoning is extremely rare. Replacing a single suicidal cell is easy, a whole organ's worth at once is impossible. We just never evolved a mechanism that tried to suppress the suicide response if too many cells wanted to die at once.
If you're not penalized for running down pedestrians, then you're less stressed when you take your eyes off the road.
Sorry, that makes no sense, because it's not like the non-violent version had pedestrians you had to avoid. It had targets you had to hit for points, while the violent version simply replaced the targets with pedestrians. Running over "targets" vs pedestrians, that was the difference.
Indeed, they often did back in the old days, however, I am fairly confident that at the very least, they expected a breatheable atmosphere at their destination.
Not true! It's a little known fact that one of the reasons the Pilgrims were dependent on the natives for food that first Thanksgiving was because they'd wasted so much space in their ship's hold on canisters of compressed O2. You don't hear about this much, because the Pilgrims were so embarrassed when they first met the American Indians and wanted to know how they could survive without oxygen masks!
But maybe the basic game sucks and is boring, and running down pedestrians and seeing the blood splatter is the only thing that spices it up and gets the player to actually pay attention.
I don't think the lower case "channel" was a typo. I think it's pretty clear he meant "the wii channel what has the weather" without caring what the official name is.
"Local on the 8s" is also 7 minutes too slow if you want the weather now (and you can't check weather around the world with a neat spinning globe interface =D). It is more accurate though.
*Ridge A Villas is not responsible for hypothermia, loss of limbs due to gangrene, or Abominable Snowman attacks. Any lawsuit filed against Ridge A Villas must be filed in Antarctica county district court jurisdiction within 90 hours of the incident.
Pfft, you can disclaim whatever you want. In court, it'll be easy to show that Ridge A Villas are responsible for the Abominable Snowman attacks, due to cutting him out of the mascot deal and resulting merchandising royalties.
The calmest place on earth, duh. Unfortunately it won't help you observe the stars and galaxies unless you mix in some psilocybin or LSD or what have you.
If this is like the computer revolution of the '80s, I wonder who will be claiming that we need a rocket on every desk...
A stark contrast to when it was like the computer revolution of the '60s.
<glayven> I predict that in a hundred years, rockets will be twice as powerful, ten thousand times larger, and so expensive only the five riches CEOs in the West will be able to afford them! <glayven>
Doesn't scheduling (process vs. thread) depend on the OS? IIRC Linux schedules threads the same as processes. IE. quantum slice size/interactivity credits and dynamic priorities are calculated per thread and penalties are assigned to their parent process. Windows, OTOH, does all of the accounting at the process level. We'll pretend for the moment that Windows fork is POSIX compliant.
Okay, it's true that the definitions of 'thread' and 'process' and what have you vary as much as implementations, but that's all that is, implementation details, the majority of it in the OS. How the OS decides to schedule various things isn't really the issue.
In the most general definition of "thread" as a "thread of execution", it merely means a "context" (relevant register values including page table pointer and instruction pointer) executed on the machine. This definition is a super-set of all other definitions. After all, contexts is all the hardware actually understands. All the additional qualifiers are added by the OS: e.g. in linux a "process" has its own page table, while "threads" within a process do not, but the hardware doesn't care, it just sees a context switch and whether or not the CR3 values are the same or different is just a coincidence (that the hardware may or may not exploit).
So, at the end of the day, the thing you as OS-scheduler-writer or you as parallel programmer are interested in is how many simultaneous threads of execution the hardware supports. The names of the data structures used to manipulate those threads may vary in your OS/library of choice, but that doesn't change what the basic unit of interest in the hardware is, and it certainly isn't the "processor".
It will be interesting to see what happens as socket packages become essentially multiple NUMA style processors (with their own L[123] caches/dedicated RAM and memory controllers) that share only a high speed internal and external bus.
Well I think that's either already happened or on the cusp of happening. With large L3s, you can have different latencies to different parts of the L3 from different cores on the chip. Intel's MCMs communicate on-package using the external data bus. I don't see much future for dedicated per-core DRAM controllers. That doesn't make much sense. For one, it's highly useful to have a shared cache at some level (L3 currently), and the DRAM naturally goes on the other side of the L3. DRAM pins coming off the package are a scarce resource, and tying those pins to a core would be wasteful when that core doesn't need the bandwidth but another does.
I see the point you're making, but what happens when I write a parallel program? [snip] I see it as having 4 processors (or cores if you will) and hence the need to get a naming scheme that is consistant across hardware and software.
And please don't say threads:s
Well sorry, I hate to break it to you, but regardless of whether you use my nomenclature or yours, that's the only term that is going to be consistent across hardware and software.
Take for example a case I already mentioned: The Nehalem (Core i7) processor. It has 4 cores, each of which supports 2-way SMT (simultaneous multi-threading).
I mean, on the software side, the thing that you're trying to schedule are definitely threads, you ask the OS to schedule your thread, not a processor, and the thing you're interested in is how many threads can you usefully run in parallel. And for Nehalem, the answer is not 4 (number of cores/processors), but 8 (number of hardware threads).
There's a lot more wiggle room in the definition of "processor" than there is for "thread", and the "thread" terminology is the only one that properly bridges hardware and software. You're going to be hearing it more in the future, not less, so I suggest you get used to it. Sorry!:)
Man, if there's ever a situation where I'd be okay with the GM assuming I'm caught off guard, it's when my own plate of nachos leaps up and attacks my face. The only way I could be more surprised would be if the Long Island Ice Tea I bought tried to sober me up.
Re:Good marketing team
on
Robotic Mold
·
· Score: 1
Sure, the General Tso's Chicken came up with a fairly solid quicksort implementation
"Kill em all, let the ancestors sort 'em out"?
I like it. O(n) and easily executed in parallel.:)
I am glad AMD added internal thermal monitoring. Before that they weren't the hottest running, but did suffer more death by heat.
No kidding! It was way too long to get that going. If they'd had it from the beginning, I probably would have only been mildly embarrassed when my processor didn't boot and I figured out I hadn't taken the sticker off the bottom of the heatsink, rather than extremely humiliated by my own noobness and a $200 processor-turned-shitty-paperweight.:)
I should sure as fucking hell hope so! Maybe not in the "ZOMG helmet designers are TEH FAIL" sense, but lots of things can be "not-failures" and still have flaws. In fact, just about everything has flaws that could be improved.
I was unaware that these helmets were designed to protect against shockwaves as oppoesed to simply projectiles.
Which is probably why the flaw exists!
"Military Helmet Design Contributes To Brain Damage" makes it sound like the helmet itself is inflicting brain damage, no?
No, it makes it sound like the helmet may be making brain damage, resulting from some other source like say an explosion, worse than it would be otherwise, i.e. "contributing".
Which is exactly what they hypothesize in the article. It's just a hypothesis, but it makes sense -- the gap between the rigid helmet and the soldier's skull acts like a scoop, and makes the resulting pressure inside the helmet greater than the shockwave itself.
Now the researchers are careful to say that any improvements to this aspect of the helmet must not compromise the helmet's primary purpose, which is to keep the soldier from dying from bullets or shrapnel impacting the head. But within that constraint, and if the research pans out, this flaw should be fixed if at all possible.
Oh shit, I forgot to be snarky! It must be Monday...
Or, more simply: words have meaning. People should learn to use them.
Yeah, words have meaning. And there are a bunch of words in something we call "the fucking article", which you should "read", so that you can learn that the use of the word "contributing" is exactly correct.
I think he's just complaining that "contributing" isn't really fair. It implies that brain damage would be less if no helmets were worn. This is obviously false, as the helmet prevents, not contributes to, brain damage.
No, it isn't obviously false, because it is possible that a poor helmet design could increase brain damage in situations where without the helmet a lesser amount or no damage would occur.
In fact based on their simulations they believe that this is the case, that the helmet can actually act as a funnel for the shockwave and increase the force felt by the skull. Based on the fact that it is a simulation, I'm sure they pile up enough "could"s or "possibly"s to make even the most nitpicky slashdotter happy, and thus the claim is completely fair.
Works fine until we start getting specialised cores with specialised instructions.
I don't see why heterogeneity should change anything.
The processor on my desk contains two x86 cores, and a 'north bridge' memory controller with DMA engine and APIC. Soon there will be ones that also have a graphics core on them as well. I'd still call that a processor.
The Cell Processor contains a single general-purpose Power core, 8 relatively specialized cores, and a memory controller, but I feel comfortable calling the sum of them a processor.
You could call the FP unit in the processor on my desk a 'specialized core with specialized instructions', but it's still part of the overall processor. If the FP unit was its own separate DSP core, I'd still call it part of the processor.
I've adopted sockets and processors. A pizza box can 8 processors (two sockets).
So... this nomenclature doesn't take into account future developments in Multicore Mania? This story is about six cores in one socket, so you're already out of date.;)
Also, while we can easily refer to a motherboard as having two sockets, a socket is still just a thing that you plug chips into. What do you call the thing you put in the socket? A package, but that's literally a container not a thing contained. I suggest "processor" when that is the type of thing that is in the package that goes into the socket.:)
A single processor, in this case, is still a generalised processing element.
Meaning, a single core that runs a particular instruction set considered 'general' for these purposes.
I just think your definition of 'general' is too specific.:)
The first "GP" in "GP-GPU" stands for "general purpose". Sure graphics cores aren't all that well suited for truly general purpose computing, but what difference does that make if the processor is using it for data processing? Same with the Cell SPEs. Same with math "coprocessors" once they were moved onto the chip.
Personally I would suggest that we continue to call everything that fits in one package, and contains processing elements of whatever nature, a "processor", and the thing it goes into a "processor socket". Leave "cores" as a separate thing, because it makes it easy to talk about a processor with heterogenous cores -- "two x86 cores, one graphics core". Also it prevents confusion when architectures get more complicated, like lets say two x86 cores sharing a single FP unit -- is the FP unit, specialized as it is, not a processor, or not part of the processors surrounding it? What about SMT? Cores are fairly well defined physically, but perhaps not so well defined logically. See what I'm getting at?
It's hard to believe that at one time CPUs didn't have heat sinks at all.
Hehe. Yeah, and I remember getting bit by the change and feeling rather foolish. I'd built a computer for my step-sister, and, well, I really never even thought about adding a heat sink. About a year and a half, maybe two years later, she was complaining that it kept crashing so she was just going to the computer lab (defeating the point of her having her own), so I took it and checked it out. Well by this point my own system very much needed a heat sink and fan, and when I opened up hers I immediately noticed the lack of one. I took a spare heat sink/fan (and it was a tiny little thing), put it in, and the machine stop crashing. She had no more problems with it.
Well over a year without a heatsink before overheating had caused enough damage to make it actually start crashing. Kinda amazing compared to, say, the K7 I fried in at most one second by mis-applying the heat sink.
Slashdot Mirror
Remember when they found those skinless bodies in the tree in that movie and one of the guys said it was probably guerrillas who did it? Well, as a kid, I thought he was talking about gorillas.
Martin Short made the same mistake when Kurt Russel told him to watch out for the guerrillas.
In vocal alarm systems, there are practically no costs to producing false alarms.
And a possibility for great reward, as the Blue Jays know well. Bastards love to alarm call right as they're swooping in to the bird feeder.
Anyway, sorry you didn't find it interesting, each to their own.
Yeah, I wouldn't put much stock in the fact that a guy who knows literally nothing about the subject other than what they read in the summary, and is trying to use that vast body of knowledge to prove that they are smarter than researchers in the field, isn't "interested" by his own ill-informed conclusions about what is happening.
I think it's neat. :)
They are only fleeing so that they may begin le resistance!
That's pretty interesting. So our cells have the ability to repair radiation damage but don't normally bother to try? Any molecular biologists around who would care to explain this in more detail than the aforementioned link? I always thought that ionizing radiation damaged the body on a molecular level beyond any healing ability that it may have.
This was on a site you may be familiar with a while ago. The upshot is, "lethal" doses of radiation may not really cause unrepairable amounts of damage just from the radiation. However when a large number of damaged cells decide to simultaneously die, then that can definitely kill you. Preventing them from committing suicide means any cells that aren't damaged beyond repair have a chance to do so. I'm sure there'd still be a "lethal" dose even if you took this drug, but it'd be much higher.
The suicide mechanism makes a lot of sense if you think about it arising in an environment where single cell mutations/DNA damage that could result in cancer is quite common, but acute radiation poisoning is extremely rare. Replacing a single suicidal cell is easy, a whole organ's worth at once is impossible. We just never evolved a mechanism that tried to suppress the suicide response if too many cells wanted to die at once.
If you're not penalized for running down pedestrians, then you're less stressed when you take your eyes off the road.
Sorry, that makes no sense, because it's not like the non-violent version had pedestrians you had to avoid. It had targets you had to hit for points, while the violent version simply replaced the targets with pedestrians. Running over "targets" vs pedestrians, that was the difference.
Indeed, they often did back in the old days, however, I am fairly confident that at the very least, they expected a breatheable atmosphere at their destination.
Not true! It's a little known fact that one of the reasons the Pilgrims were dependent on the natives for food that first Thanksgiving was because they'd wasted so much space in their ship's hold on canisters of compressed O2. You don't hear about this much, because the Pilgrims were so embarrassed when they first met the American Indians and wanted to know how they could survive without oxygen masks!
But maybe the basic game sucks and is boring, and running down pedestrians and seeing the blood splatter is the only thing that spices it up and gets the player to actually pay attention.
I don't think the lower case "channel" was a typo. I think it's pretty clear he meant "the wii channel what has the weather" without caring what the official name is.
"Local on the 8s" is also 7 minutes too slow if you want the weather now (and you can't check weather around the world with a neat spinning globe interface =D). It is more accurate though.
*Ridge A Villas is not responsible for hypothermia, loss of limbs due to gangrene, or Abominable Snowman attacks. Any lawsuit filed against Ridge A Villas must be filed in Antarctica county district court jurisdiction within 90 hours of the incident.
Pfft, you can disclaim whatever you want. In court, it'll be easy to show that Ridge A Villas are responsible for the Abominable Snowman attacks, due to cutting him out of the mascot deal and resulting merchandising royalties.
The calmest place on earth, duh. Unfortunately it won't help you observe the stars and galaxies unless you mix in some psilocybin or LSD or what have you.
If this is like the computer revolution of the '80s, I wonder who will be claiming that we need a rocket on every desk...
A stark contrast to when it was like the computer revolution of the '60s.
<glayven> I predict that in a hundred years, rockets will be twice as powerful, ten thousand times larger, and so expensive only the five riches CEOs in the West will be able to afford them! <glayven>
Doesn't scheduling (process vs. thread) depend on the OS? IIRC Linux schedules threads the same as processes. IE. quantum slice size/interactivity credits and dynamic priorities are calculated per thread and penalties are assigned to their parent process. Windows, OTOH, does all of the accounting at the process level. We'll pretend for the moment that Windows fork is POSIX compliant.
Okay, it's true that the definitions of 'thread' and 'process' and what have you vary as much as implementations, but that's all that is, implementation details, the majority of it in the OS. How the OS decides to schedule various things isn't really the issue.
In the most general definition of "thread" as a "thread of execution", it merely means a "context" (relevant register values including page table pointer and instruction pointer) executed on the machine. This definition is a super-set of all other definitions. After all, contexts is all the hardware actually understands. All the additional qualifiers are added by the OS: e.g. in linux a "process" has its own page table, while "threads" within a process do not, but the hardware doesn't care, it just sees a context switch and whether or not the CR3 values are the same or different is just a coincidence (that the hardware may or may not exploit).
So, at the end of the day, the thing you as OS-scheduler-writer or you as parallel programmer are interested in is how many simultaneous threads of execution the hardware supports. The names of the data structures used to manipulate those threads may vary in your OS/library of choice, but that doesn't change what the basic unit of interest in the hardware is, and it certainly isn't the "processor".
It will be interesting to see what happens as socket packages become essentially multiple NUMA style processors (with their own L[123] caches/dedicated RAM and memory controllers) that share only a high speed internal and external bus.
Well I think that's either already happened or on the cusp of happening. With large L3s, you can have different latencies to different parts of the L3 from different cores on the chip. Intel's MCMs communicate on-package using the external data bus. I don't see much future for dedicated per-core DRAM controllers. That doesn't make much sense. For one, it's highly useful to have a shared cache at some level (L3 currently), and the DRAM naturally goes on the other side of the L3. DRAM pins coming off the package are a scarce resource, and tying those pins to a core would be wasteful when that core doesn't need the bandwidth but another does.
But... maybe the Ministry of Economy, Trade, and Industry is?
... but I'm willing to try!
I see the point you're making, but what happens when I write a parallel program? [snip] I see it as having 4 processors (or cores if you will) and hence the need to get a naming scheme that is consistant across hardware and software.
And please don't say threads :s
Well sorry, I hate to break it to you, but regardless of whether you use my nomenclature or yours, that's the only term that is going to be consistent across hardware and software.
Take for example a case I already mentioned: The Nehalem (Core i7) processor. It has 4 cores, each of which supports 2-way SMT (simultaneous multi-threading).
I mean, on the software side, the thing that you're trying to schedule are definitely threads, you ask the OS to schedule your thread, not a processor, and the thing you're interested in is how many threads can you usefully run in parallel. And for Nehalem, the answer is not 4 (number of cores/processors), but 8 (number of hardware threads).
There's a lot more wiggle room in the definition of "processor" than there is for "thread", and the "thread" terminology is the only one that properly bridges hardware and software. You're going to be hearing it more in the future, not less, so I suggest you get used to it. Sorry! :)
Ha! Technically though to be an authentic redneck technical, the pickup has to be up on blocks in his front yard.
Replace "future" with "zombie" (or Future Zombie!) and that's pure gold!
Roll for initiative, please.
Man, if there's ever a situation where I'd be okay with the GM assuming I'm caught off guard, it's when my own plate of nachos leaps up and attacks my face. The only way I could be more surprised would be if the Long Island Ice Tea I bought tried to sober me up.
Sure, the General Tso's Chicken came up with a fairly solid quicksort implementation
"Kill em all, let the ancestors sort 'em out"?
I like it. O(n) and easily executed in parallel. :)
I am glad AMD added internal thermal monitoring. Before that they weren't the hottest running, but did suffer more death by heat.
No kidding! It was way too long to get that going. If they'd had it from the beginning, I probably would have only been mildly embarrassed when my processor didn't boot and I figured out I hadn't taken the sticker off the bottom of the heatsink, rather than extremely humiliated by my own noobness and a $200 processor-turned-shitty-paperweight. :)
This is considered a flaw in design?
I should sure as fucking hell hope so! Maybe not in the "ZOMG helmet designers are TEH FAIL" sense, but lots of things can be "not-failures" and still have flaws. In fact, just about everything has flaws that could be improved.
I was unaware that these helmets were designed to protect against shockwaves as oppoesed to simply projectiles.
Which is probably why the flaw exists!
"Military Helmet Design Contributes To Brain Damage" makes it sound like the helmet itself is inflicting brain damage, no?
No, it makes it sound like the helmet may be making brain damage, resulting from some other source like say an explosion, worse than it would be otherwise, i.e. "contributing".
Which is exactly what they hypothesize in the article. It's just a hypothesis, but it makes sense -- the gap between the rigid helmet and the soldier's skull acts like a scoop, and makes the resulting pressure inside the helmet greater than the shockwave itself.
Now the researchers are careful to say that any improvements to this aspect of the helmet must not compromise the helmet's primary purpose, which is to keep the soldier from dying from bullets or shrapnel impacting the head. But within that constraint, and if the research pans out, this flaw should be fixed if at all possible.
Oh shit, I forgot to be snarky! It must be Monday...
Or, more simply: words have meaning. People should learn to use them.
Yeah, words have meaning. And there are a bunch of words in something we call "the fucking article", which you should "read", so that you can learn that the use of the word "contributing" is exactly correct.
I think he's just complaining that "contributing" isn't really fair. It implies that brain damage would be less if no helmets were worn. This is obviously false, as the helmet prevents, not contributes to, brain damage.
No, it isn't obviously false, because it is possible that a poor helmet design could increase brain damage in situations where without the helmet a lesser amount or no damage would occur.
In fact based on their simulations they believe that this is the case, that the helmet can actually act as a funnel for the shockwave and increase the force felt by the skull. Based on the fact that it is a simulation, I'm sure they pile up enough "could"s or "possibly"s to make even the most nitpicky slashdotter happy, and thus the claim is completely fair.
Works fine until we start getting specialised cores with specialised instructions.
I don't see why heterogeneity should change anything.
The processor on my desk contains two x86 cores, and a 'north bridge' memory controller with DMA engine and APIC. Soon there will be ones that also have a graphics core on them as well. I'd still call that a processor.
The Cell Processor contains a single general-purpose Power core, 8 relatively specialized cores, and a memory controller, but I feel comfortable calling the sum of them a processor.
You could call the FP unit in the processor on my desk a 'specialized core with specialized instructions', but it's still part of the overall processor. If the FP unit was its own separate DSP core, I'd still call it part of the processor.
I've adopted sockets and processors. A pizza box can 8 processors (two sockets).
So... this nomenclature doesn't take into account future developments in Multicore Mania? This story is about six cores in one socket, so you're already out of date. ;)
Also, while we can easily refer to a motherboard as having two sockets, a socket is still just a thing that you plug chips into. What do you call the thing you put in the socket? A package, but that's literally a container not a thing contained. I suggest "processor" when that is the type of thing that is in the package that goes into the socket. :)
A single processor, in this case, is still a generalised processing element.
Meaning, a single core that runs a particular instruction set considered 'general' for these purposes.
I just think your definition of 'general' is too specific. :)
The first "GP" in "GP-GPU" stands for "general purpose". Sure graphics cores aren't all that well suited for truly general purpose computing, but what difference does that make if the processor is using it for data processing? Same with the Cell SPEs. Same with math "coprocessors" once they were moved onto the chip.
Personally I would suggest that we continue to call everything that fits in one package, and contains processing elements of whatever nature, a "processor", and the thing it goes into a "processor socket". Leave "cores" as a separate thing, because it makes it easy to talk about a processor with heterogenous cores -- "two x86 cores, one graphics core". Also it prevents confusion when architectures get more complicated, like lets say two x86 cores sharing a single FP unit -- is the FP unit, specialized as it is, not a processor, or not part of the processors surrounding it? What about SMT? Cores are fairly well defined physically, but perhaps not so well defined logically. See what I'm getting at?
It's hard to believe that at one time CPUs didn't have heat sinks at all.
Hehe. Yeah, and I remember getting bit by the change and feeling rather foolish. I'd built a computer for my step-sister, and, well, I really never even thought about adding a heat sink. About a year and a half, maybe two years later, she was complaining that it kept crashing so she was just going to the computer lab (defeating the point of her having her own), so I took it and checked it out. Well by this point my own system very much needed a heat sink and fan, and when I opened up hers I immediately noticed the lack of one. I took a spare heat sink/fan (and it was a tiny little thing), put it in, and the machine stop crashing. She had no more problems with it.
Well over a year without a heatsink before overheating had caused enough damage to make it actually start crashing. Kinda amazing compared to, say, the K7 I fried in at most one second by mis-applying the heat sink.