Hmm, it seems like it would be rather easy to assume someone's identity, especially for totally anonymous nicknames. "Yes, I ran a major website for 10 years under the nickname CmdrTaco" - not really a great example since everybody knows his real name, but you get the idea. This actually became an issue in a different forum which I was involved with.
The drug industry has always baffled me. I'm not sure what the $105 billion is - retail level revenue or something further up, but by comparison IBM's revenues last year were $96 billion. So I find it pretty amazing that the drug industry causes so much trouble (i.e. murders, corruption, tons of people doing jail time, pay-offs, threats, etc....) when one company makes as much the whole thing.
The only way to "back up" execution is to save your state as you go.
At first I wasn't sure that your statement was true, but after thinking about it for 30 seconds or so, I realized it definitely was. Every instruction produces a deterministic calculation and can be reversed, right? If we have "ADD EAX, EBX", and know the current values of EAX and EBX, going backwards is easy, right?
Well, one really difficult case is jumps. How do you know what the previous instruction executed was? On X86 this would be pretty difficult since the encodings are non-regular, but even on an ISA with regular encodings it would be non-trivial because it would be difficult to figure whether you got to the instruction via a jump (which could be anywhere in memory), or from the previous instruction.
Add things such as Self-Modifying Code, and you have a real headache. Yes, you definitely need to track state as you go, though I'm not sure you'd need to save anything more than just the Instruction Pointer (which X86 does have a mechanism for). If you know what instructions were executed, it should be pretty easy to backtrack in time. I think.
I have a hard time believing this. What are the processors actually doing? If you simply power up processors without being connected to chipset or memory they won't do a whole lot. Most likely it would get through reset (assuming reset doesn't do any chipset queries, etc.), then put out a Code Fetch for the reset vector, which would never come back, then it would go into some sort of shutdown state. So I find it hard to believe that just powering up processors would produce that much heat. There are specific workloads which could be used to maximize power throughput, but obviously they are not at work here.
Technically it's lost the grilling-functionality, but with a bit of tin foil on top of the heatsink and a fork-bomb, I reckon I could probably still fry an egg with it.
An egg? With how busy it is now he could probably fry a whole cow.
My thoughts exactly. You know, there's something like 10 million people living in this country, who risked their lives swimming across river or crawling through scorching desert to come here to earn $6/hour cleaning toilets, while having huge extended families, seem to live happily, and still have plenty of money to send to the relatives back in the homeland. Anybody who can't live off $30/hr - sheesh...
Most are manufactured in US; the only foreign countries where they are made are Ireland and Israel. They are packaged in various places around the world (Costa Rica, Malaysia, Philipines, etc.).
Intel's main fabs are in Oregon, New Mexico, California, Massachusetts, Israel, and Ireland (there may be a few others in the US which I'm forgetting).
Intel doesn't have a fab in Malaysia. There is chip packaging in Malaysia, as well as Costa Rica and Philipines.
Re:I guess you learn something every day.
on
Are You Using 802.1X?
·
· Score: 5, Informative
You're thinking of "802.11x" which generally means any of 802.11b, 802.11a, or 802.11g (wireless protocols). "802.1x" is a security protocol, not a wireless protocol per se. Very confusing, I know...
An 8086 @ 1Ghz would be substantially slower than a P3 or P4 @ 1GHz. The 8086 was a scalar, unpipelined, single issue machine, with no cache, no FPU unit, and a substantial average CPI (something like one or two dozen cycles). Most performance increases since the 8086 have been due to increasing IPC not frequency. I think a Pentium, and maybe a 486, would be faster than P3/P4 but not 8086.
Intel is the fifth most valuable brand in the world. Intel has something like 85% of the desktop CPU market, even while it charges a substantial premium against the competition. That's the value of the brand, right there. If its brand was less valuable it wouldn't be able to charge a premium while maintaining market share.
To quote Linus: "And I further bet that using a native distribution (ie totally ignoring the power and price and bad x86 performance issues), ia-64 will work a lot worse for people simply because the binaries are bigger. That was quite painful on alpha, and ia-64 is even worse - to offset the bigger binaries, you need a faster disk subsystem etc just to not feel slower than a bog-standard PC."
Yeah, RISC workstations always seemed sluggish to me for interactive use. Not sure if it's really due to the increased time to load binaries, or some other optimization issue.
Linus spends a lot of time debunking the "more registers is better" myth. X86 implementations have been addressing this issue for a long time, both by register renaming and by having extremely fast L1 data caches (esp. on P4). Adding more registers will not help speed up code much at all - and anyways requires a recompile and won't help improving legacy code.
Digital cable + HDTV is a great deal, if available. I get Time Warner in Austin which carries 4 HD channels: CBS, ABC, HBO, & Showtime. The HD-capable receiver & programming is the same price as the digital receiver, so free if you get digital cable anyways. So no need for the expensive receiver, and you don't have to mess with satellite. There's a large community of hobbyists who mess with receiving the broadcast HD channels, and they remind me of the old radio DX'ers who try to listen to the distant radio stations. It seems like an archaic means of getting into new technology - and it's also expensive.
Yes you're correct with IA32 you're limited to 4GB per process. I wouldn't call it a "kludge"; basically you have 36 bits to specify a physical address in each PTE, but are still limited to 32 bit linear addressing. This means you can have 2^36 bytes of RAM, and processes can be spread out throughout that whole address space. I'd only consider it to be a kludge if there were "windows" or "partitions" and you could access 4GB of consecutive at once.
Note that this is completely transparent to the process. The OS is responsible for setting up paging. Note also that on a server you typically run a whole lot of processes anyways (e.g. a whole bunch of web server processes) so for most server applications I don't see it as a major limitation (big databases may be one problem)
Note also that theoretically that you could have system where the process could access more than 4GB of linear address space, if you set aside some region of linear address space for this purpose, and had a system call to update where this was going to. This is an ugly, ugly kludge, requires OS modification, and reminds of DOS style memory management but could be done (and would probably be cheaper than moving off of X86...)
I don't know why or where you're paying $20 for CD's. At Amazon most of the best-selling CD's are in the $12.98-$13.49 range (some more, some less).
If the marginal cost of producing a CD were $2, sales would have to quadruple for the $6.95 price tag to bring in the same profit as your $20 price point (or double to reach $13.49). Seems very unlikely that the price drop would spur that dramatic of a buying increase.
Everything you can do with printf (i.e. examine variables), you can do in a debugger. The advantage being that you don't have to recompile everytime you want to examine another variable.
It is almost impossible to debug certain types of bugs with printf - e.g. if a bug is exposed after calling a particular small function 10 million times, with three different parameter values, you simply wouldn't be able to do this with printf.
That said, you can do significantly more with debuggers besides examine variables, such as data breakpoints and watchpoints. You can cascade different conditions together to trigger after condition A in function X occurs, and condition B in function Y has occurred, and after condition C in function Z has occurred. You can't do this with printf's since you don't have access to any variables except that function's local variables so you can't monitor what's going on in other functions.
Slashdot Mirror
Hmm, it seems like it would be rather easy to assume someone's identity, especially for totally anonymous nicknames. "Yes, I ran a major website for 10 years under the nickname CmdrTaco" - not really a great example since everybody knows his real name, but you get the idea. This actually became an issue in a different forum which I was involved with.
The drug industry has always baffled me. I'm not sure what the $105 billion is - retail level revenue or something further up, but by comparison IBM's revenues last year were $96 billion. So I find it pretty amazing that the drug industry causes so much trouble (i.e. murders, corruption, tons of people doing jail time, pay-offs, threats, etc. ...) when one company makes as much the whole thing.
Moore's Law has nothing to do with clockspeed.
Are you new to semiconductor physics?
The only way to "back up" execution is to save your state as you go.
At first I wasn't sure that your statement was true, but after thinking about it for 30 seconds or so, I realized it definitely was. Every instruction produces a deterministic calculation and can be reversed, right? If we have "ADD EAX, EBX", and know the current values of EAX and EBX, going backwards is easy, right?
Well, one really difficult case is jumps. How do you know what the previous instruction executed was? On X86 this would be pretty difficult since the encodings are non-regular, but even on an ISA with regular encodings it would be non-trivial because it would be difficult to figure whether you got to the instruction via a jump (which could be anywhere in memory), or from the previous instruction.
Add things such as Self-Modifying Code, and you have a real headache. Yes, you definitely need to track state as you go, though I'm not sure you'd need to save anything more than just the Instruction Pointer (which X86 does have a mechanism for). If you know what instructions were executed, it should be pretty easy to backtrack in time. I think.
I have a hard time believing this. What are the processors actually doing? If you simply power up processors without being connected to chipset or memory they won't do a whole lot. Most likely it would get through reset (assuming reset doesn't do any chipset queries, etc.), then put out a Code Fetch for the reset vector, which would never come back, then it would go into some sort of shutdown state. So I find it hard to believe that just powering up processors would produce that much heat. There are specific workloads which could be used to maximize power throughput, but obviously they are not at work here.
Technically it's lost the grilling-functionality, but with a bit of tin foil on top of the heatsink and a fork-bomb, I reckon I could probably still fry an egg with it.
An egg? With how busy it is now he could probably fry a whole cow.
I used to live in Austin, and it's an 8-hour drive to the nearest state line.
There are 3 states which are 4 hour drives from Austin. Tamaulipas, Nuevo Leon, and Coahuila. Chihuahua should be doable in less than 8 hours also.
My thoughts exactly. You know, there's something like 10 million people living in this country, who risked their lives swimming across river or crawling through scorching desert to come here to earn $6/hour cleaning toilets, while having huge extended families, seem to live happily, and still have plenty of money to send to the relatives back in the homeland. Anybody who can't live off $30/hr - sheesh...
Most are manufactured in US; the only foreign countries where they are made are Ireland and Israel. They are packaged in various places around the world (Costa Rica, Malaysia, Philipines, etc.).
Intel's main fabs are in Oregon, New Mexico, California, Massachusetts, Israel, and Ireland (there may be a few others in the US which I'm forgetting).
Intel doesn't have a fab in Malaysia. There is chip packaging in Malaysia, as well as Costa Rica and Philipines.
You're thinking of "802.11x" which generally means any of 802.11b, 802.11a, or 802.11g (wireless protocols). "802.1x" is a security protocol, not a wireless protocol per se. Very confusing, I know...
An 8086 @ 1Ghz would be substantially slower than a P3 or P4 @ 1GHz. The 8086 was a scalar, unpipelined, single issue machine, with no cache, no FPU unit, and a substantial average CPI (something like one or two dozen cycles). Most performance increases since the 8086 have been due to increasing IPC not frequency. I think a Pentium, and maybe a 486, would be faster than P3/P4 but not 8086.
Yes, and the peak bandwidth of the double-pumped 200 MHz Athlon bus is 3.2 GB/s, and the peak bandwidth of the quad-pumped 200 MHz P4 bus is 6.4 GB/s.
So factoring the double/pumped into frequency gives the more realistic performance picture.
Intel is the fifth most valuable brand in the world. Intel has something like 85% of the desktop CPU market, even while it charges a substantial premium against the competition. That's the value of the brand, right there. If its brand was less valuable it wouldn't be able to charge a premium while maintaining market share.
P4 is 2 cycles not 7, for L1. The L2 is 7.
To quote Linus: "And I further bet that using a native distribution (ie totally ignoring the power and price and bad x86 performance issues), ia-64 will work a lot worse for people simply because the binaries are bigger. That was quite painful on alpha, and ia-64 is even worse - to offset the bigger binaries, you need a faster disk subsystem etc just to not feel slower than a bog-standard PC."
Yeah, RISC workstations always seemed sluggish to me for interactive use. Not sure if it's really due to the increased time to load binaries, or some other optimization issue.
Did you read the source for the Inquirier article?
Linus spends a lot of time debunking the "more registers is better" myth. X86 implementations have been addressing this issue for a long time, both by register renaming and by having extremely fast L1 data caches (esp. on P4). Adding more registers will not help speed up code much at all - and anyways requires a recompile and won't help improving legacy code.
Digital cable + HDTV is a great deal, if available. I get Time Warner in Austin which carries 4 HD channels: CBS, ABC, HBO, & Showtime. The HD-capable receiver & programming is the same price as the digital receiver, so free if you get digital cable anyways. So no need for the expensive receiver, and you don't have to mess with satellite. There's a large community of hobbyists who mess with receiving the broadcast HD channels, and they remind me of the old radio DX'ers who try to listen to the distant radio stations. It seems like an archaic means of getting into new technology - and it's also expensive.
Yes you're correct with IA32 you're limited to 4GB per process. I wouldn't call it a "kludge"; basically you have 36 bits to specify a physical address in each PTE, but are still limited to 32 bit linear addressing. This means you can have 2^36 bytes of RAM, and processes can be spread out throughout that whole address space. I'd only consider it to be a kludge if there were "windows" or "partitions" and you could access 4GB of consecutive at once.
Note that this is completely transparent to the process. The OS is responsible for setting up paging. Note also that on a server you typically run a whole lot of processes anyways (e.g. a whole bunch of web server processes) so for most server applications I don't see it as a major limitation (big databases may be one problem)
Note also that theoretically that you could have system where the process could access more than 4GB of linear address space, if you set aside some region of linear address space for this purpose, and had a system call to update where this was going to. This is an ugly, ugly kludge, requires OS modification, and reminds of DOS style memory management but could be done (and would probably be cheaper than moving off of X86...)
Since when is the recording industry making a profit? Last time I checked, none of the biggest 5 recording companies are profitable.
That's Ok. I've met computer professionals who think 'gigabyte' is pronounced with a hard "g" as in 'gift'.
I don't know why or where you're paying $20 for CD's. At Amazon most of the best-selling CD's are in the $12.98-$13.49 range (some more, some less).
If the marginal cost of producing a CD were $2, sales would have to quadruple for the $6.95 price tag to bring in the same profit as your $20 price point (or double to reach $13.49). Seems very unlikely that the price drop would spur that dramatic of a buying increase.
Everything you can do with printf (i.e. examine variables), you can do in a debugger. The advantage being that you don't have to recompile everytime you want to examine another variable.
It is almost impossible to debug certain types of bugs with printf - e.g. if a bug is exposed after calling a particular small function 10 million times, with three different parameter values, you simply wouldn't be able to do this with printf.
That said, you can do significantly more with debuggers besides examine variables, such as data breakpoints and watchpoints. You can cascade different conditions together to trigger after condition A in function X occurs, and condition B in function Y has occurred, and after condition C in function Z has occurred. You can't do this with printf's since you don't have access to any variables except that function's local variables so you can't monitor what's going on in other functions.
40 hours/week is working your ass off? I'd consider it a vacation!
You got the day off? Lucky bastard!