Agreed... Which is why it is on/. and comes back every couple of months...
"I mean, a lot of people are just running Word and Excel."
They won't be running Tanenbaum's microkernel either... (by the way, does it even exist yet?)
"Even for servers, I/O is usually more important for performance."
And I/O needs system calls, which is where the slowdown is when you have a microkernel...
"Your point about CPU caches shows that memory latency is typically a bigger bottleneck than raw CPU speed."
It can be a biggie, and the microkernel thrashes the cache a little more than necessary.
"How often is your CPU running at 100%?"
Actually, a lot: g++ takes a lot (really a lot) of time compiling code if you use a lot of template classes (STL, boost, and friends). But granted, that won't slow down with a microkernel... But the production systems I work on do make a lot of system calls and are often heavilym and continously loaded with both I/O and CPU.
"Uh, no. Only interference engines have that problem. Unless you're driving a Pontiac (generally classified as "high performance" engines) or an older vehicle, you're unlikely to end up with an interference engine."
The 2002-2004 models of the VW Beetle, Jetta, Passat all have an Interference engine. I wouldn't call that an older car, or a car with a high-performance engine (esp not the Beetle and Jetta)... (http://www.forparts.com/daycovolkswagen.htm)
Non-interference engines have lower compression ratios because of the increased space between the pistons and the cylinders... A Higher Lower compression ratio does not just mean that you can make a more powerful engine, but it also means that you can make an engine that makes more efficient use of the energy in the gasoline (gas mileage).
But ok, so your point is that you can make a non-interference engine and prevent the self-destruct when the timing belt gives up.
You don't need a microkernel for that kind of protection, you can do the same thing in monolithic kernels by running the driver in userspace (in a kernel thread). So you have a choice. With a microkernel you don't have the option to use a rock-solid driver without overhead.
"And the operations I mentioned were system call operations like performing IO read/writes, caching, interfacing with devices, etc. So yes, most applications would not be affected significantly."
Linux/Unix is mainly used in server applications. Many server applications heavily perform "IO read/writes, caching, interfacing with devices, etc."...
"That is, as the hardware speed increases, the percentage of the slowdown decreases." "Between, say, 300mhz CPU's, the performance difference may be 6-14%, but 600mhz CPU's it may shrink down to 3-7% for instance."
That can't be so. The slowdown is caused by additional CPU/memory operations. Sure, the number of operations stays constant, but on the faster CPU the other operations also speedup, so the percentage stays the same. Actually, if the operations are really 'constant time', then the percentage would go up with faster processors, because everything except the 'constant time' operations would speed up.
"If you were right, nobody would buy anything except the top-speed CPUs. If you look at what people are buying, they tend to be more middle-of-the-road or low-end CPUs. So I think your argument falls down."
People buy the middle of the road because that gives you a better value: more speed per dollar. If the OS steals 6-14% of that, it reduces that value.
High-end CPUs are pricey, which means people that buy them are willing to pay up for the little extra speed. They wouldn't be happy with a 6-14% performance hit.
Many enthousiasts overclock their CPU's. They wouldn't be happy with a 6-14% performance hit.
Linux/Unix is mainly used in server applications. Those processors (Opterons/Xeons) carry a price premium just because they give a couple extra percent more speed with the larget caches that they have.
"There is about a 6% to 14% performance hit, depending on the operation. Although most of the slowdown is constant-time. And Andy claims that that kind of performance hit is insignificant in today's uber-fast systems."
Which is one of the points on which he is wrong...
14% takes that 2GHz processor down to 1720MHz, a 3GHz processor to 2580MHz
If he were right, the top 300-500MHz processors would never sell, because 14% below that would be fast enough for everybody.
"Snap your cam shaft and your engine is fucked until it's fixed. Your attempt at a contrary metaphor just plays into his theory."
So is your microkernel-engine without a camshaft. Plus, with all the parts in separate boxes, your 65hp engine might just fit in the truckbed of that huge F350 you're powering with it.
"Prof Milton's team calculated that when certain objects are placed next to superlenses, the light bouncing off them is essentially erased by light reflecting off the superlens, making the object invisible."
I know of at least one other device that can make objects invisible when they are placed next to my device.
"Realize that there isn't a laptop on the planet that can make use of a 64 bit address space, and come to my senses?"
You are so 'misinformed'...
X86-64 doubles the number of registers in the chip, resulting in quite a significant speed boost due to the significantly decreased need to access memory.
"You can replace all of the world's power with a tiny fraction of the US desert southwest's almost worthless 50$/acre barren desert land alone with solar thermal (1.4kW/m^2, 20% atmospheric losses, 70% day/night/seasonal losses, 30% efficiency -> 100W/m^2 avg; 52M GJ/day -> 600 GW -> 6B m^2 -> 6000 km^2; New Mexico is 315,194 km^2)."
It's not exactly that simple. I'm not sure, but I don't think the highest space-grade solar cells get 30%. A better guess would be 10-15% for silicon solar cells. Now, there is the second problem. There is not enough high-grade sand to make that much square kilometers of silicon of the quality required to get that kind of efficiency. So, you would have to go to much lower quality sand, further reducing efficiency, but without reducing production cost. And there is the third problem. Silicon solar cells bottom out at around $5/Watt, so even if the other problems are dealt with you are looking at $3T just to build the total solar plant (not pricing distribution, land usage, political project delays, etc).
Now, that is not to say there isn't hope, because various labs/companies are working on non-silicon solar cells, and some labs are claiming target prices of $0.5-$1/Watt, and some claim good efficiencies too. Not all together (yet), and very much still in laboratory phase, not much experience with durability, etc. But it's hope.
My point is that it's not that simple, but we're on our way, and it needs more time.
"Frankly, I doubt photovoltaic add-on packages will ever be cost effective for a hybrid vehicle. The efficiency is way too low, for one thing."
Rigth now, the rought price for PV is $5/Watt, and some labs have come out saying they are developing product for $0.50...$1/Watt.. So, divide your PV price by 5 to 10 and then think again.
The cells can then also go into hybrids (no need to wait for fuel cells).
ZRAM is in line with Merom, we're talking about the end of this year, or later, here (if Intel can't fix the problems with Merom, it's schedule will slip again.
Oh, btw M2 adds DDR2 support, not DDR, and that's hardly a tweak.
"Intel has learned from it's mistake with NetBurst (P4) design descisions and are finally heading back in the right direction."
Exactly, they are going a step backward by going back to the Pentium-M with some modifications.
"So, by the time the 45nm comes out, there will also be a new architecture to place on the new chips. We'll see how things are then."
That is an awful lot of 'forward looking'. AMD will not sit still between now and then either, on either front (process and architecture).
Intel just canceled their Whitefield processor, the only one that ever was on their roadmap to sport an integrated memory controller.
AMD is improving their architecture continuously: Introducing chips with DDR2 support very soon (motherboard manufacturers have samples), just licensed ZRAM technology to add low silicon area very large Level 3 caches, will be introducing improved versions of the HTT interconnect that makes the multi-chip Opteron systems scale so well, is going to show us a quad-core version this year, etc etc.
I don't have to wait and see, it's too clear where this is going.
Intel may have 65nm in Fab D1D right now, with plans to convert 2 more fabs to 65nm while converting D1D to 45nm, they have many more fabs that are much farther away from 65nm. Many Intel chips will have to be made on processes older than 65nm.
AMD's new Fab65 just opened last October, is already generating fantastic yields at 90nm, and it is ready for 65nm and below (this year, sooner rather than later), and (even though AMD hasn't spoken about doing it), it would not be impossible to retool their Fab30 to 65nm.
And AMD's 65nm will have SOI, just like their 90nm does. Intel does not have SOI.
Being ahead or behind in processors is not all about the nanometers you produce them in.
Transistors are not made of just 'nanometers'. There is more to a transistor than the process node of the steppers. In process technology, AMD is ahead by using SOI and soon added to that very silicon area efficient ZRAM based LIII caches.
Besides that, it's also about processor architecture (among other things the onboard memory controller).
Intel may ramp to 45nm before AMD, but AMD's 65nm will kick Intel's 45nm's butt just like the current AMD 90nm is kicking intel's 65nm.
"Apple for example aren't actually worth more than 70 billion but just their shares are."
Not even that. It's what the current owners thing they are worth. If they all would like to cash-out and sell their shares for the $70B, only the very first sellers would get their share, because the price will drop rapidly.
"I think all it means is that you don't really know much about the whole micropayment problem."
Nope, it means that people who thing there is a micropayment problem simply don't see the solution.
Transactions are cheap, forget what the companies in the transaction business want to tell you, they are just in there to make a buck, not to make it easy or cheap to exchange money.
The solution is not complex either. When I make a phone call, I get charged micropayment per minute that I call. QED.
If you still see problems, you're just looking for a problem, not a solution.
"Go and check it yourself, and compare to lame sources. The data from tables.c is included in the executable in identical form (several large tables), also all the version strings are included, which the DRM system doesn't check."
"I think we could argue this point for days."
/. and comes back every couple of months...
Agreed... Which is why it is on
"I mean, a lot of people are just running Word and Excel."
They won't be running Tanenbaum's microkernel either... (by the way, does it even exist yet?)
"Even for servers, I/O is usually more important for performance."
And I/O needs system calls, which is where the slowdown is when you have a microkernel...
"Your point about CPU caches shows that memory latency is typically a bigger bottleneck than raw CPU speed."
It can be a biggie, and the microkernel thrashes the cache a little more than necessary.
"How often is your CPU running at 100%?"
Actually, a lot: g++ takes a lot (really a lot) of time compiling code if you use a lot of template classes (STL, boost, and friends). But granted, that won't slow down with a microkernel... But the production systems I work on do make a lot of system calls and are often heavilym and continously loaded with both I/O and CPU.
"Uh, no. Only interference engines have that problem. Unless you're driving a Pontiac (generally classified as "high performance" engines) or an older vehicle, you're unlikely to end up with an interference engine."
The 2002-2004 models of the VW Beetle, Jetta, Passat all have an Interference engine. I wouldn't call that an older car, or a car with a high-performance engine (esp not the Beetle and Jetta)... (http://www.forparts.com/daycovolkswagen.htm)
Non-interference engines have lower compression ratios because of the increased space between the pistons and the cylinders... A Higher Lower compression ratio does not just mean that you can make a more powerful engine, but it also means that you can make an engine that makes more efficient use of the energy in the gasoline (gas mileage).
But ok, so your point is that you can make a non-interference engine and prevent the self-destruct when the timing belt gives up.
You don't need a microkernel for that kind of protection, you can do the same thing in monolithic kernels by running the driver in userspace (in a kernel thread). So you have a choice. With a microkernel you don't have the option to use a rock-solid driver without overhead.
"And the operations I mentioned were system call operations like performing IO read/writes, caching, interfacing with devices, etc. So yes, most applications would not be affected significantly."
Linux/Unix is mainly used in server applications. Many server applications heavily perform "IO read/writes, caching, interfacing with devices, etc."...
"That is, as the hardware speed increases, the percentage of the slowdown decreases." "Between, say, 300mhz CPU's, the performance difference may be 6-14%, but 600mhz CPU's it may shrink down to 3-7% for instance."
That can't be so. The slowdown is caused by additional CPU/memory operations. Sure, the number of operations stays constant, but on the faster CPU the other operations also speedup, so the percentage stays the same. Actually, if the operations are really 'constant time', then the percentage would go up with faster processors, because everything except the 'constant time' operations would speed up.
"If you were right, nobody would buy anything except the top-speed CPUs. If you look at what people are buying, they tend to be more middle-of-the-road or low-end CPUs. So I think your argument falls down."
People buy the middle of the road because that gives you a better value: more speed per dollar. If the OS steals 6-14% of that, it reduces that value.
High-end CPUs are pricey, which means people that buy them are willing to pay up for the little extra speed. They wouldn't be happy with a 6-14% performance hit.
Many enthousiasts overclock their CPU's. They wouldn't be happy with a 6-14% performance hit.
Linux/Unix is mainly used in server applications. Those processors (Opterons/Xeons) carry a price premium just because they give a couple extra percent more speed with the larget caches that they have.
Speed matters. Always.
Oops, meant to say 'smash their valves in the cylinders'.
Actually, even the smallest fourbangers will smash their heads in the valves if you break the timing belt...
"There is about a 6% to 14% performance hit, depending on the operation. Although most of the slowdown is constant-time. And Andy claims that that kind of performance hit is insignificant in today's uber-fast systems."
Which is one of the points on which he is wrong...
14% takes that 2GHz processor down to 1720MHz, a 3GHz processor to 2580MHz
If he were right, the top 300-500MHz processors would never sell, because 14% below that would be fast enough for everybody.
"Snap your cam shaft and your engine is fucked until it's fixed. Your attempt at a contrary metaphor just plays into his theory."
So is your microkernel-engine without a camshaft. Plus, with all the parts in separate boxes, your 65hp engine might just fit in the truckbed of that huge F350 you're powering with it.
"Prof Milton's team calculated that when certain objects are placed next to superlenses, the light bouncing off them is essentially erased by light reflecting off the superlens, making the object invisible."
I know of at least one other device that can make objects invisible when they are placed next to my device.
I'm calling it a superwall.
"Realize that there isn't a laptop on the planet that can make use of a 64 bit address space, and come to my senses?"
You are so 'misinformed'...
X86-64 doubles the number of registers in the chip, resulting in quite a significant speed boost due to the significantly decreased need to access memory.
"You can replace all of the world's power with a tiny fraction of the US desert southwest's almost worthless 50$/acre barren desert land alone with solar thermal (1.4kW/m^2, 20% atmospheric losses, 70% day/night/seasonal losses, 30% efficiency -> 100W/m^2 avg; 52M GJ/day -> 600 GW -> 6B m^2 -> 6000 km^2; New Mexico is 315,194 km^2)."
It's not exactly that simple. I'm not sure, but I don't think the highest space-grade solar cells get 30%. A better guess would be 10-15% for silicon solar cells. Now, there is the second problem. There is not enough high-grade sand to make that much square kilometers of silicon of the quality required to get that kind of efficiency. So, you would have to go to much lower quality sand, further reducing efficiency, but without reducing production cost. And there is the third problem. Silicon solar cells bottom out at around $5/Watt, so even if the other problems are dealt with you are looking at $3T just to build the total solar plant (not pricing distribution, land usage, political project delays, etc).
Now, that is not to say there isn't hope, because various labs/companies are working on non-silicon solar cells, and some labs are claiming target prices of $0.5-$1/Watt, and some claim good efficiencies too. Not all together (yet), and very much still in laboratory phase, not much experience with durability, etc. But it's hope.
My point is that it's not that simple, but we're on our way, and it needs more time.
"Frankly, I doubt photovoltaic add-on packages will ever be cost effective for a hybrid vehicle. The efficiency is way too low, for one thing."
Rigth now, the rought price for PV is $5/Watt, and some labs have come out saying they are developing product for $0.50...$1/Watt.. So, divide your PV price by 5 to 10 and then think again.
The cells can then also go into hybrids (no need to wait for fuel cells).
"You're also ignoring Intel's plans to introduce Merom in 2H of this year."
n ched_in_september/
n roe/optimism_2.htm explains why ZRAM is the answer of AMD to Merom's large cache, but without needing to match the high manufacturing cost and power problems of the Merom...
The Merom, "shows higher power consumption levels than the company anticipated" and if they can fix that, it will be introduced at a paltry 2.33GHz in September... The Merom is already obsolete. http://www.tgdaily.com/2006/01/11/merom_to_be_lau
The AMD FX60 dual-core available _today_ is already at 2.4Ghz in 90nm silicon, and will definitely switch Fab36 to 65nm before Merom is out.
And this page http://www.penstarsys.com/editor/company/intel/co
ZRAM is in line with Merom, we're talking about the end of this year, or later, here (if Intel can't fix the problems with Merom, it's schedule will slip again.
Oh, btw M2 adds DDR2 support, not DDR, and that's hardly a tweak.
"Intel has learned from it's mistake with NetBurst (P4) design descisions and are finally heading back in the right direction."
Exactly, they are going a step backward by going back to the Pentium-M with some modifications.
"So, by the time the 45nm comes out, there will also be a new architecture to place on the new chips. We'll see how things are then."
That is an awful lot of 'forward looking'. AMD will not sit still between now and then either, on either front (process and architecture).
Intel just canceled their Whitefield processor, the only one that ever was on their roadmap to sport an integrated memory controller.
AMD is improving their architecture continuously: Introducing chips with DDR2 support very soon (motherboard manufacturers have samples), just licensed ZRAM technology to add low silicon area very large Level 3 caches, will be introducing improved versions of the HTT interconnect that makes the multi-chip Opteron systems scale so well, is going to show us a quad-core version this year, etc etc.
I don't have to wait and see, it's too clear where this is going.
Intel may have 65nm in Fab D1D right now, with plans to convert 2 more fabs to 65nm while converting D1D to 45nm, they have many more fabs that are much farther away from 65nm. Many Intel chips will have to be made on processes older than 65nm.
AMD's new Fab65 just opened last October, is already generating fantastic yields at 90nm, and it is ready for 65nm and below (this year, sooner rather than later), and (even though AMD hasn't spoken about doing it), it would not be impossible to retool their Fab30 to 65nm.
And AMD's 65nm will have SOI, just like their 90nm does. Intel does not have SOI.
Being ahead or behind in processors is not all about the nanometers you produce them in.
Transistors are not made of just 'nanometers'. There is more to a transistor than the process node of the steppers. In process technology, AMD is ahead by using SOI and soon added to that very silicon area efficient ZRAM based LIII caches.
Besides that, it's also about processor architecture (among other things the onboard memory controller).
Intel may ramp to 45nm before AMD, but AMD's 65nm will kick Intel's 45nm's butt just like the current AMD 90nm is kicking intel's 65nm.
"Apple for example aren't actually worth more than 70 billion but just their shares are."
Not even that. It's what the current owners thing they are worth. If they all would like to cash-out and sell their shares for the $70B, only the very first sellers would get their share, because the price will drop rapidly.
Marketcap is just a number.
Bullshit. They made a profit last quarter, and will make a bigger profit in Q4.
"I think all it means is that you don't really know much about the whole micropayment problem."
Nope, it means that people who thing there is a micropayment problem simply don't see the solution.
Transactions are cheap, forget what the companies in the transaction business want to tell you, they are just in there to make a buck, not to make it easy or cheap to exchange money.
The solution is not complex either. When I make a phone call, I get charged micropayment per minute that I call. QED.
If you still see problems, you're just looking for a problem, not a solution.
Bill Gates is worth, what, 40Billion? 400 Million is still a lot then: I hope your net worth is better than 100 lunches...
Bullshit: Store credit.
Wall, afaics, getting to the point of dying from a terminal disease is a little worse than being at the point of having it.
In the former situation, you are at the north pole, in the latter you just know you will be going north only.
Life is a terminal disease, really.
"If you haven't had conversations with executives there, and talked about their processes of determining what gets implemented and what doesn't,"...
You are just making his point about the 'mythical man month'.
Red tape kills. Ban Red Tape(tm)!
Ok, well from here:
"Go and check it yourself, and compare to lame sources. The data from tables.c is included in the executable in identical form (several large tables), also all the version strings are included, which the DRM system doesn't check."
It walks like a chicken.
"but you continue to try to"...
This is my second reply to you. What are you talking about.
"Your reasoning is: There must be a conspiracy."
I have never said that. Who are you confusing me with?
My reasoning is: A quick inspection shows the rootkit has a symbol from lame with a nontrivial name, hence it quite likely has lame in it.