That's not what's usually understood when someone says they're splitting atoms. Otherwise, I could split a few million just scuffing my socks on the carpet or by forgetting to put a dryer sheet in when I do laundry.
Besides, there's an awful lot of ionized hydrogen out there. (Basically, just protons floating around, possibly with a neutron attached).
In any case, protons are a few orders of magnitude more massive than electrons. You're gonna need a strong-ass rudder to keep from going in circles!
I actually got the impression he was including a lot of the 32-bit microcontrollers out there too. If you look at a lot of the embedded ARMs that show up in various SoCs, his "low end CPU" comments apply to those, too. Simple pipeline, in-order execution, etc.
That was a fabulous presentation, and one that I'll likely hold onto a copy of, since it describes the issue of SMP memory ordering with a great example. I'll have to write "presenter notes" for those slides, since I can't get the video to come up, but that's OK. I understand what's going on there.
One thing I thought was notably absent was any discussion of data prefetch. With all of the emphasis on how performance is dominated by cache misses, you'd think he'd give at least a nod to both automatic hardware and compiler directed software prefetch. After all, he mentions CMT, which is a more exotic way to hide memory latency, IMHO.
On a different note: In the example on slides 23 - 30, he shows an example where speculation allowed two cache misses to pipeline, bringing the cost-per-miss down to about half. Dunno if he highlighted the synergy here in the talk, because it wasn't highlighted in the presentation. It is useful to note, though, how overlapping cache misses reduces their cost. There can be even more synergy here than is otherwise obvious: In HPCA-14, there was a fascinating paper (slides) about how incorrect speculation can still speed up programs due to misses on the incorrectly-speculated path still bringing in relevant cache lines.
At least, not their default representation. There are plenty of computers that provide some amount of acceleration for BCD arithmetic, including every x86 box out there.:-) BCD arithmetic is still rather common in financial applications.
I wouldn't say it's incorrect. It's quite common to represent binary strings as hexadecimal strings regardless of the underlying format. After all, what units would you apply to an x86 opcode? what about a portion of an H.264 bit stream? Or heck, even a floating point number? 0x3F800000 is the hexadecimal representation of the IEEE 754 single precision floating point number 1.0. (And if you don't think people write floating point numbers in hex, thinkagain.
Now the integer 10 encoded in standard binary format would be 1010, which written in hexadecimal would be A (or 0x0A in C syntax). It also happens to be the same as if you directly went from base 10 to base 16 and ended up with 0x0A. If the decimal number were encoded as BCD, though, the resulting binary string would be written 00010000 (or 0001 0000 if you so choose--the spaces are insignificant!), and that binary string is equivalent to the hexadecimal string 0x10. Note that "hexadecimal string" does not imply base-16 number. It's just a shorter representation than the binary string. It is not equivalent to the hexadecimal number 0x10. When I said "written in hexadecimal", I meant "when written as a hexadecimal string."
Look at it this way: If I were trying to hex-dump a file full of BCD values and the file had nothing but the value "10" (decimal) over and over in each byte, I would see 0x10 in every byte, not 0x0A. Try it. Go write a 6502 or x86 program that uses that processor's BCD mode, and then do a hex dump of memory. Or better yet, go get a BCD number, and pass it to the "%x" format specifier in your favorite C compiler (or other language that uses C's format specifiers).
In this case, one guy is talking BCD, another guy assumed binary, and it was no big deal until 2010 rolled around and 10 suddenly became 16.
I think you mean to say "one guy is talking BCD, another guy assumed standard binary integer. The "B" in BCD is "Binary" after all... Every number stored in the computer is in one binary format or another. Saying "assumed binary" is roughly the same as "assumed the number was stored in a computer." You have to say which format.
Bullshit. I agree that the 0x prefix specifies that the digits that follow it are in hexadecimal. It does NOT specify the encoding of the data in the bits. For example, the hexadecimal string 0x3F800000 is the single precision IEEE floating point value '1.0', rendered as a hexadecimal string. Try it out and see.
Binary coded decimal is just that: A binary coding scheme for decimal values. How you render the binary string for human readability purposes is up to you! That's just the same as writing "one million two hundred thirty four thousand five hundred sixty seven and eighty nine hundreths" as 1,234,567.89 or 1234567.89 or 1.234.567,89 (in parts of the world that use periods and commas the opposite of the way the US does).
I suggest you've never seen an actual memory dump from a real computer, have you? Here's one I took just now on my Windows box. Which of these values are integers, floating point values, x86 opcodes or BCD values? Memory dumps don't indicate, because the memory itself doesn't know! Once it's in memory it's all just bits!
“Binary” refers to its internal number representation (encoding system), not its base system.
Hmmm....
2. Mathematics.
a. of or pertaining to a system of numerical notation to the base 2, in which each place of a number, expressed as 0 or 1, corresponds to a power of 2. The decimal number 58 appears as 111010 in binary notation, since 58 = 1 × 2^5 + 1 × 2^4 + 1 × 2^3 + 0 × 2^2 + 1 × 2^1 + 0 × 2^0.
(Note: In the blockquote above, I used "^" to indicate superscript, since Slashdot eats <SUP> tags last time I checked.)
And there are many, many numeric representations of integers in binary coding beyond standard 2s complement integer and BCD. Exp-Golomb, Redundant Binary, Densely Packed Decimal to name just a few.
The decimal number 10 would be encoded in BCD as 0001 0000, which would be written in hexadecimal as 0x10
The decimal number 16 would be encoded in standard 2s complement integer format in binary as 0001 0000, which would be written in hexadecimal as 0x10
Before you argue that 00010000 is somehow different from 0001 0000, the space is just there for readability. If you pop open a memory viewer and look at a hex dump of RAM, you'll see that 10 decimal stored in BCD in a byte of RAM looks like 16 decimal stored in standard integer representation in a byte of RAM, which is more than likely strongly related to the source of the "2016 error."
(Note that I say "standard 2s complement integer format" to distinguish from other possible representations, such as floating point, etc.)
The phrase "0x10 is still 16 in binary" could be interpreted two ways that make absolutely no sense. Consider these two sentences as models: "Rojo means 'red' in Spanish," and "Red is 'rojo' in Spanish." In both cases, "in Spanish" indicates to the reader that "rojo" is a Spanish word. No number in the sentence "0x10 is still 16 in binary" is in binary. 0x10 is a hexadecimal number, and 16 is a decimal number. Your sentence can't be interpreted in either way--as saying "0x10 is... in binary" or "16 [is] in binary"--and be anywhere near correct.
At any rate, I agree with many of the other Slashdotters that there seems to be a BCD vs. normal integer disagreement issue in the software here.
Here's my rule, and it seems entirely consistent with (most) common use:
Each shorthand date range includes its eponymous year.
"Eponymous" means "giving one's name to." So, if you say "the 1900s", to me, that means 1900 - 1999, since 1900 is the eponymous year. If you say "20th century", then that should include the year 2000, since 2000 is the eponymous year. That ends up with 20th century meaning "1901 - 2000." The 3rd millennium would then include the year 3000, and so would be "2001 - 3000". The 2000s though would be 2000 - 2999.
Going back to your example, "The 60s" would imply 60 - 69. That's how we talk about temperatures, so why wouldn't it apply to dates? It'd be weird for "60s" to not include 70, but not include 60.
Now, if you want to talk about the 201st decade (who talks like that?), then yes, that'd go from 2001 to 2010. But, if you want to talk about the noughties, that'd be 2000 - 2009.
Where I work, if you are on company property and above the legal limit for intoxication (ie. 0.08% BAC), that's grounds for termination. Now, two managers have to notice and agree to send you for testing, but still, that's not something I'd ever want to test.
If "on call" means having to come on site, then that means minimal drinking (ie. 1 standardized drink an hour approximately, so a beer or two with dinner or a small nightcap is fine) when there's no backup. If "on call" means having to answer a phone and log in remote? Then maybe you can have a couple more drinks, but you're still pushing it, IMHO.
Yep, I do work for that vendor, on the C6000 team. (On C6000 since 1998, actually.)
I don't know why the Windows versions of the tools were so much slower than the Linux ones. I have found that many command line tools brought over to Windows from *nix using Cygwin (and maybe MinGW in some cases) seem to have significant, strange pauses if run from CMD.EXE. For example, my copy of "less" takes around 10 seconds to start. I don't know how we compile our Windows tool versions, though, so I have no idea if it's a similar mechanism at play or not.
The IDE definitely doesn't support multiple platforms well. The fact that you have to "configure a board" before you even start, and that you can't just defer that or configure a set of boards just irks me as well.
Hopefully your experience with the chips themselves wasn't too bad. Who knows, depending on what you were working on, you may've gotten to use some of my code directly, at least on the C64x!:-)
Well, in languages such as Java, the finalize() method may neverbe called. You have to manually call a "close"/"destroy" type method since finalize() isn't really a destructor. Even C# recommends you implement explicit destruction (See "Explicit Release of Resources" in the linked page.) I quote:
The programmer has no control over when the destructor is called because this is determined by the garbage collector. The garbage collector checks for objects that are no longer being used by the application. If it considers an object eligible for destruction, it calls the destructor (if any) and reclaims the memory used to store the object. Destructors are also called when the program exits. [...] If your application is using an expensive external resource, we also recommend that you provide a way to explicitly release the resource before the garbage collector frees the object.
In other words, the lazy destruction in a "managed" language can really bite you in the hindside, since who knows when the GC will get around to releasing your resource? Why else would a managed language have an entire standard interface devoted to the problem?
In contrast, in C++ (an unmanaged language), objects' destructors are always called automatically when they go out of scope or when you delete them.
I used to write very low level C and assembly for two different DSP processors for a living, too.We used the vendor's joke of an IDE for debugging and only debugging. Everything else was better* with external editor (Emacs or UltraEdit depending on developer's taste, I don't think anyone used vi) and command line. I hear that the vendor has since then abandoned their home-brew IDE and maintains a fork of Eclipse instead.
Hmmm... I get the sinking feeling I work for that vendor.:-) Which family DSPs?
FWIW, I don't use our GUI either except for loading stuff on silicon. Most of the time though, I'm working with the processor about a year or more before there's silicon, so that means I'm doing everything under Linux with make and the command-line compiler anyway.
These days, many compilers offer mechanisms to access SIMD instructions from the high level language, so that you don't have to yourself. These vary from special vector types, to "intrinsic functions" that model the target instructions, to directives to specify pointer alignment and loop iteration count properties. The compiler for the architecture family I work on is rather sophisticated in this regards, and it does some really impressive transformations. Even without annotations, it can figure quite a lot out if enough of the program is visible to it.
That said, I sometimes still pop down to hand-coded assembly when it really, really matters, but these days it's usually to do things that can't be expressed in C/C++, such as manipulating interrupt vector tables or aspects of the run time environment. Most people I know that try to "optimize" something by writing assembly code delude themselves that they can outperform the compiler. I remember seeing this one several-page assembly function that had been optimized over several months by one of our teams at work get replaced by ~30-40 lines of properly written C code that compiled to 30% faster code. Assembly code isn't magic.
I'd call that "runtime environment glue" and that's an extremely appropriate place for assembly code in modern programming. You're quite literally outside the language at that point, when you have to manually manage the calling convention.
BTW, while that Wikipedia article mentions COM can do a fat binary, it doesn't mention how and it does say [Citation Needed]. I suspect it was a machine code hack such that the same bit of machine code would branch to the 8086 vs. 8080 portions of code due to differences in how the two CPUs interpreted the same instructions. I wouldn't really call that "support", since COM was a headerless format. It was just raw object code loaded at a fixed address!
Another nicety is that cross-compiling gets baked into the DNA of the tools, and now becomes trivial. When I build jzIntv on my Mac, I just add "-arch ppc -arch i386" and GCC does the right thing. I've been doing that for years. Cross compiling an 32-bit x86 version of jzIntv on my x86-64 Ubuntu box is a little more complicated, enough so that it's just easier to do it on a 32-bit machine instead. That seems a bit heavy handed and backwards.
Then there's the whole/lib vs./lib32 vs./lib64 stuff, and how I still manage to get errors like this that are just too much pain to track down:
It used to work... I don't know what I did to break it, but I clearly did something. Oh well. How annoying! Fat binaries would make this work effortlessly. Disk space is waaaaay cheaper than my time.
Hmm... My wife's clamshell iBook worked right up until the day she put it away because she moved from Mac OS 9 to OS X. Our Blue & White Mac G3 is still going strong. Ok, we needed to replace the hard drive after 4 years, but that wasn't made by Apple. Oh, and the monitor died after 6 or 7 years. That's a pretty good run for a CRT anymore. The machine itself is 10 years old now.
Slashdot Mirror
That's not what's usually understood when someone says they're splitting atoms. Otherwise, I could split a few million just scuffing my socks on the carpet or by forgetting to put a dryer sheet in when I do laundry.
Besides, there's an awful lot of ionized hydrogen out there. (Basically, just protons floating around, possibly with a neutron attached).
In any case, protons are a few orders of magnitude more massive than electrons. You're gonna need a strong-ass rudder to keep from going in circles!
Hmmm.... something tells me that cutting a large number of single protons in half right in front of the ship would more than double their problems....
Wait... wasn't Firefox the "de-bloated" Mozilla?
I actually got the impression he was including a lot of the 32-bit microcontrollers out there too. If you look at a lot of the embedded ARMs that show up in various SoCs, his "low end CPU" comments apply to those, too. Simple pipeline, in-order execution, etc.
That was a fabulous presentation, and one that I'll likely hold onto a copy of, since it describes the issue of SMP memory ordering with a great example. I'll have to write "presenter notes" for those slides, since I can't get the video to come up, but that's OK. I understand what's going on there.
One thing I thought was notably absent was any discussion of data prefetch. With all of the emphasis on how performance is dominated by cache misses, you'd think he'd give at least a nod to both automatic hardware and compiler directed software prefetch. After all, he mentions CMT, which is a more exotic way to hide memory latency, IMHO.
On a different note: In the example on slides 23 - 30, he shows an example where speculation allowed two cache misses to pipeline, bringing the cost-per-miss down to about half. Dunno if he highlighted the synergy here in the talk, because it wasn't highlighted in the presentation. It is useful to note, though, how overlapping cache misses reduces their cost. There can be even more synergy here than is otherwise obvious: In HPCA-14, there was a fascinating paper (slides) about how incorrect speculation can still speed up programs due to misses on the incorrectly-speculated path still bringing in relevant cache lines.
At least, not their default representation. There are plenty of computers that provide some amount of acceleration for BCD arithmetic, including every x86 box out there. :-) BCD arithmetic is still rather common in financial applications.
I wouldn't say it's incorrect. It's quite common to represent binary strings as hexadecimal strings regardless of the underlying format. After all, what units would you apply to an x86 opcode? what about a portion of an H.264 bit stream? Or heck, even a floating point number? 0x3F800000 is the hexadecimal representation of the IEEE 754 single precision floating point number 1.0. (And if you don't think people write floating point numbers in hex, think again.
Now the integer 10 encoded in standard binary format would be 1010, which written in hexadecimal would be A (or 0x0A in C syntax). It also happens to be the same as if you directly went from base 10 to base 16 and ended up with 0x0A. If the decimal number were encoded as BCD, though, the resulting binary string would be written 00010000 (or 0001 0000 if you so choose--the spaces are insignificant!), and that binary string is equivalent to the hexadecimal string 0x10. Note that "hexadecimal string" does not imply base-16 number. It's just a shorter representation than the binary string. It is not equivalent to the hexadecimal number 0x10. When I said "written in hexadecimal", I meant "when written as a hexadecimal string."
Look at it this way: If I were trying to hex-dump a file full of BCD values and the file had nothing but the value "10" (decimal) over and over in each byte, I would see 0x10 in every byte, not 0x0A. Try it. Go write a 6502 or x86 program that uses that processor's BCD mode, and then do a hex dump of memory. Or better yet, go get a BCD number, and pass it to the "%x" format specifier in your favorite C compiler (or other language that uses C's format specifiers).
I think you mean to say "one guy is talking BCD, another guy assumed standard binary integer. The "B" in BCD is "Binary" after all... Every number stored in the computer is in one binary format or another. Saying "assumed binary" is roughly the same as "assumed the number was stored in a computer." You have to say which format.
Bullshit. I agree that the 0x prefix specifies that the digits that follow it are in hexadecimal. It does NOT specify the encoding of the data in the bits. For example, the hexadecimal string 0x3F800000 is the single precision IEEE floating point value '1.0', rendered as a hexadecimal string. Try it out and see.
Binary coded decimal is just that: A binary coding scheme for decimal values. How you render the binary string for human readability purposes is up to you! That's just the same as writing "one million two hundred thirty four thousand five hundred sixty seven and eighty nine hundreths" as 1,234,567.89 or 1234567.89 or 1.234.567,89 (in parts of the world that use periods and commas the opposite of the way the US does).
I suggest you've never seen an actual memory dump from a real computer, have you? Here's one I took just now on my Windows box. Which of these values are integers, floating point values, x86 opcodes or BCD values? Memory dumps don't indicate, because the memory itself doesn't know! Once it's in memory it's all just bits!
Ooops, I meant to include this link to the dictionary entry.
Hmmm....
(Note: In the blockquote above, I used "^" to indicate superscript, since Slashdot eats <SUP> tags last time I checked.)
And there are many, many numeric representations of integers in binary coding beyond standard 2s complement integer and BCD. Exp-Golomb, Redundant Binary, Densely Packed Decimal to name just a few.
Some more observations:
Before you argue that 00010000 is somehow different from 0001 0000, the space is just there for readability. If you pop open a memory viewer and look at a hex dump of RAM, you'll see that 10 decimal stored in BCD in a byte of RAM looks like 16 decimal stored in standard integer representation in a byte of RAM, which is more than likely strongly related to the source of the "2016 error."
(Note that I say "standard 2s complement integer format" to distinguish from other possible representations, such as floating point, etc.)
10 hexadecimal is 16 decimal is 10000 binary.
The phrase "0x10 is still 16 in binary" could be interpreted two ways that make absolutely no sense. Consider these two sentences as models: "Rojo means 'red' in Spanish," and "Red is 'rojo' in Spanish." In both cases, "in Spanish" indicates to the reader that "rojo" is a Spanish word. No number in the sentence "0x10 is still 16 in binary" is in binary. 0x10 is a hexadecimal number, and 16 is a decimal number. Your sentence can't be interpreted in either way--as saying "0x10 is ... in binary" or "16 [is] in binary"--and be anywhere near correct.
At any rate, I agree with many of the other Slashdotters that there seems to be a BCD vs. normal integer disagreement issue in the software here.
Editing fail. I meant to say "to include 70 but not include 60."
Here's my rule, and it seems entirely consistent with (most) common use:
"Eponymous" means "giving one's name to." So, if you say "the 1900s", to me, that means 1900 - 1999, since 1900 is the eponymous year. If you say "20th century", then that should include the year 2000, since 2000 is the eponymous year. That ends up with 20th century meaning "1901 - 2000." The 3rd millennium would then include the year 3000, and so would be "2001 - 3000". The 2000s though would be 2000 - 2999.
Going back to your example, "The 60s" would imply 60 - 69. That's how we talk about temperatures, so why wouldn't it apply to dates? It'd be weird for "60s" to not include 70, but not include 60.
Now, if you want to talk about the 201st decade (who talks like that?), then yes, that'd go from 2001 to 2010. But, if you want to talk about the noughties, that'd be 2000 - 2009.
Where I work, if you are on company property and above the legal limit for intoxication (ie. 0.08% BAC), that's grounds for termination. Now, two managers have to notice and agree to send you for testing, but still, that's not something I'd ever want to test.
If "on call" means having to come on site, then that means minimal drinking (ie. 1 standardized drink an hour approximately, so a beer or two with dinner or a small nightcap is fine) when there's no backup. If "on call" means having to answer a phone and log in remote? Then maybe you can have a couple more drinks, but you're still pushing it, IMHO.
Yep, I do work for that vendor, on the C6000 team. (On C6000 since 1998, actually.)
I don't know why the Windows versions of the tools were so much slower than the Linux ones. I have found that many command line tools brought over to Windows from *nix using Cygwin (and maybe MinGW in some cases) seem to have significant, strange pauses if run from CMD.EXE. For example, my copy of "less" takes around 10 seconds to start. I don't know how we compile our Windows tool versions, though, so I have no idea if it's a similar mechanism at play or not.
The IDE definitely doesn't support multiple platforms well. The fact that you have to "configure a board" before you even start, and that you can't just defer that or configure a set of boards just irks me as well.
Hopefully your experience with the chips themselves wasn't too bad. Who knows, depending on what you were working on, you may've gotten to use some of my code directly, at least on the C64x! :-)
Small world, eh? Howdy!
Well, in languages such as Java, the finalize() method may never be called. You have to manually call a "close"/"destroy" type method since finalize() isn't really a destructor. Even C# recommends you implement explicit destruction (See "Explicit Release of Resources" in the linked page.) I quote:
In other words, the lazy destruction in a "managed" language can really bite you in the hindside, since who knows when the GC will get around to releasing your resource? Why else would a managed language have an entire standard interface devoted to the problem?
In contrast, in C++ (an unmanaged language), objects' destructors are always called automatically when they go out of scope or when you delete them.
Hmmm... I get the sinking feeling I work for that vendor. :-) Which family DSPs?
FWIW, I don't use our GUI either except for loading stuff on silicon. Most of the time though, I'm working with the processor about a year or more before there's silicon, so that means I'm doing everything under Linux with make and the command-line compiler anyway.
These days, many compilers offer mechanisms to access SIMD instructions from the high level language, so that you don't have to yourself. These vary from special vector types, to "intrinsic functions" that model the target instructions, to directives to specify pointer alignment and loop iteration count properties. The compiler for the architecture family I work on is rather sophisticated in this regards, and it does some really impressive transformations. Even without annotations, it can figure quite a lot out if enough of the program is visible to it.
That said, I sometimes still pop down to hand-coded assembly when it really, really matters, but these days it's usually to do things that can't be expressed in C/C++, such as manipulating interrupt vector tables or aspects of the run time environment. Most people I know that try to "optimize" something by writing assembly code delude themselves that they can outperform the compiler. I remember seeing this one several-page assembly function that had been optimized over several months by one of our teams at work get replaced by ~30-40 lines of properly written C code that compiled to 30% faster code. Assembly code isn't magic.
I'd call that "runtime environment glue" and that's an extremely appropriate place for assembly code in modern programming. You're quite literally outside the language at that point, when you have to manually manage the calling convention.
BTW, while that Wikipedia article mentions COM can do a fat binary, it doesn't mention how and it does say [Citation Needed]. I suspect it was a machine code hack such that the same bit of machine code would branch to the 8086 vs. 8080 portions of code due to differences in how the two CPUs interpreted the same instructions. I wouldn't really call that "support", since COM was a headerless format. It was just raw object code loaded at a fixed address!
Another nicety is that cross-compiling gets baked into the DNA of the tools, and now becomes trivial. When I build jzIntv on my Mac, I just add "-arch ppc -arch i386" and GCC does the right thing. I've been doing that for years. Cross compiling an 32-bit x86 version of jzIntv on my x86-64 Ubuntu box is a little more complicated, enough so that it's just easier to do it on a 32-bit machine instead. That seems a bit heavy handed and backwards.
Then there's the whole /lib vs. /lib32 vs. /lib64 stuff, and how I still manage to get errors like this that are just too much pain to track down:
$ mplayer
mplayer: error while loading shared libraries: libgtk-1.2.so.0: wrong ELF class: ELFCLASS64
It used to work... I don't know what I did to break it, but I clearly did something. Oh well. How annoying! Fat binaries would make this work effortlessly. Disk space is waaaaay cheaper than my time.
Hmm... My wife's clamshell iBook worked right up until the day she put it away because she moved from Mac OS 9 to OS X. Our Blue & White Mac G3 is still going strong. Ok, we needed to replace the hard drive after 4 years, but that wasn't made by Apple. Oh, and the monitor died after 6 or 7 years. That's a pretty good run for a CRT anymore. The machine itself is 10 years old now.
What you're saying is that HD makers need HD porn and lots and lots of torrents to remain relevant, eh?
"Actually" works.