Wow. How do you even deliver 1TB/day to a database? That's more than enough to saturate a 100Mbps network, 24 hours/day. And how do you index it, so it can be usefully retrieved? And how do you store it?
That is a truly astounding amount of data. It's like receiving Google's entire database every week, several times over.
Nice one. Not only did I post a redundant comment; I attached it to the wrong article. Some please mod parent article into the oblivion it deserves. (It's ok, I have plenty of karma.)
Time to market these days means being able to reuse and adapt the previous product's software as quickly as possible.
Partly. This is "external reuse", where a software component is used on multiple projects. However, "internal reuse" is equally important, where a component (function, data structure, class, whatever) is used multiple times in the same project. This has two advantages:
Less development time, because you're re-using code you have already written.
Less debugging time, because every defect you correct in a shared piece of code fixes several bugs.
In this way, software components are opposite to mechanical devices: the more they are used, the more reliable they become.
How often are 4M pages useful? I guess the whole kernel could be in one page, but where else is this useful? I bet most applications would never see any benefit from 4M pages anyway.
Just think... north becomes south, and south becomes north.
And, if it shifts once more, then Earth's north pole will actually be a magnetic north. Right now it's a magnetic south; that's why the north pole of a magnetic compass is attracted to it.
Say YES to having all the exercise equipment in the world hooked up to generators!
Actually, at the gym I go to, many of the machines don't plug into the wall current. The electricity needed to power the machine comes from the person using it.
Anonymous Cowards filtered. If their words aren't worth so much as a nom de plume why should I value them any more?
Does anonymity always make an opinion worthless?
Do you believe in secret-ballot elections? Isn't it beneficial to allow people to express controvercial opinions with no threat of repercussion?
Thanks for the info. You are right of course. My comment about kinetic energy was wrong.
However, what I meant by not measuring the recession speed "directly" was that the yearly recession of the moon is swamped by other factors like the eccentricity of the moon's orbit, rotation of the Earth, etc. Whatever velocity you measure will have no relation whatsoever to the moon's rate of recession.
Bzzztt. The speed that the moon receeds wasn't measured directly, especially by doppler shift of all things. It was calculated from the kinetic energy gained by the moon from the Earth from tidal forces.
This reminds me of the last time I went to have dinner at the Old Spaghetti Factory in Toronto. Their lounge has about six old ceiling fans, all driven by the same motor, connected by chains.
We all know what happened to that technology.
This might prove to be a good stepping-stone, but I think the end result will be a motor on everything that moves.
So on Linux, the fact that memory isn't shared between processes (hence CPU coherency isn't the same issue) often makes processes a substantial performance _win_.
I think you're comparing apples and oranges. If you have two threads that are not modifying the same portion of the address space, there is no coherency traffic. OTOH, if they do modify the same pages, presumably it's because they need to communicate, which they would need to do with processes anyway.
Thus, I still don't see any reason that processes are inherently more efficient than threads. Unless you think you can settle the shared-memory-versus-message-passing debate once and for all.:-)
Linux threads aren't tremendously more efficient than its processes, but threads can be pooled. When a connection closes, its thread doesn't terminate; instead, it blocks and waits to be assigned to a new connection. That way, the thread creation cost is amortized over a lot more connection.
It's also possible to pool processes, but pooling threads is easier and more efficient, because you don't need interprocess communication or special shared-memory segments. Instead, you just have the threads all block on the same job queue.
Wow. I read this guy's description of what he has done. I hope he's a teacher, because his explanation of those complex issues was a joy to read.
I have a BP6 dual-celeron Debian machine which already gives me the benefits of countless hours of volunteer time, including the SMP kernel and ReiserFS, along with dozens of free development tools. Now I see this guy working like a dog to tune the heck out of the scheduler for SMP machines, and I know that when I eventually run the 2.6 kernel, I'm again going to reap the benefits of his work.
It's almost enough to make me learn to hack the Linux kernel out of a sense of obligation.
It's not a matter of compute cycles. My point is that whatever language they were translating into, why not just write the first version directly in that language? Be it assembly or p-code or whatever, what is the point of emulating a compiler on paper when you could just write the code in the target language to begin with?
Slashdot Mirror
I hereby declare the "how can they detect this" question redundant, since it has already been asked here and here and here and here and here and here.
Wow. How do you even deliver 1TB/day to a database? That's more than enough to saturate a 100Mbps network, 24 hours/day. And how do you index it, so it can be usefully retrieved? And how do you store it?
That is a truly astounding amount of data. It's like receiving Google's entire database every week, several times over.
Nice one. Not only did I post a redundant comment; I attached it to the wrong article. Some please mod parent article into the oblivion it deserves. (It's ok, I have plenty of karma.)
This is a great idea. Here's two cents' worth of encouragement from me.
-
Less development time, because you're re-using code you have already written.
-
Less debugging time, because every defect you correct in a shared piece of code fixes several bugs.
In this way, software components are opposite to mechanical devices: the more they are used, the more reliable they become.Slightly off-topic, but...
How often are 4M pages useful? I guess the whole kernel could be in one page, but where else is this useful? I bet most applications would never see any benefit from 4M pages anyway.
Don't blame him for your despised disaster scenario: you're the one who extrapolated from his Java simulation to the real world.
20F is -7C.
Thanks for the info. You are right of course. My comment about kinetic energy was wrong.
However, what I meant by not measuring the recession speed "directly" was that the yearly recession of the moon is swamped by other factors like the eccentricity of the moon's orbit, rotation of the Earth, etc. Whatever velocity you measure will have no relation whatsoever to the moon's rate of recession.
Bzzztt. The speed that the moon receeds wasn't measured directly, especially by doppler shift of all things. It was calculated from the kinetic energy gained by the moon from the Earth from tidal forces.
This reminds me of the last time I went to have dinner at the Old Spaghetti Factory in Toronto. Their lounge has about six old ceiling fans, all driven by the same motor, connected by chains.
We all know what happened to that technology.
This might prove to be a good stepping-stone, but I think the end result will be a motor on everything that moves.
Thus, I still don't see any reason that processes are inherently more efficient than threads. Unless you think you can settle the shared-memory-versus-message-passing debate once and for all. :-)
As someone with a bona fide engineering degree, it does bother me a bit that they are allowed to use the term "Engineer" for what they do.
Answer: don't install it. It's not yet stable. Some people on the mailing list had trouble booting with the patch.
I'm looking forward to the day it appears in kernel 2.6.
Linux threads aren't tremendously more efficient than its processes, but threads can be pooled. When a connection closes, its thread doesn't terminate; instead, it blocks and waits to be assigned to a new connection. That way, the thread creation cost is amortized over a lot more connection.
It's also possible to pool processes, but pooling threads is easier and more efficient, because you don't need interprocess communication or special shared-memory segments. Instead, you just have the threads all block on the same job queue.
Wow. I read this guy's description of what he has done. I hope he's a teacher, because his explanation of those complex issues was a joy to read.
I have a BP6 dual-celeron Debian machine which already gives me the benefits of countless hours of volunteer time, including the SMP kernel and ReiserFS, along with dozens of free development tools. Now I see this guy working like a dog to tune the heck out of the scheduler for SMP machines, and I know that when I eventually run the 2.6 kernel, I'm again going to reap the benefits of his work.
It's almost enough to make me learn to hack the Linux kernel out of a sense of obligation.
It's not a matter of compute cycles. My point is that whatever language they were translating into, why not just write the first version directly in that language? Be it assembly or p-code or whatever, what is the point of emulating a compiler on paper when you could just write the code in the target language to begin with?