Why hasn't it advanced much compared to just about every other technology in a laptop
Because the marketplace is not dominated by the low-weight/small crowd. The marketplace wants cheap, powerful and reasonably luggable. If the market cared as much about weight and size as you do, Transmeta would have actual hope.
Let's see... Your compelling reason for Space exploration is to discover and provide warning of biblical size impact events. To whom do you suppose the bill should be sent?
This isn't a flame. If a workable business model exists it could actually happen. Without this, however, it's hand waving. Perhaps the "global conscience" should be above such matters but it's not.
"But I guess actually helping your fellow humans is less glamourous then being the first nerd or geek to discover some faint signal which when discovered probably won't even be accepted by the rest of the world and will be debated forever."
It "glamorous" you silly twitch.
Stick your fucking guilt trip in your ear. My fellow humans get more than enough "help" already. With what is left over, we're doing as we see fit. Don't like it? Allow me to bend over so you can plant a juicy wet one on my left cheek. Enjoy.
Good question. Whatever the consequences, bring it on. Yeah, we'll probably see new religions appear. They'll be radical cult like messes that contribute nothing. Our existing religions will adapt, because they're good at it, or they wouldn't still exist.
Bring it on. I've got about 30 worthwhile years left in me. I have no intention of allowing the fools of this planet to keep me ignorant. Lets have at it.
This "getting use out of your hardware and software" is pretty common in municipal systems. I saw genuine Sperry terminals in use by clerks processing election returns in Fort Collins, CO three years back. That would be Sperry equipment manufactured prior to the Sperry + Burroughs = Unisys merger, circa 1986. No telling when it was purchased originally, but figuring in a couple years prior to the merger and the possibility that they're still in use, you're going on two decades!
The difference between win95 and XP is cause for a retrain all by itself. Remember, these are municipal governement employees. Mostly clerks. Most of them don't know what version of Microsoft's bootloader their running and won't care they've been switched to something else.
One friend who still works at NASA complains about increasingly bureaucratic management getting in the way.
Bureaucracy can keep metric and english from getting confused. Bureaucracy can prevent priority inversions inside the tiny kernels of remotely piloted vehicles. More bureaucracy might have gotten the lens ground right. It took a LOT of bureaucrats to organize the fix for that one.
Does "flexible" include ignoring launch parameters and blowing up manned vehicles? I watched that happen. Fuck flexible.
I'm not sure how fine the granularity is on the cache.
The granularity of a cache is called a "cache line". It varies by CPU model.
The cache would have to hold 10k of code, but that's still a small portion of a 500k cache.
The concept you're circling around is called the "working set". The size of this dictates the amount of cache CPU manufacturers create. Your figures are quite low. There are individual function calls in the Linux kernel that account for 2k of memory, including stack. Windows is no different. Some of these are called hundreds of thousands of times a second. VM and scheduler functions come to mind. If these fall out of the cache performance falls a order of magnitude.
Further, cache lines are fixed in size. Your example of 2k bits of code loaded redundantly into 5 separate lines would actually consume 40KB of a cache that has 8K lines. See? Almost 10% of your cache gone for one 2k function. Double plus ungood.
Typical "desktop" Intel chips are coming with 512KB of L1 cache. Less in low-power "portable" variants (cache is very power hungry.) More in "pro" models. It is quite easy to create a working set larger than 512K. 5-6 typical GUI programs is all you need. Remember that this includes data in addition to code. Data includes things like the stack. This is why stopping unneeded background processes makes a noticeable difference, even though they aren't large enough to cause swap.
OTOH, if caches are only capable of pulling in large blocks, they could only pull in one dynamic at a time anyway. The others would miss every time the task switched.
The units a cache maintains do no correspond to units of executable code such as DLLs. Most of the code in any given shared library gets into the cache for only a few microseconds.
If I turn off my cache, I won't simulate static linking--I'll just simulate... umm... not having a cache.
If you compile an entire system static and then try to multitask more than a very small number of processes you will effectively have no cache. A bone stock W2K box starts >20 background jobs on boot. Never mind what you want to run. You think all that stuff can be redundantly loaded and still have the working set fit in 512K of cache?? Think again.
Workstation class CPUs typically have 1-4MB of L1 cache. This is why a 500MHz SPARC is competitive with Intel CPUs running two more times faster in cycles. More recent RISC CPUs (PA-RISC comes to mind) are appearing with 8-16MB of L1. Cache is everything.
On one hand, RISC CPUs with smaller, simpler instructions use cache less efficiently than CISC designs due to needing a larger number instructions to get the same result. On the other, Intel's CISC design has a very small register file, requiring more stack, and therefore more cache. Cache is king.
Managing cpu cache consumes enormous efforts of system programmers. Go spend some time on the LKML reading about what system programmers think about. About half the time it's cache, cache, cache. All system programmers do the same.
Before we chuck out our dreams, perhaps we should consider changing the current approach to the problems
I don't wish for anyone to chuck out their dreams. I'd just like some of the anti-NASA zealots to put their dreams into perspective. The common Joe is convinced that NASA is a farce of waste and mismanagement. This isn't the case, but the perception gives leverage to forces that oppose NASA and, by extension, institutional exploration altogether.
There are two groups of anti-NASA. The first group hates NASA because they harbor vague notions about how to do it "right." They believe NASA, with it's big budget programs such as the Space Shuttle, is the reason that progress is slow. The second group hates NASA because NASA consumes resources that they would rather have for other, mostly "social", agendas. The problem is that when the first group sounds off, they give ammunition to the second group. I don't like this because I believe progress is slow because the task is hard, not because NASA sucks, and NASA doesn't need either group ankle-bitting it, much less both. Destroying NASA isn't going to create a better NASA, it's just going to get more food stamps bought.
Next year Cassini will reach Saturn. It will drop a probe onto the surface of Titan. We will learn more about Saturn than has ever been known. That which we learn will constitute the domain of knowledge about Saturn that anyone reading this will ever have the opportunity to know prior to death. Cassini is considered an old-fashioned "big budget" mission according to contemporary anti-NASA zealot thinking. Will there be more? God forbid!
Want something to dream of that you have a rational basis for suspecting may be feasible in your lifetime? Here are mine; detecting extra-terrestrial intelligent life and creating machine based non-human intelligence. The first is a matter of fate and possibly some luck. The second I consider an inevitability and I'm only left to wonder about timing. I too have my dreams. I just try a little harder to keep reality in perspective. The physics involved in space exploration precludes most of what our imaginations are capable of. This isn't NASA's fault so I figure it's best not to blame them for it.
Where have you been ? I've been using 1000BaseTX ethernet for over a year. Right now I would only buy a machine with a GigE port. The switches are still a little pricey but they will come down.
Well la-de-da. You have been using 1000BaseT for over a year. You do realize that is 10 times slower than what the poster suggested using, correct? That happened to be my point.
100BaseT is the common medium today. While you may be on the cutting edge, the vast majority of build-outs in recent times is 100BaseT. Typical build-outs are still not specced for 1Gb operation at this time. Perhaps your misconception is due to a narrow view of your personal collection of gear and lacks actual experience in contemporary infrastructure specs?
10GBASE was ratified about 180 days ago. I can forgive the storage industry for not having faith! You can expect to wait a couple years before 10GBASE switches appear in the pipeline from vendors that matter. You can further expect that adopting such hardware will be risky and troublesome for a couple years after that. The Catalyst 6500 family of Cisco hardware doesn't do 10GBASE, and this is about as good as you'll find in typical corporate network cores. Probably not a feasible SCSI bus.
Amen. Put that in your NASA/Military Industrial Complex conspiracy pipe and smoke it. The Universe has no compelling reason to cater to whims and dreams of mortals. There is no "grass roots" road to space. Get over it.
Plainly, dynamic libraries are a holdover from the days when memory costs and address-space limits were something to think about.
Sorry, this is badly naive. The value of shared executable memory (a.k.a dynamic libraries) is still quite high.
As we know, our CPUs can usually outrun the ability of our RAM to keep the pipeline full with new code and data to process. An extremely effective way to cope with this is by providing the CPU with various forms of cache. The cache is of limited size, however, because it is very costly and power hungry.
Sharing executable RAM allows the bulk of CPU activity to remain within the limits of the cache. Eliminating shared executable RAM breaks this. If N processes are all busy waiting for mouse events or writing a network socket they will all spend the majority of their time in the same small bit of machine code nicely packed into the CPU cache. By not having code present in RAM redundantly due to lack of sharing, we avoid cache blowouts.
When a CPU suffers a cache miss the cost in cycles is enormous. As time passes we see that CPU performance is increasing faster than RAM performance. As the trend continues it will only become more important that software respect the CPU cache.
If you want know what the performance of a system would be like with everything compiled static and all dynamic loading (and thus, sharing) removed, just reboot into your BIOS configuration and turn off your cache. I promise, you WILL notice.
Shared executables are important now for the same reason they have always been important; the fast part of the computer is a costly, limited resource. You can see the importance of cache in modern computing with a little effort at PriceWatch. The cost of a CPU is directly proportional to it's cache size.
People haven't been putting up with the difficulties of shared executables for the past 3-4 decades because they're morons.
"During the previous article I made a call for peace. I suggested that it was too early to condemn SCO for they had done nothing vicious, and we had no way to tell precisely what was planned."
We need to give the inspectors more time. War is wrong. Bush just wants the oil.
I think I've seen this at work many years ago. I remember watching an array being operated by Novell 4.something. No matter what time of day or night (which dramatically varied the load) the lights on the array would pulse simultaneously about once per second. I surmised that the OS was caching writes in RAM and flushing the data to storage asynchronously according to it's scheduler.
One thing (the only thing afaict) about Novell; I don't know of any other OS that could provide multiple filesystem mounts to hundreds of PCs from a 386 with 128MB of RAM. Novell did this routinely.
There is nothing "just" about LEDs. They can be big. Very big. They can have a hotshot geek with a lens to focus their bigness. Before you know it, some twit has enough focused light to replace his 802.11 rig operating at 20+ miles.
"5. Something like "OpenBIOS" or Sun's OpenBoot (I think that's the name? Been a while, I forgot). This is great to work with, for instance, on Alpha systems. Fairly complete diagnostics before the OS even boots, and it all gets shucked out the serial port. You can compensate for this by installing some kind of lights-out management board in your PC, but if you ask any UNIX admin that has used the non-PC-BIOS stuff on pro UNIX systems, a PC BIOS just doesn't compare. For instance, on the Alpha I have at home, I can hook up fibre channel and enumerate all"
Intel actually makes nice system boards that can do this. The whole BIOS config may be run though a serial port. They don't cost much more than regular peecee boards either. They call it "console redirection" and/or "serial over lan" and it's built in to most of their "server" boards. On the low end you can get Intel STL-2 or SCB2 boards that have this. Check it out:
Slashdot Mirror
Why hasn't it advanced much compared to just about every other technology in a laptop
Because the marketplace is not dominated by the low-weight/small crowd. The marketplace wants cheap, powerful and reasonably luggable. If the market cared as much about weight and size as you do, Transmeta would have actual hope.
Honestly, I've often thought that the Universe was in a donut shape. However, the question still remains: what the hell's outside of it?
Nothing. Reality ends there. There is no outside.
Bush did something that pleases /. Will wonders never cease?
This scores points with the prols. I'd have advised The Evil One to postpone signing until just before the '04 elections.
Let's see... Your compelling reason for Space exploration is to discover and provide warning of biblical size impact events. To whom do you suppose the bill should be sent?
This isn't a flame. If a workable business model exists it could actually happen. Without this, however, it's hand waving. Perhaps the "global conscience" should be above such matters but it's not.
Go ask about unnecessary wars in a NY fire station. Please.
It "glamorous" you silly twitch.
Stick your fucking guilt trip in your ear. My fellow humans get more than enough "help" already. With what is left over, we're doing as we see fit. Don't like it? Allow me to bend over so you can plant a juicy wet one on my left cheek. Enjoy.
"Now what?"
Good question. Whatever the consequences, bring it on. Yeah, we'll probably see new religions appear. They'll be radical cult like messes that contribute nothing. Our existing religions will adapt, because they're good at it, or they wouldn't still exist.
Bring it on. I've got about 30 worthwhile years left in me. I have no intention of allowing the fools of this planet to keep me ignorant. Lets have at it.
Thanks.
This "getting use out of your hardware and software" is pretty common in municipal systems. I saw genuine Sperry terminals in use by clerks processing election returns in Fort Collins, CO three years back. That would be Sperry equipment manufactured prior to the Sperry + Burroughs = Unisys merger, circa 1986. No telling when it was purchased originally, but figuring in a couple years prior to the merger and the possibility that they're still in use, you're going on two decades!
The difference between win95 and XP is cause for a retrain all by itself. Remember, these are municipal governement employees. Mostly clerks. Most of them don't know what version of Microsoft's bootloader their running and won't care they've been switched to something else.
One friend who still works at NASA complains about increasingly bureaucratic management getting in the way.
Bureaucracy can keep metric and english from getting confused. Bureaucracy can prevent priority inversions inside the tiny kernels of remotely piloted vehicles. More bureaucracy might have gotten the lens ground right. It took a LOT of bureaucrats to organize the fix for that one.
Does "flexible" include ignoring launch parameters and blowing up manned vehicles? I watched that happen. Fuck flexible.
The hacker ethos does not apply to Space. Period.
I'm not sure how fine the granularity is on the cache.
The granularity of a cache is called a "cache line". It varies by CPU model.
The cache would have to hold 10k of code, but that's still a small portion of a 500k cache.
The concept you're circling around is called the "working set". The size of this dictates the amount of cache CPU manufacturers create. Your figures are quite low. There are individual function calls in the Linux kernel that account for 2k of memory, including stack. Windows is no different. Some of these are called hundreds of thousands of times a second. VM and scheduler functions come to mind. If these fall out of the cache performance falls a order of magnitude.
Further, cache lines are fixed in size. Your example of 2k bits of code loaded redundantly into 5 separate lines would actually consume 40KB of a cache that has 8K lines. See? Almost 10% of your cache gone for one 2k function. Double plus ungood.
Typical "desktop" Intel chips are coming with 512KB of L1 cache. Less in low-power "portable" variants (cache is very power hungry.) More in "pro" models. It is quite easy to create a working set larger than 512K. 5-6 typical GUI programs is all you need. Remember that this includes data in addition to code. Data includes things like the stack. This is why stopping unneeded background processes makes a noticeable difference, even though they aren't large enough to cause swap.
OTOH, if caches are only capable of pulling in large blocks, they could only pull in one dynamic at a time anyway. The others would miss every time the task switched.
The units a cache maintains do no correspond to units of executable code such as DLLs. Most of the code in any given shared library gets into the cache for only a few microseconds.
If I turn off my cache, I won't simulate static linking--I'll just simulate... umm... not having a cache.
If you compile an entire system static and then try to multitask more than a very small number of processes you will effectively have no cache. A bone stock W2K box starts >20 background jobs on boot. Never mind what you want to run. You think all that stuff can be redundantly loaded and still have the working set fit in 512K of cache?? Think again.
Workstation class CPUs typically have 1-4MB of L1 cache. This is why a 500MHz SPARC is competitive with Intel CPUs running two more times faster in cycles. More recent RISC CPUs (PA-RISC comes to mind) are appearing with 8-16MB of L1. Cache is everything.
On one hand, RISC CPUs with smaller, simpler instructions use cache less efficiently than CISC designs due to needing a larger number instructions to get the same result. On the other, Intel's CISC design has a very small register file, requiring more stack, and therefore more cache. Cache is king.
Managing cpu cache consumes enormous efforts of system programmers. Go spend some time on the LKML reading about what system programmers think about. About half the time it's cache, cache, cache. All system programmers do the same.
Before we chuck out our dreams, perhaps we should consider changing the current approach to the problems
I don't wish for anyone to chuck out their dreams. I'd just like some of the anti-NASA zealots to put their dreams into perspective. The common Joe is convinced that NASA is a farce of waste and mismanagement. This isn't the case, but the perception gives leverage to forces that oppose NASA and, by extension, institutional exploration altogether.
There are two groups of anti-NASA. The first group hates NASA because they harbor vague notions about how to do it "right." They believe NASA, with it's big budget programs such as the Space Shuttle, is the reason that progress is slow. The second group hates NASA because NASA consumes resources that they would rather have for other, mostly "social", agendas. The problem is that when the first group sounds off, they give ammunition to the second group. I don't like this because I believe progress is slow because the task is hard, not because NASA sucks, and NASA doesn't need either group ankle-bitting it, much less both. Destroying NASA isn't going to create a better NASA, it's just going to get more food stamps bought.
Next year Cassini will reach Saturn. It will drop a probe onto the surface of Titan. We will learn more about Saturn than has ever been known. That which we learn will constitute the domain of knowledge about Saturn that anyone reading this will ever have the opportunity to know prior to death. Cassini is considered an old-fashioned "big budget" mission according to contemporary anti-NASA zealot thinking. Will there be more? God forbid!
Want something to dream of that you have a rational basis for suspecting may be feasible in your lifetime? Here are mine; detecting extra-terrestrial intelligent life and creating machine based non-human intelligence. The first is a matter of fate and possibly some luck. The second I consider an inevitability and I'm only left to wonder about timing. I too have my dreams. I just try a little harder to keep reality in perspective. The physics involved in space exploration precludes most of what our imaginations are capable of. This isn't NASA's fault so I figure it's best not to blame them for it.
Where have you been ? I've been using 1000BaseTX ethernet for over a year. Right now I would only buy a machine with a GigE port. The switches are still a little pricey but they will come down.
Well la-de-da. You have been using 1000BaseT for over a year. You do realize that is 10 times slower than what the poster suggested using, correct? That happened to be my point.
100BaseT is the common medium today. While you may be on the cutting edge, the vast majority of build-outs in recent times is 100BaseT. Typical build-outs are still not specced for 1Gb operation at this time. Perhaps your misconception is due to a narrow view of your personal collection of gear and lacks actual experience in contemporary infrastructure specs?
10GBASE was ratified about 180 days ago. I can forgive the storage industry for not having faith! You can expect to wait a couple years before 10GBASE switches appear in the pipeline from vendors that matter. You can further expect that adopting such hardware will be risky and troublesome for a couple years after that. The Catalyst 6500 family of Cisco hardware doesn't do 10GBASE, and this is about as good as you'll find in typical corporate network cores. Probably not a feasible SCSI bus.
Amen. Put that in your NASA/Military Industrial Complex conspiracy pipe and smoke it. The Universe has no compelling reason to cater to whims and dreams of mortals. There is no "grass roots" road to space. Get over it.
And how about 10Gbit Ethernet ? What's stopping you from using this as a drive interface ?
What 10Gbit Ethernet? Obsolete Ethernet is 10Mb. Typical current Ethernet is 100Mb. Up and coming 1Gb Ethernet is appearing.
10Gb?
Plainly, dynamic libraries are a holdover from the days when memory costs and address-space limits were something to think about.
Sorry, this is badly naive. The value of shared executable memory (a.k.a dynamic libraries) is still quite high.
As we know, our CPUs can usually outrun the ability of our RAM to keep the pipeline full with new code and data to process. An extremely effective way to cope with this is by providing the CPU with various forms of cache. The cache is of limited size, however, because it is very costly and power hungry.
Sharing executable RAM allows the bulk of CPU activity to remain within the limits of the cache. Eliminating shared executable RAM breaks this. If N processes are all busy waiting for mouse events or writing a network socket they will all spend the majority of their time in the same small bit of machine code nicely packed into the CPU cache. By not having code present in RAM redundantly due to lack of sharing, we avoid cache blowouts.
When a CPU suffers a cache miss the cost in cycles is enormous. As time passes we see that CPU performance is increasing faster than RAM performance. As the trend continues it will only become more important that software respect the CPU cache.
If you want know what the performance of a system would be like with everything compiled static and all dynamic loading (and thus, sharing) removed, just reboot into your BIOS configuration and turn off your cache. I promise, you WILL notice.
Shared executables are important now for the same reason they have always been important; the fast part of the computer is a costly, limited resource. You can see the importance of cache in modern computing with a little effort at PriceWatch. The cost of a CPU is directly proportional to it's cache size.
People haven't been putting up with the difficulties of shared executables for the past 3-4 decades because they're morons.
>> 8 way scalability.
:)
Um, where have you been. That's been there for a long time.
I said "greater than" 8 way... did the > get messed up? I'm too lazy to go look.
Eh... this isn't a "yank" movie is it? Are you certain yanks are responsible for the change?
"During the previous article I made a call for peace. I suggested that it was too early to condemn SCO for they had done nothing vicious, and we had no way to tell precisely what was planned."
We need to give the inspectors more time. War is wrong. Bush just wants the oil.
Oh... sorry. Wrong cause.
I think I've seen this at work many years ago. I remember watching an array being operated by Novell 4.something. No matter what time of day or night (which dramatically varied the load) the lights on the array would pulse simultaneously about once per second. I surmised that the OS was caching writes in RAM and flushing the data to storage asynchronously according to it's scheduler.
One thing (the only thing afaict) about Novell; I don't know of any other OS that could provide multiple filesystem mounts to hundreds of PCs from a 386 with 128MB of RAM. Novell did this routinely.
"File transfer failed: Code 75(flock of seagulls)"
EBIRD
It's just an LED.
There is nothing "just" about LEDs. They can be big. Very big. They can have a hotshot geek with a lens to focus their bigness. Before you know it, some twit has enough focused light to replace his 802.11 rig operating at 20+ miles.
Bet on it.
Nokia + T-Mobile. Excellent coverage in fly-over country. ...why am I not surprised to learn AT&T coverage sucks?
"5. Something like "OpenBIOS" or Sun's OpenBoot (I think that's the name? Been a while, I forgot). This is great to work with, for instance, on Alpha systems. Fairly complete diagnostics before the OS even boots, and it all gets shucked out the serial port. You can compensate for this by installing some kind of lights-out management board in your PC, but if you ask any UNIX admin that has used the non-PC-BIOS stuff on pro UNIX systems, a PC BIOS just doesn't compare. For instance, on the Alpha I have at home, I can hook up fibre channel and enumerate all"
s /b oards/server_management/index.htm
Intel actually makes nice system boards that can do this. The whole BIOS config may be run though a serial port. They don't cost much more than regular peecee boards either. They call it "console redirection" and/or "serial over lan" and it's built in to most of their "server" boards. On the low end you can get Intel STL-2 or SCB2 boards that have this. Check it out:
http://program.intel.com/shared/products/server