There's an article in the Washington Post about Marc Ewing (of RedHat fame), his wife, and the billion dollars they're now challenged with giving away.
It's a very interesting read in any case, but especially because of the financial success so many in the Free software community have been enjoying.
I'll just choose to use code I know has been well tested, reviewed by a community of people other than the authors, and is therefore a better bet than the cruft that passes for Windows drivers these days.
On machines I depend on for day-to-day activities, every bit as much as for production servers, my primary concern is stability. I have every intention of sticking with 3.3.6 since they don't really need my bugchecking effort, and I need my computer working right. Similarly, I'd gladly take an Open driver that I trusted but was a little bit slower over a flaky-but-fast closed driver (as long as we're talking about small differences in speed, say 15%).
a) The linux kernel isn't any more open a development environment than XFree is. There are a couple of gurus with commit rights. Everyone else sends patches. Most of those are rejected. It's not a formal process of approval like becoming a FreeBSD developer. But you're equally free to fork the code in any of those cases -- the unwashed public always has full access to everyone's latest stuff.
b) Hiding behind cruft is not a way to fight closed source drivers. They've been offered before, many times. And the response has been increasingly negative. I think we'll continue to write our own, open drivers, and write better ones. I want code I can review running with priviledges on my machine. How about y'all?
c) A cleaner driver model will make it easier to write Free drivers too.
d) Let's keep things positive here, huh?
e) "uncommon hardware, (alpha,ppc)" will rise to crush puny pathetic PCs once and for all:)
Do you have any figures for actual fill rates and triangle drawing rates
All those figures are irrelevant anyhow:) the only thing that matters is real-world fps on real-world games. And you can't tell how fast they are on real games till you see them... (haven't even gotten a GeForce yet, I'll have to work on that).
with release dates for the hardware
Anything I could say (besides the fact it would be breaking peoples' confidences in me) might very well be wrong. For example, lot of what 3dfx said (under NDA) to developers at GDC '99 about the geometry acceleration abilities of the Voodoo4/5 turned out to be wrong, because of last-minute design changes.
Cycle time is about 9 months (instead of Intel's 18).
This should be no surprise: Intel can adjust their R&D budget to hit Moore right on the nose. They haven't had much competition, so there's no reason for them to spend money going any faster. But the 3D hardware market is cutthroat (and no there hasn't been any reduction in competition -- all the key chipset manufacturers are still out there, with the exception of Rendition, who disappeared a long time ago). These guys are pushing their cycle time about as fast as possible -- they're basically looking at a few months of design, then fab on each generation...
Their stuff is easily as complex (element-count wise, I can't say if it's easier to harder to design) as the big CPU makers....
in the Carnegie Mellon operating systems course (mostly taken by juniors/seniors, tho it isn't specifically a "3rd year" course), you don't start with any operating system.
The course is taught on SPARC emulators, which run on (you guessed it) SPARCs and make the architecture a bit more manageable. But you write the operating system... that's kind of the point:)
It's not all that complex an operating system, nice and straightforward and unix-ish, but it's a hell of a lot for one semester. The course is done in project groups, and it has a reputation as about the hardest class out there.
I've had friends in the course get back after a week almost exlusively in the lab. They show up friday afternoon in a zombie like state... --"What did you write this week in OS?" --"Huh? Oh, inter-process data streams. You know, pipes" --"Neat" --"pipe pipe pipe! pipe! PIPE! PIPE!" [nervous sobs]
that if we don't like laws, we can just ignore them? Even if the laws are perfectly constitutional and backed by centuries of precedent?
The fact that it's illegal to duplicate recordings isn't anything new. And it doesn't take away any of my freedom (except where my freedom would infringe upon others' freedom, namely the owners of the copyright).
Using DeCSS to decrypt your DVD and play it in Linux is not wrong.
Copying mp3 files without compensating the copyright holders is wrong.
There's a world of difference. As a community, we need to grow up and accept that.
...
I'm a paranoid m********ker and I'm rabid about protecting my privacy.
I detest consumerism.
I avoid debt.
I work way more than 10 hours a day.
I vote, and I use my vote (and my voice) to protect my rights (how many of the rest of you vote? I bet more of you should).
And theft is still wrong. You don't have to like it, and you don't have to like the industry. Theft is not the answer.
and as soon as we cross the line where we are breaking the law (even in so trivial a way as playing an mp3 file we haven't paid for the CD of), we give validity to their arguments.
I had a conversation with Dean Paul Fowler here at CMU, about the line between protecting the University from lawsuits by the industry and academic freedom. One of the things he pointed out is that whenever an industry of that size goes to court or Congress and says, "We're losing money because of this illegal activity," you can bet there's going to be a rapid response from those with the power. And that's going to affect everyone else. We have to pick our fights, and make sure we're really on the moral high ground here.
We have to be able to respond with an unconditional, "No laws are being broken but our rights are being violated." I can't simultaneously tell the industry to go screw itself and apologize for my cohorts who are stealing their product (however much money they make despite that theft).
It's a shame that illegal search-and-seizure of a legitimate business must be equated with stealing the intellectual property of the music industry.
I'm sorry.
I don't like the MPAA or the RIAA either.
And they're just damn wrong about DeCSS, as we all know.
But they do own the copyright to all that music that people steal. And that's illegal, and undefendable. I don't like the big music companies any more than you do. But crime is not the answer -- if we're going to preserve our personal freedoms, we have to be above such things.
People, if you don't like big media companies that screw artists and consumers alike, don't buy from them. You're not giving the artists a cent, we all know, by buying the CDs. Go to the concerts (on tour is how most artists make money). Buy CDs from small indie music houses that focus on the artists, and on doing what's different, instead of more of the same drivel. But don't steal. That just gives them more ammunition and reason for laws that take away privacy.
If you want a Free implementation of an ARM-compatible CPU, just turn to anyone in the CMU ECE dept. who has taken 18-347 (the 2nd level processor-design course). The semester-long project in that course is to implement an ARM-compatible CPU in Verilog. Structural in the fall, procedural in the spring:)
They don't synthesize them (no real point), but they run them in simulation, and you can write assembly or use the GNU ARM compiler to make code for it. I believe (haven't taken the course yet) they give you a few of the more complex parts to save time (I think they give you the FPU). You write the rest in your project groups.
Just have to talk someone in the class into releasing their code under a Free license. Have to check about any restrictions on any code they were given to use, tho
It's very easy to fab chips these days. Lots of companies are out there doing custom chips for various applications (ASICs, application-specific integrated circuits). All of those companies have a premium on fast design, and getting the hardware right on the first fab run (since that's a very expensive and time consuming step). And all of these companies use outside fabs to actually make the chips.
So you can take these OpenRISC designs over to your favorite fab company, and just have a bunch made. Motorola does this (for pretty big orders). There are quite a few others. It's not even that expensive; professors here at CMU get their experimental designs fabbed (in small quantities) when they're ready.
But what's even cooler is to get a nice Xilinx or Altera FPGA, and just download the chip on there. That's how the designers work. It's not the most price effective (a good enough FPGA board will cost you a couple k, and you need the synthesis software, and a good copy of Verilog or VHDL) but it's way more fun, since you can play with the chip yourself and change it around. We did this (with a pretty simple chip design) in my 18-240 class.
What's more important is that there's plenty of competition for fabbing chips, so the market is good for consumers (rather unlike the traditional chip market). So you're likely to get a considerably better deal. You can't get the absolute latest.18 micron copper process (unless you wann pay IBM to fab for you, and I bet they're steep). But lots of guys have pretty good.25u stuff. Band together with some friends and get an order going!
[sigh] too bad the OpenRISC is all VHDL and I only know Verilog, or I'd take it over to the lab here and see if I could get it on the university's FPGAs:)
But this could end up really changing the way hardware is made and sold. Remember, there are a lot of university ECE departments cranking out good work, and looking for research projects to work on (check out the OpenRISC 2000 on the OpenCores website). The origin of all of UNIX, and more recently of Linux, was people at university CS depts. looking for fun stuff to hack on... all it takes is projects in CVS for the collaboration to begin...
on recent ANSI committee developments, such as the deprecation of C-style casting (in favor of static_cast<>(), which in my understanding has such a long name, along with things like reinterpret_cast<>() so people would know to avoid using it)?
Will the ANSI committee leave C++ the way we knew it (obviously stuff like exceptions was a bit of a fiasco and all...)? I think at this point C++ is so popular and has such an established user base that users will be alienated by major fundamental changes to the language that start to break their old programs, or majorly affect fundamental style issues.
If someone wants to find a NewsBytes editorial email, I'll send the same email to them.
The main thing is to respond. And I don't think we should only let the big guns of the community respond (though of course their help will be very important).
Send mail yourselves. It doesn't really even matter if it's to the right guys -- CompCurr has an obligation to report the news correctly, and if NewsBytes is giving them bad wire feeds, perhaps they should junk the service. News companies need to stand up behind the stories they report.
This one was about the dumbest I've read in a long time:)
Actually I hear they're fixing the Pixmap engine
on
Death of CDE & Motif?
·
· Score: 1
If you think about it, there's no reason a theme based on the Pixmap engine should be any slower than anything else -- it's doing all the same things, rendering buttons and toolbars and whatnot.
It turns out that the Pixmap code was pretty braindamaged -- it was based on Imlib (which is not known for beauty or speed of code), and it did some dumb things. Somehow, for example, it ended up rendering everything three times.
It's being rewritten based on GDXPixbuf, the new GNOME imaging library. It will be fast, light, and much more capable. All your Pixmap themes should become suddenly very happy:)
I've mirrored stuff before (the Star Wars trailer... served like 8 gigs the day the first one game out). Never had a problem.
Except if Loki gets cheesed at me for IP violation, i'm not breaking CMU's guidelines. I can run nonprofit websites as long as the use isn't excessive. We're talking about small bursts here over a day or so. It's not a big deal. At least I hope he doesn't think so...
I can also write code in ML that can be proven correct at compiletime, since it's statically typed and lexically scoped (Java can still come up with an exception and die on you).
So my question to you is: How are your languages so magic if none of the software I use on a daily basis uses them, or seems to miss their properties?
Some guys here at CMU wrote a TCP/IP stack in ML that was provably correct. It took them a whole year. Was it worth it? You could write a whole operating system in that time!
...
The stack-based ISA for Java is slow. It doesn't map well onto actual processors. It's a big reason that even JITC'd Java isn't very fast.
There's no reason not to use a language like Java with slightly stronger typing than C++ (although there are good reasons to use C++; there are powerful things C++ can do that Java can't). But it should be compiled, even if "compilation" is something that happens the first time you run a program, and it should be compiled from a more intelligent format than a nonexistent ISA. Why not distribute source code after the frontend has run on it, with all the symbols resolved and the syntax broken up into lower-level constructs? That would be as hard to reverse-engineer as assembly, and significantly moreso than Java classes (which leave way too much info in there).
...
Being able to state with supreme confidence that this type of bug does not exist in my code because it has been rigorously proven is helpful. You really should be more concerned with running correct code than running "fast" code.
Except for the fact that we've gotten everything done so far by writing fast code, and testing it to see that it's reasonably bug free. Proving code with Java is still quite hard, and writing code at all in ML is very hard.
Empirically, companies will trade off getting the software written for having it proven; they've been doing things that way for quite a long time. Java certainly won't change that.
I can write fast C (or C++ if you stay away from the evil slow features) code.
Everything I do in Java is bloody slow.
I do believe fundamentally that some sort of per-machine compilation is in fact ideal -- the C compiler could do clever stuff if it new the exact cache architecture of your machine and compiled your programs from some intermediate (say parsed and desymbolized) representation when you ran them (or maybe just the 1st time you ran them).
(all the slackware people in the crowd say "bwaahahahaha! I did compile my programs for my own machine!":-)
But I think the dumbness of Java -- the funky GC, the dumb dumb dumb RTTI, will always make it slow. For that matter, Java uses a dumb fake-o instruction set that's not a particularly good representation of the information needed by a compiler. Why not give your JITC something closer to the source rather than a binary for a machine that doesn't even exist ?!?
...
Ditzel said something very significant when he introduced Crusoe: (i'm paraphrasing) "The reason we haven't talked openly about this before is we didn't want to boast before we could prove we've done it". Ditzel stood there and said "We've got a chip that does on-chip JIT architecture translation, and does it to run as fast as any other chip out there, and here's the proof".
The Java people have been claiming for a long time that they could write faster code than the C compiler with JITC.
Java has gotten better than when it started, it's true.
But it still can't hold a candle to gcc -O2.
My message to the Java world: I spend too much on my computers to waste time running slow code. Call me back when you can actually demonstrate your claims.
It provides no functionality not in C++, doesn't make writing the same program in C++ significantly easier, and is butt-slow to boot.
Not exactly winning characteristics, eh?
I don't care if it's faster than when it was introduced. I care it's still way slower than compiled code.
Do the benchmarks yourself. Write a simple program the same way (same algo/data structure) in C++ and in Java. Run it with the best JITC you can find.
Do you think gamers who spend big bucks on fast CPUs and killer graphics cards will look kindly on you wasting their money by writing slow code?
...
I don't agree with everything Carmack does.
But offloading work from compiletime to runtime doesn't seem like a good idea at all if you're working on a system that's pushing the speed envelope already, by very nature.
Slashdot Mirror
but I'll just put it here.
There's an article in the Washington Post about Marc Ewing (of RedHat fame), his wife, and the billion dollars they're now challenged with giving away.
It's a very interesting read in any case, but especially because of the financial success so many in the Free software community have been enjoying.
Debian!
:)
Everyone's favorite not-a-bit-like-RedHat, completely non-commercial (well, except for spin-offs like Corel), power-user distro
I'll just choose to use code I know has been well tested, reviewed by a community of people other than the authors, and is therefore a better bet than the cruft that passes for Windows drivers these days.
On machines I depend on for day-to-day activities, every bit as much as for production servers, my primary concern is stability. I have every intention of sticking with 3.3.6 since they don't really need my bugchecking effort, and I need my computer working right. Similarly, I'd gladly take an Open driver that I trusted but was a little bit slower over a flaky-but-fast closed driver (as long as we're talking about small differences in speed, say 15%).
a) The linux kernel isn't any more open a development environment than XFree is. There are a couple of gurus with commit rights. Everyone else sends patches. Most of those are rejected. It's not a formal process of approval like becoming a FreeBSD developer. But you're equally free to fork the code in any of those cases -- the unwashed public always has full access to everyone's latest stuff.
:)
b) Hiding behind cruft is not a way to fight closed source drivers. They've been offered before, many times. And the response has been increasingly negative. I think we'll continue to write our own, open drivers, and write better ones. I want code I can review running with priviledges on my machine. How about y'all?
c) A cleaner driver model will make it easier to write Free drivers too.
d) Let's keep things positive here, huh?
e) "uncommon hardware, (alpha,ppc)" will rise to crush puny pathetic PCs once and for all
Do you have any figures for actual fill rates and triangle drawing rates
:) the only thing that matters is real-world fps on real-world games. And you can't tell how fast they are on real games till you see them ... (haven't even gotten a GeForce yet, I'll have to work on that).
All those figures are irrelevant anyhow
with release dates for the hardware
Anything I could say (besides the fact it would be breaking peoples' confidences in me) might very well be wrong. For example, lot of what 3dfx said (under NDA) to developers at GDC '99 about the geometry acceleration abilities of the Voodoo4/5 turned out to be wrong, because of last-minute design changes.
Cycle time is about 9 months (instead of Intel's 18).
This should be no surprise: Intel can adjust their R&D budget to hit Moore right on the nose. They haven't had much competition, so there's no reason for them to spend money going any faster. But the 3D hardware market is cutthroat (and no there hasn't been any reduction in competition -- all the key chipset manufacturers are still out there, with the exception of Rendition, who disappeared a long time ago). These guys are pushing their cycle time about as fast as possible -- they're basically looking at a few months of design, then fab on each generation...
Their stuff is easily as complex (element-count wise, I can't say if it's easier to harder to design) as the big CPU makers....
in the Carnegie Mellon operating systems course (mostly taken by juniors/seniors, tho it isn't specifically a "3rd year" course), you don't start with any operating system.
... that's kind of the point :)
The course is taught on SPARC emulators, which run on (you guessed it) SPARCs and make the architecture a bit more manageable. But you write the operating system
It's not all that complex an operating system, nice and straightforward and unix-ish, but it's a hell of a lot for one semester. The course is done in project groups, and it has a reputation as about the hardest class out there.
I've had friends in the course get back after a week almost exlusively in the lab. They show up friday afternoon in a zombie like state...
--"What did you write this week in OS?"
--"Huh? Oh, inter-process data streams. You know, pipes"
--"Neat"
--"pipe pipe pipe! pipe! PIPE! PIPE!" [nervous sobs]
that if we don't like laws, we can just ignore them? Even if the laws are perfectly constitutional and backed by centuries of precedent?
The fact that it's illegal to duplicate recordings isn't anything new. And it doesn't take away any of my freedom (except where my freedom would infringe upon others' freedom, namely the owners of the copyright).
Using DeCSS to decrypt your DVD and play it in Linux is not wrong.
Copying mp3 files without compensating the copyright holders is wrong.
There's a world of difference. As a community, we need to grow up and accept that.
...
I'm a paranoid m********ker and I'm rabid about protecting my privacy.
I detest consumerism.
I avoid debt.
I work way more than 10 hours a day.
I vote, and I use my vote (and my voice) to protect my rights (how many of the rest of you vote? I bet more of you should).
And theft is still wrong. You don't have to like it, and you don't have to like the industry. Theft is not the answer.
and as soon as we cross the line where we are breaking the law (even in so trivial a way as playing an mp3 file we haven't paid for the CD of), we give validity to their arguments.
I had a conversation with Dean Paul Fowler here at CMU, about the line between protecting the University from lawsuits by the industry and academic freedom. One of the things he pointed out is that whenever an industry of that size goes to court or Congress and says, "We're losing money because of this illegal activity," you can bet there's going to be a rapid response from those with the power. And that's going to affect everyone else. We have to pick our fights, and make sure we're really on the moral high ground here.
We have to be able to respond with an unconditional, "No laws are being broken but our rights are being violated." I can't simultaneously tell the industry to go screw itself and apologize for my cohorts who are stealing their product (however much money they make despite that theft).
It's a shame that illegal search-and-seizure of a legitimate business must be equated with stealing the intellectual property of the music industry.
I'm sorry.
I don't like the MPAA or the RIAA either.
And they're just damn wrong about DeCSS, as we all know.
But they do own the copyright to all that music that people steal. And that's illegal, and undefendable. I don't like the big music companies any more than you do. But crime is not the answer -- if we're going to preserve our personal freedoms, we have to be above such things.
People, if you don't like big media companies that screw artists and consumers alike, don't buy from them. You're not giving the artists a cent, we all know, by buying the CDs. Go to the concerts (on tour is how most artists make money). Buy CDs from small indie music houses that focus on the artists, and on doing what's different, instead of more of the same drivel. But don't steal. That just gives them more ammunition and reason for laws that take away privacy.
though you can use them to simulate code.
Students write complete Verilog descriptions of the processor, which can by synthesized on an FPGA or sent off to a fab to make "real" chips.
ARM distributed simulators so people can verify that their code runs on the chip without actually having one.
If you want a Free implementation of an ARM-compatible CPU, just turn to anyone in the CMU ECE dept. who has taken 18-347 (the 2nd level processor-design course). The semester-long project in that course is to implement an ARM-compatible CPU in Verilog. Structural in the fall, procedural in the spring :)
They don't synthesize them (no real point), but they run them in simulation, and you can write assembly or use the GNU ARM compiler to make code for it. I believe (haven't taken the course yet) they give you a few of the more complex parts to save time (I think they give you the FPU). You write the rest in your project groups.
Just have to talk someone in the class into releasing their code under a Free license. Have to check about any restrictions on any code they were given to use, tho
It's very easy to fab chips these days. Lots of companies are out there doing custom chips for various applications (ASICs, application-specific integrated circuits). All of those companies have a premium on fast design, and getting the hardware right on the first fab run (since that's a very expensive and time consuming step). And all of these companies use outside fabs to actually make the chips.
.18 micron copper process (unless you wann pay IBM to fab for you, and I bet they're steep). But lots of guys have pretty good .25u stuff. Band together with some friends and get an order going!
:)
So you can take these OpenRISC designs over to your favorite fab company, and just have a bunch made. Motorola does this (for pretty big orders). There are quite a few others. It's not even that expensive; professors here at CMU get their experimental designs fabbed (in small quantities) when they're ready.
But what's even cooler is to get a nice Xilinx or Altera FPGA, and just download the chip on there. That's how the designers work. It's not the most price effective (a good enough FPGA board will cost you a couple k, and you need the synthesis software, and a good copy of Verilog or VHDL) but it's way more fun, since you can play with the chip yourself and change it around. We did this (with a pretty simple chip design) in my 18-240 class.
What's more important is that there's plenty of competition for fabbing chips, so the market is good for consumers (rather unlike the traditional chip market). So you're likely to get a considerably better deal. You can't get the absolute latest
[sigh] too bad the OpenRISC is all VHDL and I only know Verilog, or I'd take it over to the lab here and see if I could get it on the university's FPGAs
But this could end up really changing the way hardware is made and sold. Remember, there are a lot of university ECE departments cranking out good work, and looking for research projects to work on (check out the OpenRISC 2000 on the OpenCores website). The origin of all of UNIX, and more recently of Linux, was people at university CS depts. looking for fun stuff to hack on... all it takes is projects in CVS for the collaboration to begin...
on recent ANSI committee developments, such as the deprecation of C-style casting (in favor of static_cast<>(), which in my understanding has such a long name, along with things like reinterpret_cast<>() so people would know to avoid using it)?
Will the ANSI committee leave C++ the way we knew it (obviously stuff like exceptions was a bit of a fiasco and all...)? I think at this point C++ is so popular and has such an established user base that users will be alienated by major fundamental changes to the language that start to break their old programs, or majorly affect fundamental style issues.
I was given the address of the editor of Newsbytes by the fine people at ComputerCurrents.net.
Her name is Wendy Woods, wendy@newsbytes.com
I don't enjoy poster her personal email here, but she's an editor; she needs to take responsibility.
I agree in retrospect. You may well be right.
:)
If someone wants to find a NewsBytes editorial email, I'll send the same email to them.
The main thing is to respond. And I don't think we should only let the big guns of the community respond (though of course their help will be very important).
Send mail yourselves. It doesn't really even matter if it's to the right guys -- CompCurr has an obligation to report the news correctly, and if NewsBytes is giving them bad wire feeds, perhaps they should junk the service. News companies need to stand up behind the stories they report.
This one was about the dumbest I've read in a long time
...
Oh, and M$ isn't behind this. Don't be absurd.
Send mail to the editor.
Be polite, but set them straight.
If you think about it, there's no reason a theme based on the Pixmap engine should be any slower than anything else -- it's doing all the same things, rendering buttons and toolbars and whatnot.
:)
It turns out that the Pixmap code was pretty braindamaged -- it was based on Imlib (which is not known for beauty or speed of code), and it did some dumb things. Somehow, for example, it ended up rendering everything three times.
It's being rewritten based on GDXPixbuf, the new GNOME imaging library. It will be fast, light, and much more capable. All your Pixmap themes should become suddenly very happy
I've mirrored stuff before (the Star Wars trailer ... served like 8 gigs the day the first one game out). Never had a problem.
...
Except if Loki gets cheesed at me for IP violation, i'm not breaking CMU's guidelines. I can run nonprofit websites as long as the use isn't excessive. We're talking about small bursts here over a day or so. It's not a big deal. At least I hope he doesn't think so
How about that, wu-ftpd maintained the connections through the '/etc/init.d/wu-ftpd restart'.
That's awesome!
Go, wu-ftpd!
Sorry to the 6 people on right now, i've gotta restart the ftpserver to raise the limit from 10 to 150 users....
I've set up a mirror at
ftp://templestowe.res.cmu.edu/pub/lokiga mes/
I notified Loki of this by email, and told them if they request me to take down the mirror, I will.
Till then, enjoy.
I can also write code in ML that can be proven correct at compiletime, since it's statically typed and lexically scoped (Java can still come up with an exception and die on you).
So my question to you is: How are your languages so magic if none of the software I use on a daily basis uses them, or seems to miss their properties?
Some guys here at CMU wrote a TCP/IP stack in ML that was provably correct. It took them a whole year. Was it worth it? You could write a whole operating system in that time!
...
The stack-based ISA for Java is slow. It doesn't map well onto actual processors. It's a big reason that even JITC'd Java isn't very fast.
There's no reason not to use a language like Java with slightly stronger typing than C++ (although there are good reasons to use C++; there are powerful things C++ can do that Java can't). But it should be compiled, even if "compilation" is something that happens the first time you run a program, and it should be compiled from a more intelligent format than a nonexistent ISA. Why not distribute source code after the frontend has run on it, with all the symbols resolved and the syntax broken up into lower-level constructs? That would be as hard to reverse-engineer as assembly, and significantly moreso than Java classes (which leave way too much info in there).
...
Being able to state with supreme confidence that this type of bug does not exist in my code because it has been rigorously proven is helpful. You really should be more concerned with running correct code than running "fast" code.
Except for the fact that we've gotten everything done so far by writing fast code, and testing it to see that it's reasonably bug free. Proving code with Java is still quite hard, and writing code at all in ML is very hard.
Empirically, companies will trade off getting the software written for having it proven; they've been doing things that way for quite a long time. Java certainly won't change that.
@#$% theory.
:-)
I can write fast C (or C++ if you stay away from the evil slow features) code.
Everything I do in Java is bloody slow.
I do believe fundamentally that some sort of per-machine compilation is in fact ideal -- the C compiler could do clever stuff if it new the exact cache architecture of your machine and compiled your programs from some intermediate (say parsed and desymbolized) representation when you ran them (or maybe just the 1st time you ran them).
(all the slackware people in the crowd say "bwaahahahaha! I did compile my programs for my own machine!"
But I think the dumbness of Java -- the funky GC, the dumb dumb dumb RTTI, will always make it slow. For that matter, Java uses a dumb fake-o instruction set that's not a particularly good representation of the information needed by a compiler. Why not give your JITC something closer to the source rather than a binary for a machine that doesn't even exist ?!?
...
Ditzel said something very significant when he introduced Crusoe: (i'm paraphrasing) "The reason we haven't talked openly about this before is we didn't want to boast before we could prove we've done it". Ditzel stood there and said "We've got a chip that does on-chip JIT architecture translation, and does it to run as fast as any other chip out there, and here's the proof".
The Java people have been claiming for a long time that they could write faster code than the C compiler with JITC.
Java has gotten better than when it started, it's true.
But it still can't hold a candle to gcc -O2.
My message to the Java world: I spend too much on my computers to waste time running slow code. Call me back when you can actually demonstrate your claims.
It provides no functionality not in C++, doesn't make writing the same program in C++ significantly easier, and is butt-slow to boot.
Not exactly winning characteristics, eh?
I don't care if it's faster than when it was introduced. I care it's still way slower than compiled code.
Do the benchmarks yourself. Write a simple program the same way (same algo/data structure) in C++ and in Java. Run it with the best JITC you can find.
Do you think gamers who spend big bucks on fast CPUs and killer graphics cards will look kindly on you wasting their money by writing slow code?
...
I don't agree with everything Carmack does.
But offloading work from compiletime to runtime doesn't seem like a good idea at all if you're working on a system that's pushing the speed envelope already, by very nature.