If Linus is feeling even vaguely himself, he will not accept this patch. Ordinarily, people trying to put stuff into the kernel that a) hurts performance, and b) fixes no real problem, but c) is critical to some contrived project that seems really important to the contributor get entertainingly flamed, and then shown the door. In fact, Kevin's most likely motivation for submitting this as a Slashdot story is to marshall support for his Linux patch.
That's harsh. I see nothing wrong with redefining the goal's more modestly, and contrary to what you suggest, I haven't seen anyone pushing for Plex86 patches in mainline. Everybody knows what the process is, and it does not happen on unproven code.
I do particularly like the kernel service module as a design approach. For what I'd use this for, which is kernel debugging, this is entirely appropriate. To me, the key is a lightweight, clean design, without attempting to take over the world.
Plex86 is taking so very long to materialize, I wonder if it is even worth the effort being put into it. Bochs works fine, even if slow, and virtualization isn't exactly a big market. Where does Plex86 fit into all this?
You bet it's worth it. I'm really glad Kevin has been able to return to working on it. I consider him brilliant. It's really sad that Mandrake was unable to continue to sponsor his important work.
It makes a whole lot of sense to set the sights a little lower, resulting in something simpler and achievable by one or two people. Now I'll evaluate plex86 for 2.5 debugging work and see how it stacks up against User Mode Linux.
I agree with some of the above posters. I don't think the graphics are all that impressive, though I have to say that they DO look better than 90% of the linux games we have now. Any code coming over to our side is better than nothing, and maybe someone will look at this code and say "hey, I can use this to/insert really cool statement here/"
Make that 99% of the Linux games we have now. Actually, the terrain rendering is quite nice, so is the snow texture mapping. The snowboarder figure is done with taste, though not to today's typical production values. The trees suck pretty badly, but that is exactly where somebody could go in and bring the graphics up to today's standards, relying purely on the current generation of fast GPUs to handle a lot of extra splats.
The terrain rendering is expansive - it's hard to spot a backdrop, if there is one at all.
In any case, speaking as a developer of games, you can be sure I'll _never_ release anything into the GPL. Not so much because of politics but just because I can't stand the attitude of the GPL zealots who whine and moan about everything.
But you will happily read, learn from, and/or use the code written by others and released to the public?
I do would like to have a look at the src u used to do the benchmarking, I'm looking at dynamic typing issues and the tradeoff's associated with them...performance would be a good one..
Oops, heres's the rest of it, from the <=: <=2? 1: fib(n-2) + fib(n-1);
}
public static void main(String args[]) {
int n = 22;
System.out.println("Fib of "+n+" is "+fib(n));
}
}
The jit-compiled Java ends up running faster than the gcc-compiled C probably because of better register optimization, and possibly elimination of the tail-recursion. I didn't look at the assembly code from the C this time, but every time I do, I tend to see extra instructions being generated that should have been optimized away with simple peephole optimization. Lots of room for improvement.
I'm interested in seeing the code in the three languages that you were using. I'd like to see where the bottlenecks are and see what specificly causes these results. I would think that C would be faster than Java, which would be faster than Python (but none by 100 x). I'm not saying that you're wrong, but now I'm interested in why.
Oh, and the java version:
class Fib {
static int fib(int n) {
return n<
The jit-compiled Java ends up running faster than the gcc-compiled C probably because of better register optimization, and possibly elimination of the tail-recursion. I didn't look at the assembly code from the C this time, but every time I do, I tend to see extra instructions being generated that should have been optimized away with simple peephole optimization. Lots of room for improvement.
I do would like to have a look at the src u used to do the benchmarking, I'm looking at dynamic typing issues and the tradeoff's associated with them...performance would be a good one..
It's the Batteries Included part of Python that makes it such a productive environment. Optimization is suppose to be the last step in the coding cycle. Get it write in Python first and then recode the bits that are too slow to tolerate in C.
That would be fine if Python had a more efficient C interface than it does. What's it has sucks supremely. You parse ascii text to unpack each parameter. Grief. The result of this is, you can't write just the little parts that suck the time in C, you have to wrap these in enough surrounding program to cut down the number of times you have to cross the C-Python boundary.
Mind you, I still like Python, but I shy away from it for any heavy lifting. The Python crowd really do need to look seriously at native code generation, it's just not something you can ignore forever. As it stands, I see Python as a more elegant, maintainable way of writing the kind of scripts that have traditionally be done in Bash and Perl.
Renderman is a specification, not a product. There are various open-source efforts to implement the renderman specification, but they all seem to be dormant at the moment. See here.
I am, however, a little leary on the performance parity bit. Don't get me wrong, I love programming in Python, but I know from experience that it still costs a good bit to create all the dictionaries that are used for frame construction, global maniuplation, and object management.
I did a little benchmarking recently, and I can confirm that for typical algorithmic benchmarks (not heavily library or IO oriented) Python is more than 100 times slower than C/C++. There's a Python "specializing compiler" called Psyco that produces significant speedup, running my little fibonacci test around half the speed of C, very impressive.
Java on the other hand has had huge amounts of effort and money put into making it run faster, and to my surprise, I found it now runs my fibonacci benchmark faster than gcc-compiled C. Overall, Java performance has improved from horrible to tolerable. Programs are still taking a long time to start, even on a beefy machine, but to be fair, I've seen some long startup times on some C++ programs as well.
Python really beats Java in startup time, with the result that Python gets used here and Java doesn't.
Python is, however, fast enough for a great many applications. I'm just a little skeptical about it being quite as fast in certain aspects.
I see Pysco has made it into Debian Sid, this is a good sign.
Microsoft seems to pretty much ignore efforts like this because they are more interested in the future of computing, not the past, which is definitely where NT4 belongs.
Sorry, but that does not demonstrate a high level of cluefulness. 2000, XP, and all Microsoft OS products in the forseeable future, with the exception of Wince, are based on NT, just as the first 10 years of Windows was based on Dos.
Microsoft ignores efforts like this until they begin to look like they might succeed, then they go looking through their bag of dirty tricks. Unfortunately for Microsoft, they have to burn a lot of karma to attack an open-source project, and the chance of being able to stamp out the source code itself is pretty much zero.
The guy who did this did NOT compare performance against Walmart Lindows PCs. In fact, the XBox *WOULD* beat the $199 Wallyworld boxes for performance. The XBox uses a 733Mhz PIII/celeron-like CPU (same specs except a 133Mhz FSB). The Walmart PC has an 800Mhz CPU, but uses a crappy VIA C3 processor (think "PII/400 at best" performance).
Well, he said that compiling 2.4.20 on one XBox took 48 minutes, which is pathetic and far under what the nominal 733 clockrate would suggest. I don't think the C3 is as slow as that.
MS has made a machine which it isn't practical to use for cheap computing power. It's possible to use the Xbox as a PC, and a few folks will do it, but it isn't practical, and I'm sure that's just what MS was aiming for.
Well, the problem for Microsoft is that pretty soon XBox owners are going to figure out a) it really is just a PC and b) it's a lot slower than a PC, has outdated hardware, and doesn't run as many games.
From the article:
"I recompiled the Linux kernel 2.4.20 on a single node took 48 mins 30 sec"
OK, it's a 733 MHz PIII. My 1 GHz PIII here does the job in roughly 7 minutes. What explains the 6 times slowdown? Note: kernel compilation is *not* disk bound, it's basically a test of processor speed.
If that timing is accurate, even the Walmart PC's little C3 wipes XBox off the map in processing power.
There is only one possibility for Microsoft to get players to buy these things, and that is by having exclusive content. The problem is, nobody wants to give them exclusive content, the numbers just don't add up, so Microsoft ends up having to buy the company instead. Well, they can only push that one so far until the the remaining buyout targets get too expensive, and there is also an endless supply of new game startups, none of whom will see the logic of signing exclusives for the miniscule XBox market and kissing the huge PC market goodbye, probably forever.
That's because you haven't thought about it very hard. Consider that each bit you strip away from a sample takes away half the dynamic range. So if you strip away 8 bits from a 16 bit sample, you are left with 1/256th of the bandwidth of the original signal, and you still want to encode in that miniscule space every little nuance of the original signal. Got more respect now?
So the point isn't that FLAC is new... the point is that FLAC is OSS, and has joined forces with an organization backing such efforts. The SHN codec is not OSS.
It's not only that. The FLAC format is better too, for example, it embeds the checksums inside the file (duh!) and includes mp3 tags (double duh!). It has slightly better compression as well. So the bottom line is, not only freer, but better.
IMO, Linux needs games in order to "make it" in the mass market. It already has the good O/S, it has the word processing software, it has GUIs if you want them - the only thing it doesn't have is a good games library.
I agree with you. However, just be patient, it's coming. It takes time to build a whole infrastructure capable of supporting the full lifecycle of a game development project. It takes time for massive numbers of independent developers to absorb the technical background and learn the skills to come up to the same level as a pro game developer. But look here and here and tell me it isn't happening. As open source developers, one thing we have is plenty of time. That means time to get it right, time to build best of breed tools, time to build a community of first hundreds, then thousands, then tens of thousands of open source game developers. It's happening, I can assure you. Sooner than you think the worldwide programming talent pool for open source games will grow to exceed in numbers the largest commercial game company by an order of magnitude. What's more, that talent pool will include many professional game developers, working in their free time just because they love it, or they want to build their reputation. In that, game developers are no different than any other breed of open source developer.
But it takes more than programmers to make a game, it takes artists and game developers with both excellent skills and good taste. Right now, this side of the community lags way behind the programming side, but that too is a temporary situation. The artists will arrive when the tools are there, and the tools are well on their way. Note that the whole animation industry has basically switched to Linux. Sure, most of the software they're using is proprietary/expensive, but that's changing rapidly.
I don't think so. I watched a 4 min report on the Slammer Worm in CNN on saturday and they fail to mention either MS or SQL Server. It was an "internet worm", originated by some haker in the internet for the internet. For 4 min they danced around the news without any mention of Redmond or any of their products.
That's very true, and more alarming, even the online coverage doesn't put the blame squarely where it belongs. Almost all are blaming the user for avoiding patching (when we now know that even at Microsoft they can't manage to do this) and going on to recommend improved security procedures, without recommending the obvious: consider moving to a more secure operating system.
In fact, Microsoft gives you several options (at least re upgrading Windows XP Pro):...(2) will automatically download updates and notify you when they are ready to install. This option gives details on each update and gives you the option to skip all or any of the updates if you want;...
Do you have it in writing from Microsoft that they will tell you the full contents of every patch, not just what they want you to think the patch is? No? Then you *are* going to get quiet little riders in those patches, tied to things like critical security updates.
Let's be honest, Microsoft really only gives you two options: accept the patches or freeze in the dark.
Would you rather have a system where you have to manually implement every patch, or would you rather have a system where you didn't have any choices which patches were implemented?
That argument is an example of a logical fallacy called "bifurcation" - presenting two alternatives as if they were the only two alternatives, when in fact more may exist.
Somehow I keep my Debian system updated with the latest security patches without much effort, and without being forced to accept patches I don't want.
He goes on to note that SBC is not a villian for doing this - it is after all a valid patent, and that what is needed now is prior art.
If he walks, talks and quacks like a villian, he's a villian. He's acting just like any other IP thug, by mugging some little guy first. He knows exactly what he's doing, he choses to be part of the problem fostered by the monumentally stupid IP regime that increasingly runs the U.S.
"Next-generation secure computing base", hmm, that's a little long, we should just abbreviate it to "DRM".
The fact that it was something that got a lot of attention and gave rise to a lot of misunderstanding
Yes, to be sure, people do not understand why Microsoft is telling them it's supposed to make their Windows security less buggy, when it's obviously much better suited to restricting what you can do with your own computer.
Slashdot Mirror
If Linus is feeling even vaguely himself, he will not accept this patch. Ordinarily, people trying to put stuff into the kernel that a) hurts performance, and b) fixes no real problem, but c) is critical to some contrived project that seems really important to the contributor get entertainingly flamed, and then shown the door. In fact, Kevin's most likely motivation for submitting this as a Slashdot story is to marshall support for his Linux patch.
That's harsh. I see nothing wrong with redefining the goal's more modestly, and contrary to what you suggest, I haven't seen anyone pushing for Plex86 patches in mainline. Everybody knows what the process is, and it does not happen on unproven code.
I do particularly like the kernel service module as a design approach. For what I'd use this for, which is kernel debugging, this is entirely appropriate. To me, the key is a lightweight, clean design, without attempting to take over the world.
It's great to see Kevin back at it.
Plex86 is taking so very long to materialize, I wonder if it is even worth the effort being put into it. Bochs works fine, even if slow, and virtualization isn't exactly a big market. Where does Plex86 fit into all this?
You bet it's worth it. I'm really glad Kevin has been able to return to working on it. I consider him brilliant. It's really sad that Mandrake was unable to continue to sponsor his important work.
It makes a whole lot of sense to set the sights a little lower, resulting in something simpler and achievable by one or two people. Now I'll evaluate plex86 for 2.5 debugging work and see how it stacks up against User Mode Linux.
I agree with some of the above posters. I don't think the graphics are all that impressive, though I have to say that they DO look better than 90% of the linux games we have now. Any code coming over to our side is better than nothing, and maybe someone will look at this code and say "hey, I can use this to /insert really cool statement here/"
Make that 99% of the Linux games we have now. Actually, the terrain rendering is quite nice, so is the snow texture mapping. The snowboarder figure is done with taste, though not to today's typical production values. The trees suck pretty badly, but that is exactly where somebody could go in and bring the graphics up to today's standards, relying purely on the current generation of fast GPUs to handle a lot of extra splats.
The terrain rendering is expansive - it's hard to spot a backdrop, if there is one at all.
In any case, speaking as a developer of games, you can be sure I'll _never_ release anything into the GPL. Not so much because of politics but just because I can't stand the attitude of the GPL zealots who whine and moan about everything.
But you will happily read, learn from, and/or use the code written by others and released to the public?
I do would like to have a look at the src u used to do the benchmarking, I'm looking at dynamic typing issues and the tradeoff's associated with them...performance would be a good one..
Oops, heres's the rest of it, from the <=:
<=2? 1: fib(n-2) + fib(n-1);
}
public static void main(String args[]) {
int n = 22;
System.out.println("Fib of "+n+" is "+fib(n));
}
}
The jit-compiled Java ends up running faster than the gcc-compiled C probably because of better register optimization, and possibly elimination of the tail-recursion. I didn't look at the assembly code from the C this time, but every time I do, I tend to see extra instructions being generated that should have been optimized away with simple peephole optimization. Lots of room for improvement.
I'm interested in seeing the code in the three languages that you were using. I'd like to see where the bottlenecks are and see what specificly causes these results. I would think that C would be faster than Java, which would be faster than Python (but none by 100 x). I'm not saying that you're wrong, but now I'm interested in why.
Oh, and the java version:
class Fib {
static int fib(int n) {
return n<
The jit-compiled Java ends up running faster than the gcc-compiled C probably because of better register optimization, and possibly elimination of the tail-recursion. I didn't look at the assembly code from the C this time, but every time I do, I tend to see extra instructions being generated that should have been optimized away with simple peephole optimization. Lots of room for improvement.
I do would like to have a look at the src u used to do the benchmarking, I'm looking at dynamic typing issues and the tradeoff's associated with them...performance would be a good one..
Would u mind sending me them?
---------
fib.c:
---------
int fib(int n)
{
return (n<2)? 1: fib(n-1) + fib(n-2);
}
int main(void)
{
int n = 35;
printf("fib of %i = %i\n", n, fib(n));
}
---------
fib.py:
---------
def fib(n):
if(n < 2):
return 1
else:
return fib(n-1) + fib(n-2)
import psyco
psyco.bind(fib)
print fib(35)
Try it with and without the "import pysco".
It's the Batteries Included part of Python that makes it such a productive environment. Optimization is suppose to be the last step in the coding cycle. Get it write in Python first and then recode the bits that are too slow to tolerate in C.
That would be fine if Python had a more efficient C interface than it does. What's it has sucks supremely. You parse ascii text to unpack each parameter. Grief. The result of this is, you can't write just the little parts that suck the time in C, you have to wrap these in enough surrounding program to cut down the number of times you have to cross the C-Python boundary.
Mind you, I still like Python, but I shy away from it for any heavy lifting. The Python crowd really do need to look seriously at native code generation, it's just not something you can ignore forever. As it stands, I see Python as a more elegant, maintainable way of writing the kind of scripts that have traditionally be done in Bash and Perl.
Is renderman open source yet?
Renderman is a specification, not a product. There are various open-source efforts to implement the renderman specification, but they all seem to be dormant at the moment. See here.
I am, however, a little leary on the performance parity bit. Don't get me wrong, I love programming in Python, but I know from experience that it still costs a good bit to create all the dictionaries that are used for frame construction, global maniuplation, and object management.
I did a little benchmarking recently, and I can confirm that for typical algorithmic benchmarks (not heavily library or IO oriented) Python is more than 100 times slower than C/C++. There's a Python "specializing compiler" called Psyco that produces significant speedup, running my little fibonacci test around half the speed of C, very impressive.
Java on the other hand has had huge amounts of effort and money put into making it run faster, and to my surprise, I found it now runs my fibonacci benchmark faster than gcc-compiled C. Overall, Java performance has improved from horrible to tolerable. Programs are still taking a long time to start, even on a beefy machine, but to be fair, I've seen some long startup times on some C++ programs as well.
Python really beats Java in startup time, with the result that Python gets used here and Java doesn't.
Python is, however, fast enough for a great many applications. I'm just a little skeptical about it being quite as fast in certain aspects.
I see Pysco has made it into Debian Sid, this is a good sign.
A three-line chunk would probably come under fair use.
I seriously doubt that. Under the fair use doctrine of the U.S. copyright statute, it is permissible to use limited portions of a work including quotes, for purposes such as commentary, criticism, news reporting, and scholarly reports.
Which of these do you suppose your three line chunk would fall under?
This is fine for a personal or hobby site but for e-commerce, you need to write to users, not standards.
You need to write to users and standards. I hope you didn't really mean what you seemed to say.
Microsoft seems to pretty much ignore efforts like this because they are more interested in the future of computing, not the past, which is definitely where NT4 belongs.
Sorry, but that does not demonstrate a high level of cluefulness. 2000, XP, and all Microsoft OS products in the forseeable future, with the exception of Wince, are based on NT, just as the first 10 years of Windows was based on Dos.
Microsoft ignores efforts like this until they begin to look like they might succeed, then they go looking through their bag of dirty tricks. Unfortunately for Microsoft, they have to burn a lot of karma to attack an open-source project, and the chance of being able to stamp out the source code itself is pretty much zero.
The guy who did this did NOT compare performance against Walmart Lindows PCs. In fact, the XBox *WOULD* beat the $199 Wallyworld boxes for performance. The XBox uses a 733Mhz PIII/celeron-like CPU (same specs except a 133Mhz FSB). The Walmart PC has an 800Mhz CPU, but uses a crappy VIA C3 processor (think "PII/400 at best" performance).
Well, he said that compiling 2.4.20 on one XBox took 48 minutes, which is pathetic and far under what the nominal 733 clockrate would suggest. I don't think the C3 is as slow as that.
There are all kinds of issues such as MPICH's underlying communication structure (Tree, Linear, Cube, whatever).
:-)
Please explain difference between a tree, line and cube when you have 3 boxes
MS has made a machine which it isn't practical to use for cheap computing power. It's possible to use the Xbox as a PC, and a few folks will do it, but it isn't practical, and I'm sure that's just what MS was aiming for.
Well, the problem for Microsoft is that pretty soon XBox owners are going to figure out a) it really is just a PC and b) it's a lot slower than a PC, has outdated hardware, and doesn't run as many games.
From the article:
"I recompiled the Linux kernel 2.4.20 on a single node took 48 mins 30 sec"
OK, it's a 733 MHz PIII. My 1 GHz PIII here does the job in roughly 7 minutes. What explains the 6 times slowdown? Note: kernel compilation is *not* disk bound, it's basically a test of processor speed.
If that timing is accurate, even the Walmart PC's little C3 wipes XBox off the map in processing power.
There is only one possibility for Microsoft to get players to buy these things, and that is by having exclusive content. The problem is, nobody wants to give them exclusive content, the numbers just don't add up, so Microsoft ends up having to buy the company instead. Well, they can only push that one so far until the the remaining buyout targets get too expensive, and there is also an endless supply of new game startups, none of whom will see the logic of signing exclusives for the miniscule XBox market and kissing the huge PC market goodbye, probably forever.
That seems low.
That's because you haven't thought about it very hard. Consider that each bit you strip away from a sample takes away half the dynamic range. So if you strip away 8 bits from a 16 bit sample, you are left with 1/256th of the bandwidth of the original signal, and you still want to encode in that miniscule space every little nuance of the original signal. Got more respect now?
So the point isn't that FLAC is new... the point is that FLAC is OSS, and has joined forces with an organization backing such efforts. The SHN codec is not OSS.
It's not only that. The FLAC format is better too, for example, it embeds the checksums inside the file (duh!) and includes mp3 tags (double duh!). It has slightly better compression as well. So the bottom line is, not only freer, but better.
IMO, Linux needs games in order to "make it" in the mass market. It already has the good O/S, it has the word processing software, it has GUIs if you want them - the only thing it doesn't have is a good games library.
I agree with you. However, just be patient, it's coming. It takes time to build a whole infrastructure capable of supporting the full lifecycle of a game development project. It takes time for massive numbers of independent developers to absorb the technical background and learn the skills to come up to the same level as a pro game developer. But look here and here and tell me it isn't happening. As open source developers, one thing we have is plenty of time. That means time to get it right, time to build best of breed tools, time to build a community of first hundreds, then thousands, then tens of thousands of open source game developers. It's happening, I can assure you. Sooner than you think the worldwide programming talent pool for open source games will grow to exceed in numbers the largest commercial game company by an order of magnitude. What's more, that talent pool will include many professional game developers, working in their free time just because they love it, or they want to build their reputation. In that, game developers are no different than any other breed of open source developer.
But it takes more than programmers to make a game, it takes artists and game developers with both excellent skills and good taste. Right now, this side of the community lags way behind the programming side, but that too is a temporary situation. The artists will arrive when the tools are there, and the tools are well on their way. Note that the whole animation industry has basically switched to Linux. Sure, most of the software they're using is proprietary/expensive, but that's changing rapidly.
"if this info gets around enough"
I don't think so. I watched a 4 min report on the Slammer Worm in CNN on saturday and they fail to mention either MS or SQL Server. It was an "internet worm", originated by some haker in the internet for the internet. For 4 min they danced around the news without any mention of Redmond or any of their products.
That's very true, and more alarming, even the online coverage doesn't put the blame squarely where it belongs. Almost all are blaming the user for avoiding patching (when we now know that even at Microsoft they can't manage to do this) and going on to recommend improved security procedures, without recommending the obvious: consider moving to a more secure operating system.
I can't help thinking about exploding gas tanks.
In fact, Microsoft gives you several options (at least re upgrading Windows XP Pro): ...(2) will automatically download updates and notify you when they are ready to install. This option gives details on each update and gives you the option to skip all or any of the updates if you want;...
Do you have it in writing from Microsoft that they will tell you the full contents of every patch, not just what they want you to think the patch is? No? Then you *are* going to get quiet little riders in those patches, tied to things like critical security updates.
Let's be honest, Microsoft really only gives you two options: accept the patches or freeze in the dark.
Would you rather have a system where you have to manually implement every patch, or would you rather have a system where you didn't have any choices which patches were implemented?
That argument is an example of a logical fallacy called "bifurcation" - presenting two alternatives as if they were the only two alternatives, when in fact more may exist.
Somehow I keep my Debian system updated with the latest security patches without much effort, and without being forced to accept patches I don't want.
He goes on to note that SBC is not a villian for doing this - it is after all a valid patent, and that what is needed now is prior art.
If he walks, talks and quacks like a villian, he's a villian. He's acting just like any other IP thug, by mugging some little guy first. He knows exactly what he's doing, he choses to be part of the problem fostered by the monumentally stupid IP regime that increasingly runs the U.S.
The core private key is unique to the chip and is put on the chip at time of manufacture.
So the manufacturer is the only one who knows the core private key?
"Next-generation secure computing base", hmm, that's a little long, we should just abbreviate it to "DRM".
The fact that it was something that got a lot of attention and gave rise to a lot of misunderstanding
Yes, to be sure, people do not understand why Microsoft is telling them it's supposed to make their Windows security less buggy, when it's obviously much better suited to restricting what you can do with your own computer.