No more than the latency hit for a multi-socket system today when one CPU needs to access memory residing on the other CPU's memory controller. That's the beauty of HyperTransport.
For the US the saying was "television is the opiate of the masses" - it's very likely that bringing good mass communication to everyone will help quell their bickering. Either thru education, getting people to see each other and their place in the rest of the world, or just feeding them mind-numbing videos via Youtube.
Actually Sunbird is the standalone calendar app. Support for the Suite's Calendar Extension was officially dropped a long time ago. I've put together a working build of it (http://highlandsun.com/hyc/mozilla/) but there's no official recognition of any of my work by either the Calendar or the Seamonkey teams. (And obviously, since I still use the Calendar Extension every day, I think it's a useful item that should never have been dropped. But hey, I'm just one of the thousands of volunteer Mozilla developers with no say in anything. Strange that there's thousands of developers but not enough manpower to maintain a few extra build rules. Life is short, where does all the time go...)
The other benefit I'm looking forward to is that flash disks will most likely become 8x faster in the near term. Since they tend to be constructed with 512 byte sectors, it'll make sense to use 8 of them in parallel to get the 4K sector size. (Somewhere down the line they may decide to just increase the flash sector sizes, but they don't actually need to just yet...)
How generous you are, giving away your ignorance so freely.
The vast majority of people with computers on their desktops are using paging all the time. Even in Windows, when you turn off the paging file, executables are still demand-paged into memory instead of being loaded in all at once.
Yes, and... synthesis is the harder problem. In general, my experience has been "when you can do anything at all, you often stop and do nothing at all." Too much freedom brings paralysis, because you don't know what choice to make. Again, that's synthesis, creating your own agenda from zero, when you have no constraints and no direction laid out already. Being called in to fight a fire is easy, because you know the starting condition and the end goal. Looking at a well-runningsteady state environment and finding ways to improve it is hard, really hard. That's why they say "if it ain't broke don't fix it" because more often than not, you break it. It takes a really rare insight to actually improve a working system, and most people just don't get them; most people can't do real synthesis.
Agreed. I transcribed a 1992 SAE paper on the design of the engine in my car (Mazda KL) into HTML (by hand) and published it on my web site. I got a polite take-down letter from them, and I complied. (Point to note - my document is technically a derived work. It is not a photocopy or other facsimile of the original document, it is a manual translation of the original document into a new language (HTML). In that respect, given that I made several esthetic choices in my translation, it's a creative work in its own right and I own the copyright of my HTML document, even though the bulk of the content is SAE's.) Then I inquired into how much a license would cost to allow me to repost the paper. They considered it distribution and wanted to charge me $150 for each web hit to that page, in addition to a base license fee of several hundred dollars. Needless to say, I declined to get the license and the document is no longer available on my web site.
The thing is, this paper is about an engine that's no longer used in any currently produced car. As such, the technology described in it has no commercial value. It's only of interest to the small handful of car fanatics left who still own one of these cars (Ford Probe GT, Mazda 626/MX6) and none of us are pushing any commercial interest either, it's purely for education and personal enlightenment. If we were all students at an engineering university we could distribute copies freely to each other, but because we are out in the real world, they don't seem to consider it educational usage. Despite the fact that it has no other practical usage...
This kind of stuff is just a shade away from the guild system of old, where everything was jealously guarded as a trade secret. Once again people fail to see that Intellect is what matters, not Intellectual Property. IP is intrinsically worthless. If you hand it to someone who cannot comprehend it or cannot implement it, you haven't given away anything at all, you haven't lost anything and you haven't created anything. The only thing of real value in this context is the people who create the ideas, who have the know-how to turn ideas into reality. Ideas are a dime-a-dozen. Less than that...
There are 4 bases, yes, but they can only form in specific pairs. Adenine can only pair with Thymine, and Cytosine can only pair with Guanine. So there's really only two values. In other words, the two possible base pairs can be represented as the two possible values of a binary digit - a bit. Instead of using 4 colors to represent the DNA, only two are actually needed, assuming you use one base-pair per pixel. But really, looking at a 100 million bit long bitstring as individual bits is pretty stupid.
Nobody analyzes machine code in binary, we cluster the bits together and represent them as hex or octal digits. The right way to assemble this data, for the purposes of visualization and pattern recognition, would be to cluster the bits together, so you could reduce the total pixel count to something viewable all at once on an available display. Going to a full 24 or 32 bits per pixel would be self-defeating, because you'd be at or beyond the human eye's shading resolution. You want to condense the data enough to make it displayable, but not so much that the gradations in data are no longer discernable. 8 or 16 bits per pixel would be the goal. Then instead of needing a 200 megapixel display, you only need a 1 megapixel display, which is well within most people's reach.
Given the amount of energy received back from a space probe beyond the edge of the solar system, I believe the distinction you're making doesn't exist. I.e, we're getting data rates of 10 or so bits per second, because we're only getting 6 or 7 detectable photons per second.
We're already beyond one bit per photon for communicating with space probes at the edge of the solar system; 1.5 bits per photon (statistical) last I knew, 13 years ago. The breakthrough in this story isn't about encoding the data on a photon, it's about buffering it without degrading it.
I.e., we're already quite adept at *transmitting* data with photons in realtime. The problem is non-realtime storage/access.
For a different example, when I worked at JPL a decade or so ago the transmissions they got from Voyager and other probes through the Deep Space Network were getting a data rate of about 1.5 bits per photon. I wonder how much their encoding algorithms have improved since then.
The corollary is that we should start transitioning to more DC appliances. LED lighting is pretty efficient, but inconvenient right now because you need an AC to DC downconverter...
No, because most researchers today have specialized so much in their studies that they pretty much have tunnel vision. It practically takes an Act of God (note the irony) to get these people to look up and take note of what other people in other fields have discovered.
There are many fundamental differences. In optical photography your image resolution depends on a number of variables including the focal length of your lens and the distance to your target. It also depends on the surface area of your imaging surface (film, CCD, whatever). The image you record is exactly due to the photons striking your 2-dimensional imaging surface. It works based on the particle nature of photons.
In synthetic aperture radar you have a one-dimensional antenna. There is no lens or focusing mechanism. It works based on the wave nature of photons. The two-dimensional image is constructed mathematically (that's the Synthetic Aperture). One of the consequences of the math used in SAR is that the distance to the target cancels out, and so image resolution depends solely on the size of the antenna. You can't do that with optics...
I used to work in the JPL Radar Group, the same folks who processed the Magellan data. My project mapped the Earth using SAR, from the Space Shuttle. Our project (SIR-C) used 3 wavelengths of radar, with three corresponding characteristics of penetration. So we could map treetop foliage, ground level, and sub-surface. Magellan only had a surface mapper.
Gawd. Hack 1.0.2 was one of the first programs I dissected when I was learning C. I contributed a bunch of bug fixes and enhancements that went into Hack 1.0.3 and 1.0.4. This was 1985 or 1986... I remember struggling with getting the executable to fit into 640K on a PC, and being so relieved to have my 1MB Atari 1040 ST to play it on.
One of the things I worked on was splitting the UI into a separate module, with a simple protocol in between. So you could run the main game as a server and connect with curses or graphical UIs depending on preference. Unfortunately having worked on so much of the code started to take the fun out of playing it for me; I knew all the secrets already. Haven't thought about it much in recent years.
Expanding your post... they're fairly specifically holding up a single piece of software in the aerospace industry, as the cream of the crop, and comparing it to everything else. That's what we call an outlier, skewing the results. A good analysis discards outliers and uses what's left. We already know that the "average quality" of the OSS projects is high; without that outlier it's probably no contest. (Just guessing, not having seen their closed-source data.)
The other thing that's obviously intentionally slanted here - many of the OSS projects on their list show zero bugs per 1000 lines. Obviously we can't do better than zero bugs, so saying "no open-source project we analyzed had fewer software defects (per thousand lines of code) than the top-of-the-line closed-source application" is pure spin.
We can just as easily say "15 of the top 60 OSS projects have zero bugs, but only *one* of the closed source projects could match that." Ultimately the numbers here are meaningless, so it's best to just not play this game.
What would be more interesting to me is a metric of time-to-solution, after a bug has been reported. The current coverity scan isn't set up to measure that accurately, because it doesn't notify anyone on the project when a scan completes and finds any bugs. So unless you check their web site very frequently, you won't know what it found.
I think 50 cents is massively underestimating, just like $70K is massively overestimating. The most efficient off-the-shelf LiIon cell available today comes in the 18650 form factor. You can get these retail for $6.00 each, which should mean they can get them direct from the manufacturer for around $1.50 - $2.00 each. (E.g., http://www.sabahoceanic.com/detail.aspx?ID=750 I've ordered from these guys several times to rebuild packs for my 3 laptops...)
That means almost $13,000 worth of batteries that need to be replaced every 3 years or so. If a car company is buying these in bulk to put into cars, I would expect the entire pack to sell for less than the retail cost of the individual cells, but obviously it'll be more than $13,000. Prices will continue to drop over time.
I'm not sure I'd want to budget $4K/year for battery replacement, but if other maintenance cost is reduced or eliminated, it may balance out in the end.
The AIX linker is fairly intelligent, and its object file format preserves function boundaries so that the distribution of functions over object files is largely irrelevant. (Contrast this with the typical dumb Unix linker that includes an entire object file if any symbol inside it is referenced; the AIX linker only includes the actual referenced symbols, not the entire object file.)
The MIPS toolchain was pretty smart along these lines too. I also developed M68K tools for gcc on the Atari ST that did the same thing, to allow globally optimizing address references to use (base register)+16 bit offset addressing modes wherever possible (which offered about a 10% speedup overall vs 32bit absolute addressing in most programs, as well as more compact code. It also allowed shared-text without needing an MMU, which was very handy...). All this was in the late 80s - early 90s. A lot of these ideas didn't get much traction in x86 land because the architecture was so abysmally bad that the space/performance payoff was in the noise. Oh well.
And my Lisp professor was always harping on "Lisp is not slow" in my college days, trotting out the multi-precision arithmetic support and such as ready examples to prove his point. Granted, getting pi to 100 digits faster than my HP41CV was impressive by human standards, but that in no way proved that Lisp in general was slower than C or some other language.
OOO has nothing to do with that; the processor still has to provide the appearance of in-order execution. A sufficiently skilled and fanatical human can hand-write assembler that executes faster than any compiler. It's just a tradeoff of human productivity, there's probably better things to do with that human's time.
Because a direct thought-to-text translator requires that your thought-receiver directly interfaces to whatever system you're working with. If the interface is unavailable, you lose. On the other hand (har har) controlling an artificial limb means you can use all of the existing keyboards and other interfaces, no new special interface required.
Well, if all cars on the road were automated, it's very likely that you could prevent jams from occurring in the first place. Most of the slowdowns I've observed tend to be caused by inattentive drivers, remove them from the equation and traffic flow will be smooth all the time.
I enjoy being in control of my car too, but I think I'd be willing to give it up when I got onto a freeway if I knew all the vehicles around me would be driving consistently and intelligently. Just as long as I can still switch over to full manual for weekend outings at the track.
Slashdot Mirror
No more than the latency hit for a multi-socket system today when one CPU needs to access memory residing on the other CPU's memory controller. That's the beauty of HyperTransport.
= 28&threadid=34279
Of course I asked AMD for this 2 and a half years ago. Nice to see it's finally come to life.
http://forums.amd.com/forum/messageview.cfm?catid
They didn't need to wait for HT 3.0 to release this, it would have worked perfectly well back then.
Pretty good guess.
p ics/topic02.pdf
http://wps.aw.com/wps/media/objects/877/898586/to
22hp @ 67mph for a reasonably aerodynamic sports car (Porsche Carrera,drag coefficient 0.35. My car has a drag coefficient of 0.31...).
Don't worry. You'd probably just wind up in the Land of the Giants if you went...
For the US the saying was "television is the opiate of the masses" - it's very likely that bringing good mass communication to everyone will help quell their bickering. Either thru education, getting people to see each other and their place in the rest of the world, or just feeding them mind-numbing videos via Youtube.
Actually Sunbird is the standalone calendar app. Support for the Suite's Calendar Extension was officially dropped a long time ago. I've put together a working build of it (http://highlandsun.com/hyc/mozilla/) but there's no official recognition of any of my work by either the Calendar or the Seamonkey teams. (And obviously, since I still use the Calendar Extension every day, I think it's a useful item that should never have been dropped. But hey, I'm just one of the thousands of volunteer Mozilla developers with no say in anything. Strange that there's thousands of developers but not enough manpower to maintain a few extra build rules. Life is short, where does all the time go...)
The other benefit I'm looking forward to is that flash disks will most likely become 8x faster in the near term. Since they tend to be constructed with 512 byte sectors, it'll make sense to use 8 of them in parallel to get the 4K sector size. (Somewhere down the line they may decide to just increase the flash sector sizes, but they don't actually need to just yet...)
How generous you are, giving away your ignorance so freely.
The vast majority of people with computers on their desktops are using paging all the time. Even in Windows, when you turn off the paging file, executables are still demand-paged into memory instead of being loaded in all at once.
Yes, and ... synthesis is the harder problem. In general, my experience has been "when you can do anything at all, you often stop and do nothing at all." Too much freedom brings paralysis, because you don't know what choice to make. Again, that's synthesis, creating your own agenda from zero, when you have no constraints and no direction laid out already. Being called in to fight a fire is easy, because you know the starting condition and the end goal. Looking at a well-runningsteady state environment and finding ways to improve it is hard, really hard. That's why they say "if it ain't broke don't fix it" because more often than not, you break it. It takes a really rare insight to actually improve a working system, and most people just don't get them; most people can't do real synthesis.
Agreed. I transcribed a 1992 SAE paper on the design of the engine in my car (Mazda KL) into HTML (by hand) and published it on my web site. I got a polite take-down letter from them, and I complied. (Point to note - my document is technically a derived work. It is not a photocopy or other facsimile of the original document, it is a manual translation of the original document into a new language (HTML). In that respect, given that I made several esthetic choices in my translation, it's a creative work in its own right and I own the copyright of my HTML document, even though the bulk of the content is SAE's.) Then I inquired into how much a license would cost to allow me to repost the paper. They considered it distribution and wanted to charge me $150 for each web hit to that page, in addition to a base license fee of several hundred dollars. Needless to say, I declined to get the license and the document is no longer available on my web site.
The thing is, this paper is about an engine that's no longer used in any currently produced car. As such, the technology described in it has no commercial value. It's only of interest to the small handful of car fanatics left who still own one of these cars (Ford Probe GT, Mazda 626/MX6) and none of us are pushing any commercial interest either, it's purely for education and personal enlightenment. If we were all students at an engineering university we could distribute copies freely to each other, but because we are out in the real world, they don't seem to consider it educational usage. Despite the fact that it has no other practical usage...
This kind of stuff is just a shade away from the guild system of old, where everything was jealously guarded as a trade secret. Once again people fail to see that Intellect is what matters, not Intellectual Property. IP is intrinsically worthless. If you hand it to someone who cannot comprehend it or cannot implement it, you haven't given away anything at all, you haven't lost anything and you haven't created anything. The only thing of real value in this context is the people who create the ideas, who have the know-how to turn ideas into reality. Ideas are a dime-a-dozen. Less than that...
Agreed it's lame, but not just for those reasons.
There are 4 bases, yes, but they can only form in specific pairs. Adenine can only pair with Thymine, and Cytosine can only pair with Guanine. So there's really only two values. In other words, the two possible base pairs can be represented as the two possible values of a binary digit - a bit. Instead of using 4 colors to represent the DNA, only two are actually needed, assuming you use one base-pair per pixel. But really, looking at a 100 million bit long bitstring as individual bits is pretty stupid.
Nobody analyzes machine code in binary, we cluster the bits together and represent them as hex or octal digits. The right way to assemble this data, for the purposes of visualization and pattern recognition, would be to cluster the bits together, so you could reduce the total pixel count to something viewable all at once on an available display. Going to a full 24 or 32 bits per pixel would be self-defeating, because you'd be at or beyond the human eye's shading resolution. You want to condense the data enough to make it displayable, but not so much that the gradations in data are no longer discernable. 8 or 16 bits per pixel would be the goal. Then instead of needing a 200 megapixel display, you only need a 1 megapixel display, which is well within most people's reach.
Given the amount of energy received back from a space probe beyond the edge of the solar system, I believe the distinction you're making doesn't exist. I.e, we're getting data rates of 10 or so bits per second, because we're only getting 6 or 7 detectable photons per second.
We're already beyond one bit per photon for communicating with space probes at the edge of the solar system; 1.5 bits per photon (statistical) last I knew, 13 years ago. The breakthrough in this story isn't about encoding the data on a photon, it's about buffering it without degrading it.
I.e., we're already quite adept at *transmitting* data with photons in realtime. The problem is non-realtime storage/access.
Ah yes, that pesky ol' signal to noise ratio.
For a different example, when I worked at JPL a decade or so ago the transmissions they got from Voyager and other probes through the Deep Space Network were getting a data rate of about 1.5 bits per photon. I wonder how much their encoding algorithms have improved since then.
The corollary is that we should start transitioning to more DC appliances. LED lighting is pretty efficient, but inconvenient right now because you need an AC to DC downconverter...
No, because most researchers today have specialized so much in their studies that they pretty much have tunnel vision. It practically takes an Act of God (note the irony) to get these people to look up and take note of what other people in other fields have discovered.
There are many fundamental differences. In optical photography your image resolution depends on a number of variables including the focal length of your lens and the distance to your target. It also depends on the surface area of your imaging surface (film, CCD, whatever). The image you record is exactly due to the photons striking your 2-dimensional imaging surface. It works based on the particle nature of photons.
In synthetic aperture radar you have a one-dimensional antenna. There is no lens or focusing mechanism. It works based on the wave nature of photons. The two-dimensional image is constructed mathematically (that's the Synthetic Aperture). One of the consequences of the math used in SAR is that the distance to the target cancels out, and so image resolution depends solely on the size of the antenna. You can't do that with optics...
I used to work in the JPL Radar Group, the same folks who processed the Magellan data. My project mapped the Earth using SAR, from the Space Shuttle. Our project (SIR-C) used 3 wavelengths of radar, with three corresponding characteristics of penetration. So we could map treetop foliage, ground level, and sub-surface. Magellan only had a surface mapper.
Gawd. Hack 1.0.2 was one of the first programs I dissected when I was learning C. I contributed a bunch of bug fixes and enhancements that went into Hack 1.0.3 and 1.0.4. This was 1985 or 1986... I remember struggling with getting the executable to fit into 640K on a PC, and being so relieved to have my 1MB Atari 1040 ST to play it on.
One of the things I worked on was splitting the UI into a separate module, with a simple protocol in between. So you could run the main game as a server and connect with curses or graphical UIs depending on preference. Unfortunately having worked on so much of the code started to take the fun out of playing it for me; I knew all the secrets already. Haven't thought about it much in recent years.
Expanding your post... they're fairly specifically holding up a single piece of software in the aerospace industry, as the cream of the crop, and comparing it to everything else. That's what we call an outlier, skewing the results. A good analysis discards outliers and uses what's left. We already know that the "average quality" of the OSS projects is high; without that outlier it's probably no contest. (Just guessing, not having seen their closed-source data.)
The other thing that's obviously intentionally slanted here - many of the OSS projects on their list show zero bugs per 1000 lines. Obviously we can't do better than zero bugs, so saying "no open-source project we analyzed had fewer software defects (per thousand lines of code) than the top-of-the-line closed-source application" is pure spin.
We can just as easily say "15 of the top 60 OSS projects have zero bugs, but only *one* of the closed source projects could match that." Ultimately the numbers here are meaningless, so it's best to just not play this game.
What would be more interesting to me is a metric of time-to-solution, after a bug has been reported. The current coverity scan isn't set up to measure that accurately, because it doesn't notify anyone on the project when a scan completes and finds any bugs. So unless you check their web site very frequently, you won't know what it found.
$13K to replace a full set, average of once every 3 years replacement, spread out to about $4K/year. Duh...
I think 50 cents is massively underestimating, just like $70K is massively overestimating. The most efficient off-the-shelf LiIon cell available today comes in the 18650 form factor. You can get these retail for $6.00 each, which should mean they can get them direct from the manufacturer for around $1.50 - $2.00 each. (E.g., http://www.sabahoceanic.com/detail.aspx?ID=750 I've ordered from these guys several times to rebuild packs for my 3 laptops...)
That means almost $13,000 worth of batteries that need to be replaced every 3 years or so. If a car company is buying these in bulk to put into cars, I would expect the entire pack to sell for less than the retail cost of the individual cells, but obviously it'll be more than $13,000. Prices will continue to drop over time.
I'm not sure I'd want to budget $4K/year for battery replacement, but if other maintenance cost is reduced or eliminated, it may balance out in the end.
The AIX linker is fairly intelligent, and its object file format preserves function boundaries so that the distribution of functions over object files is largely irrelevant. (Contrast this with the typical dumb Unix linker that includes an entire object file if any symbol inside it is referenced; the AIX linker only includes the actual referenced symbols, not the entire object file.)
The MIPS toolchain was pretty smart along these lines too. I also developed M68K tools for gcc on the Atari ST that did the same thing, to allow globally optimizing address references to use (base register)+16 bit offset addressing modes wherever possible (which offered about a 10% speedup overall vs 32bit absolute addressing in most programs, as well as more compact code. It also allowed shared-text without needing an MMU, which was very handy...). All this was in the late 80s - early 90s. A lot of these ideas didn't get much traction in x86 land because the architecture was so abysmally bad that the space/performance payoff was in the noise. Oh well.
And my Lisp professor was always harping on "Lisp is not slow" in my college days, trotting out the multi-precision arithmetic support and such as ready examples to prove his point. Granted, getting pi to 100 digits faster than my HP41CV was impressive by human standards, but that in no way proved that Lisp in general was slower than C or some other language.
OOO has nothing to do with that; the processor still has to provide the appearance of in-order execution. A sufficiently skilled and fanatical human can hand-write assembler that executes faster than any compiler. It's just a tradeoff of human productivity, there's probably better things to do with that human's time.
Because a direct thought-to-text translator requires that your thought-receiver directly interfaces to whatever system you're working with. If the interface is unavailable, you lose. On the other hand (har har) controlling an artificial limb means you can use all of the existing keyboards and other interfaces, no new special interface required.
Well, if all cars on the road were automated, it's very likely that you could prevent jams from occurring in the first place. Most of the slowdowns I've observed tend to be caused by inattentive drivers, remove them from the equation and traffic flow will be smooth all the time.
I enjoy being in control of my car too, but I think I'd be willing to give it up when I got onto a freeway if I knew all the vehicles around me would be driving consistently and intelligently. Just as long as I can still switch over to full manual for weekend outings at the track.