Demand paging with a unified buffer cache is a difficult concept for laymen to grasp. They tend to think of memory being a finite resource that is used up, rather than simply another caching layer for permanent storage.
So what would be a good, simple number we can use to gauge an operating system's memory efficiency? Working set size? Pageins and pageouts on a typical workload?
The average person needs a number, at least some kind of letter grade.
There's also the idea that even with a unified buffer cache, an operating system can be memory-inefficient - bloated data structures and inefficient page-aging algorithms can make that 2GB of RAM seem like 1GB.
Is there any simple gauge of how well an operating system uses memory?
My Prius is actually plenty roomy and comfortable. It's my first foreign car, and I couldn't be happier. I've been impressed by the quality of the construction too. Even if GM did come out with something rivaling the Prius in fuel economy, I'd be hesitant to return to American brands anyway. (Though there'd be at least a chance: until Detroit comes out with an efficient vehicle, I'm never coming back.)
It's kind of funny: I was the kind of guy who plastered his car with liberal bumper stickers. I haven't added anything to the Prius. I think the entire car is one big statement: "I give a shit."
So? My university health plan wasn't any better. It took days to see a real doctor (not a nurse practitioner who was basically a conduit between a hearing aide and a prescription pad), and months to see a specialist. Plus, it was obscenely expensive. Your point?
The percentage of GDP really doesn't matter so long as the burden is distributed equitably. I imagine there's a progressive income or property tax system in France, so that problem is solved. As for the supplementary insurance: you haven't given enough information. Source? It could be some minimal, 5/month supplement for TV in the hospital.
And as for copayments - I doubt your figures. Source? But even if you're right, the existence of copayments doesn't negate the usefulness of insurance, especially under catastrophic loss.
Interesting. So you guys (at least in Bavaria) aren't so different from the US. I know Bavarians have a recognizable accent too; do other Germans cringe when they hear it the same way we do when we hear someone with a thick Texas accent rattle on about guns?
China, India, and Brazil are rising powers, but they haven't achieved the same level of importance yet. Also, the per-capita GDPs of China, India, and Brazil are still below that of other industrialized nations.
See, that's where I think you're wrong. Here's my reasoning: as geeks, we pay more attention to the specifications and documentation than normal.
But as the guide for writing unmaintainable code says, bad documentation is worse than no documentation
We geeks read about how we're supposed to act around women. All that material is a product of a feel-good, postmodernist feminism that utterly fails to reflect what women actually want. It's the sociological equivalent of a single female saying she wants the nice guy and screwing the jock.
Speaking of these stereotypical jocks: they don't read. They don't think. They just act on their biological impulses. And thousands of years of evolution have honed these biological impulses to match what females want.
So, in short, society is telling anyone who will listen feel-good, egalitarian, and utterly wrong information about how to act around women. The successful ones, for once, don't read the documentation.
It's not waste energy. Extracting energy from the exhaust pressure differential increases the backpressure on the engine, reducing the available motive power for each stroke. (The engine has to work harder on the exhaust stroke, which robs power-striking cylinders of oomph.)
ECMAScript 4 will be a modern language in all senses of the word. It will support optional type annotations, destructuring assignment, generators, convenient inheritance, and all the other trappings of amodernlanguage.
With ECMAScript 4, the advantages of running anything other than Javascript fade away: you still have all your Ruby/Python/Lisp features, just spelled differently.
And from the browser point of view: would you rather create a generic scripting framework or add one language and be done forever?
Also, instead of trying to compile languages to MSIL, why not just write a source-to-source translator to Javascript? Isn't that what some people do to Java these days?
The political administration may order (not request, but order) a political wiretapping to catch communications they are interested in.
What on earth? At least here in the United States, the government pretends to not wiretap for private political motives. I thought Sweden was a pleasant, progressive nation. What happened to you guys?
And to think that only a century ago, we were debating whether ours was the only "island universe". It's amazing to think what progress we've made in only a couple lifetimes.
All transitive verbs take direct objects. If "effect" were intransitive, the sentence "Bob effects" would be correct, but it is clearly ungrammatical. "Run" is an intransitive verb. "Bob runs" is a correct sentence. Since "effect" is a transitive verb, it must therefore take a direct object.
Also, try replacing "effect" with "create". "Bob creates X" is correct as well.
Thank you for your polite reply, but I feel like I haven't adequately communicated my point.
The language you choose may affect your ability to scale when you take its concurrency model (or lack thereof in some cases) in to account. For instance, I can have a O(1) algorithm, using a hashmap, but that doesn't mean that I'll be able to have the runtime performance of constant time.
If your whole web application is bottlenecked by one hashmap, you're going to run into scalability problems as soon as you need more than one machine anyway. On the other hand, If the performance of the web application as a whole does not depend on the hashmap, then your argument is irrelevant to the scalability of the application as a whole.
I concede that a more efficient runtime environment might make better use of the same hardware, supporting, say, 70 clients instead of 50 per machine. But that's not the kind of scalability I'm talking about. Even a platform that achieved only one client per machine that scaled linearly would be better than one that handled 70 clients per machine, except that you were limited to one machine.
And yes, on one machine, a bad choice of data structure can affect scalability. But the blame for that rests on the data structure itself, not the language in which it is implemented. As an associative array, a Python hash table (dict) will scale far better than a C linked list. Why? Because one's a hash table and one is a linked list!
Which data structures are available in which language might factor into the choice of language, but it's only a convenience: you can always create your own data structure implementations.
Granted, there are ways around this, but you can't just throw hardware at the problem and pretend it doesn't exist.
Creating a scalable application means being able to throw hardware at the problem.
Let's assume you've gotten your application to scale beyond one machine anyway. That's a prerequisite for this section.
Now, if the machines don't communicate and users don't care, you automatically win O(N) scalability.
If your machines must communicate, they do so over some kind of network. The way this communication is achieved determines the scalability of the application. While some environments might have more intuitive network facilities than others (think Erlang), ultimately one can use any approach to networking with any language.
Again, we're reduced to choice of data structures and algorithms, not language, as the marker of scalability.
The choice of language does not dictate the data structure the designer of the application uses, and so the language is not a serious barrier to scalability. I concede it may be more difficult to implement efficient protocols in some languages than in others, but we're dealing with turing-complete languages here, aren't we?
I should note that languages typically thought of as "slower" are often more expressive. It often takes less effort to write efficient algorithms in expressive languages.
(Returning to our previous example, since writing a hash table is more complex than writing a naive linked list in C, a C programmer is more likely to use a linked list at the expense of scalability. In Python, using a hash table is as simple as writing {}, so an equally-skilled programmer is more likely to use the more efficient data structure, resulting in better performance in a "slower" language.)
The bottom line is that if communication between nodes is required, complexity must be > O(N). And if complexity is greater than O(N), then as N increase without bound, the communication overhead approaches infinity anyway. The key is to make that growth as slow as possible.
The tools and techniques used to slow that growth --- thinking about the problem, designing efficient algorithms --- are features of the human mind, and not any particular language.
Saying that one language is better at scaling than another is like arguing that one human language is better for building cars than another!
Slashdot Mirror
Demand paging with a unified buffer cache is a difficult concept for laymen to grasp. They tend to think of memory being a finite resource that is used up, rather than simply another caching layer for permanent storage.
So what would be a good, simple number we can use to gauge an operating system's memory efficiency? Working set size? Pageins and pageouts on a typical workload?
The average person needs a number, at least some kind of letter grade.
There's also the idea that even with a unified buffer cache, an operating system can be memory-inefficient - bloated data structures and inefficient page-aging algorithms can make that 2GB of RAM seem like 1GB.
Is there any simple gauge of how well an operating system uses memory?
My Prius is actually plenty roomy and comfortable. It's my first foreign car, and I couldn't be happier. I've been impressed by the quality of the construction too. Even if GM did come out with something rivaling the Prius in fuel economy, I'd be hesitant to return to American brands anyway. (Though there'd be at least a chance: until Detroit comes out with an efficient vehicle, I'm never coming back.)
It's kind of funny: I was the kind of guy who plastered his car with liberal bumper stickers. I haven't added anything to the Prius. I think the entire car is one big statement: "I give a shit."
Just imagine a world without scarcity of any kind. Imagine Diamond Age style matter compilers in every house. It'd be amazing, wouldn't it?
Reagan gave away the farm.
Oh yeah? I'm stuck using an RFC1149 connection. Let me tell you, path MTU discovery is a pain over that thing...
It's also important in user interface design. One of my pet peeves is seeing something like:
[X] Disable the foo button
Why the hell not just invert the sense of the checkbox?
[ ] Enable the foo button
So? My university health plan wasn't any better. It took days to see a real doctor (not a nurse practitioner who was basically a conduit between a hearing aide and a prescription pad), and months to see a specialist. Plus, it was obscenely expensive. Your point?
The percentage of GDP really doesn't matter so long as the burden is distributed equitably. I imagine there's a progressive income or property tax system in France, so that problem is solved. As for the supplementary insurance: you haven't given enough information. Source? It could be some minimal, 5/month supplement for TV in the hospital.
And as for copayments - I doubt your figures. Source? But even if you're right, the existence of copayments doesn't negate the usefulness of insurance, especially under catastrophic loss.
Interesting. So you guys (at least in Bavaria) aren't so different from the US. I know Bavarians have a recognizable accent too; do other Germans cringe when they hear it the same way we do when we hear someone with a thick Texas accent rattle on about guns?
Not if all that GDP is produced by subsidence agriculture. It's the ability to project power outside your borders that counts.
China, India, and Brazil are rising powers, but they haven't achieved the same level of importance yet. Also, the per-capita GDPs of China, India, and Brazil are still below that of other industrialized nations.
See, that's where I think you're wrong. Here's my reasoning: as geeks, we pay more attention to the specifications and documentation than normal.
But as the guide for writing unmaintainable code says, bad documentation is worse than no documentation
We geeks read about how we're supposed to act around women. All that material is a product of a feel-good, postmodernist feminism that utterly fails to reflect what women actually want. It's the sociological equivalent of a single female saying she wants the nice guy and screwing the jock.
Speaking of these stereotypical jocks: they don't read. They don't think. They just act on their biological impulses. And thousands of years of evolution have honed these biological impulses to match what females want.
So, in short, society is telling anyone who will listen feel-good, egalitarian, and utterly wrong information about how to act around women. The successful ones, for once, don't read the documentation.
Nah. The administration is a little classier, paying the kid's way into Yale.
Wouldn't there have been fjords resulting from previous glaciations? It's not as if they're unique to the last one.
Why use RHN when yum works very well?
Are you thinking of an RTG? These things last a few decades before the thermocouples lose the ability to transform the heat to electricity.
"Percussive maintenance."
According to the TFA, the maximum planned output is 1kW. That's only 1.3 horsepower!
It's not waste energy. Extracting energy from the exhaust pressure differential increases the backpressure on the engine, reducing the available motive power for each stroke. (The engine has to work harder on the exhaust stroke, which robs power-striking cylinders of oomph.)
ECMAScript 4 will be a modern language in all senses of the word. It will support optional type annotations, destructuring assignment, generators, convenient inheritance, and all the other trappings of a modern language.
With ECMAScript 4, the advantages of running anything other than Javascript fade away: you still have all your Ruby/Python/Lisp features, just spelled differently.
And from the browser point of view: would you rather create a generic scripting framework or add one language and be done forever?
Also, instead of trying to compile languages to MSIL, why not just write a source-to-source translator to Javascript? Isn't that what some people do to Java these days?
What on earth? At least here in the United States, the government pretends to not wiretap for private political motives. I thought Sweden was a pleasant, progressive nation. What happened to you guys?
And to think that only a century ago, we were debating whether ours was the only "island universe". It's amazing to think what progress we've made in only a couple lifetimes.
All transitive verbs take direct objects. If "effect" were intransitive, the sentence "Bob effects" would be correct, but it is clearly ungrammatical. "Run" is an intransitive verb. "Bob runs" is a correct sentence. Since "effect" is a transitive verb, it must therefore take a direct object.
Also, try replacing "effect" with "create". "Bob creates X" is correct as well.
If your whole web application is bottlenecked by one hashmap, you're going to run into scalability problems as soon as you need more than one machine anyway. On the other hand, If the performance of the web application as a whole does not depend on the hashmap, then your argument is irrelevant to the scalability of the application as a whole.
I concede that a more efficient runtime environment might make better use of the same hardware, supporting, say, 70 clients instead of 50 per machine. But that's not the kind of scalability I'm talking about. Even a platform that achieved only one client per machine that scaled linearly would be better than one that handled 70 clients per machine, except that you were limited to one machine.
And yes, on one machine, a bad choice of data structure can affect scalability. But the blame for that rests on the data structure itself, not the language in which it is implemented. As an associative array, a Python hash table (dict) will scale far better than a C linked list. Why? Because one's a hash table and one is a linked list!
Which data structures are available in which language might factor into the choice of language, but it's only a convenience: you can always create your own data structure implementations.
Creating a scalable application means being able to throw hardware at the problem.
Let's assume you've gotten your application to scale beyond one machine anyway. That's a prerequisite for this section.
Now, if the machines don't communicate and users don't care, you automatically win O(N) scalability.
If your machines must communicate, they do so over some kind of network. The way this communication is achieved determines the scalability of the application. While some environments might have more intuitive network facilities than others (think Erlang), ultimately one can use any approach to networking with any language.
Again, we're reduced to choice of data structures and algorithms, not language, as the marker of scalability.
The choice of language does not dictate the data structure the designer of the application uses, and so the language is not a serious barrier to scalability. I concede it may be more difficult to implement efficient protocols in some languages than in others, but we're dealing with turing-complete languages here, aren't we?
I should note that languages typically thought of as "slower" are often more expressive. It often takes less effort to write efficient algorithms in expressive languages.
(Returning to our previous example, since writing a hash table is more complex than writing a naive linked list in C, a C programmer is more likely to use a linked list at the expense of scalability. In Python, using a hash table is as simple as writing {}, so an equally-skilled programmer is more likely to use the more efficient data structure, resulting in better performance in a "slower" language.)
The bottom line is that if communication between nodes is required, complexity must be > O(N). And if complexity is greater than O(N), then as N increase without bound, the communication overhead approaches infinity anyway. The key is to make that growth as slow as possible.
The tools and techniques used to slow that growth --- thinking about the problem, designing efficient algorithms --- are features of the human mind, and not any particular language.
Saying that one language is better at scaling than another is like arguing that one human language is better for building cars than another!