Of course it's true that it should be boring, rigorous and correct, but right now it can't be. The first few thousand years of bridge building, they REALLY DID just build it and have guys walk across it until it collapsed, then rebuild it.
If you told someone to build a sky-scraper with only knowledge of the first 50 years of architecture to work on, it would be a really big FAIL.
And computer software can be many times more complex than anything else humanity's ever accomplished. It's virtually impossible to get it ALL, so we build in layers. The analogy would be trying to build a bridge to Hawaii. You'd build out a little way, test, make sure stuff works, re-enforce it, then build on what's already been built. Nobody could do the entire trip, but between different techniques, building on each others work, and some very crafty, creative artistic thought--it just might be doable (I'm not saying I'd want to USE it).
There are very few tasks in today's workplace that require as much thought as programming, and for most problems there is no "correct" solution. A guy building a high performance 3-d game can't use a library built to be readable over fast. I good server can't use a library built for speed, scalability and maintainability or more important.
Software engineering can't even build on the other engineering disciplines--it's too different so we're starting over from scratch.
So yeah, until we've been programming for a thousand years or so, I don't know if it's fair to expect to see the same kind of discipline.
So, I'm sure, are a lot of things I don't recognize, like designing a sky-scraper or space shuttle.
Programming is an art, Anyone can follow instructions and follow an existing style or try to paint a realistic scene, but to come up with a skilled interpretation that really conveys a meaning takes a better painter. To bring together 20 painters, outline a collaboration and manage the production of some giant, detailed interpretation takes a master--at this point natural talent starts to mean more than training, and no level of training can improve someone without talent.
Anyone can write a small program. You can fit 20 generic programmers in a room and have them each write a small program. You might even be able to get them to join the programs somewhat-properly, but the whole thing will never go smoothly.
One or two really good programmers will probably out-produce 20 people that "know how to program".
How many amateur painters do you need to create something like the sistine chapel?
Just because most people can't see the art that allows large programs to work doesn't mean it's not there. In fact, most people can't tell any type of good art from bad without some training.
We do backups, but if we never do a restore, we don't really know that the restore procedure will work. If you REALLY want to make your downtime minimal, you occasionally test your restore procedure.
I'd like to suggest that any life critical application like this be forced, at least one day a month, to run without computers.
If it causes them to hire another employee, good--we need more employment. It should also help them gauge how many extra people they will need to handle a situation where the computer services are unavailable.
Computers are nice, the internet is nice, email is nice, NONE of these should be required for the normal functioning of a country--it's too big a vulnerability. We already know the effects of an EMP, do we really want a single attack to be able to shut down all the hospitals in a state?
What's the obsession these days with calling observations "laws"?
Moore's law is simply an observation, as is this. Actually software will be as slow as hardware of the period allows, rarely faster. Can we call this Bill's Law? Note the relationship between Moore's and Page's is obvious when you consider Bill's law.
Hmph, it's all just observations that happen to hold true for a short period. If that period happens to be 20 years, us short-lived humans extrapolate it to a constant like "Housing prices will always rise".
Not that I really care, but it seems to be an insult to people who actually discover real laws of nature an physics to have a casual observation given as much verbal weight.
What motivates me is the fact that they can install a keylogger and scan for passwords after you type something like "wamu.com". Since I don't trust ANYTHING to detect rootkits, I've just completely stopped using windows to access anything financial... No credit cards, nothing.
Not that Linux/Macs are invulnerable, but at least they don't default to a state equivalent to the swiss cheese of security.
Thank you! Holding down shift while I booted the mac worked, I was able to create my 10gb msdos partition and will be able to play Oblivion as soon as I can figure out the driver situation.
Note: this makes Apples recomendation to wipe/reinstall even more appropriate for this topic!
> I meant for the specific case of knowing whether to inline a function or not. Collecting metrics for that seems like a big overhead considering the benefit.
I know it collects various metrics, but the big deal right now is JIT compiling. My feeling is there is a lot of room for improvement with the JVM--The JIT compiler is only a few years old.
Then there are the potential big improvements that could jump it above most assembly language such as Microcode in a CPU or co-processor with the ability to process Java bytecode instructions natively--remember bytecode is MUCH more compact than the x86 assembly instruction set. A powerful, optimized CPU should be able to do much more with it than with x86 code because it wouldn't have to spend so much effort trying to move code in and out of caches--less data does significantly more work.
In fact, did you know that even in the early 90's, excel and Word, even though they were written in C, used an embedded bytecode VM for code size? (I forget where I heard that, it was when Java first appeared on the scene, so I really should check my references).
I'm not half as vested in this as I sound--It's just that the OP put out that C can't be beat, and I really think a lot of people miss the advantages of an active runtime. I get the feeling that people think Java is like 100x slower, and yet many of the same people will use Ruby which actually IS 100x slower. Confuses me a little.
>>Also, how do you prove that pointers haven't modified the values you depend on without checking each one?
>>The same way that the runtime would do it.
The java runtime doesn't have to because it doesn't allow arbitrary pointers to memory. I do kind of wonder about C# and if it affects performance optimizations.
>Is that improvement worth it when you have to constantly gather statistics about every function call? There's two sides to this coin, you know. Does Java implement that?
Yes, Java currently collects runtime statistics so that it knows which calls might benefit from compiling to machine language.
>How would it prove that the two paths don't interact, in a way which can't be done by a compiler? The compiler can also simulate the running of code.
I admit this one is reaching a bit. You can do a lot of compile-time optimization, but you could use runtime statistics to show which functions might benefit from their own thread.
>I looked, and it's a bit weird that the results for C and C++ often differ by a lot (which makes me think the programs are not that optimized, as for small programs like that it should be trivial to make C and C++ as fast as each other).
Since the programs are submitted by language advocates and repeatedly revised, I'm guessing none of them have really big obvious time-sinks.
I found a lot of those results strange as well--the compiler used often seemed to have more of an effect than the language! There is also one case where functional languages are far faster than C or Java.
But notice that there are very few edge cases where C is a few times quicker, and mostly they are within a few percent. This is with all Java's VM overhead you mentioned above. It won't take but a few small incremental improvements before Java is regularly beating C--and C's so optimized already I'm not sure how much more can be done.
If you add heap allocation of small objects (Very common with good OO code), you may find that Java starts to blow C out of the water (at least C using standard malloc). 99% of Java's heap allocation should perform like C's stack allocation, it uses some very neat tricks to accomplish that. I'd actually like to test this sometime, but I don't write much C code these days--not since the early 90's.
I'm guessing multiple small allocations are what makes the thread-ring test prefer functional languages over the best C/Java times by a factor of 10x+ though.
Yes, you are correct. If you were to make C run in a VM and remove pointers (for improved optimization, with pointers around it's harder for the VM to know what can and can't change at runtime). You might also make it cleaner while you're at it, remove stupid compiler tricks like header files. Make it OO as well with memory management (you might as well now that you've got a VM there, it'll be a good deal more efficient than malloc/free for heap memory).
Yes, you can improve C. Someone should look into that.
Exactly, now do it for every single function, automatically determining (by call count and mutability of external references) if it makes sense or not. Now you DO have a runtime.
Also, how do you prove that pointers haven't modified the values you depend on without checking each one?
And that's just one of hundreds of things that are possible with a VM, none of which you can do with native code.
--Compiling code to native for a given state of a variable who's state rarely changes, eliminating calculations on that variable as though it was a constant. --Compiling a second instance of that method if the variable DOES change, being able to alternate between which of the two you call at will. --Inlining code like that (or not) based on runtime statistics. --Taking code written as single-threaded and throwing multiple threads at it when it determines that two paths don't interact. (This could be done at compile time as well, but could be done more efficiently with code profiling information in memory.) --Improving the efficiency without recompiling (Or, you could look at Java as ALWAYS recompiling to machine language)
In fact, that may be the point that the C people here are missing. How can C possibly compete with a language that compiles to machine language with more information than the C compiler has at compile time?
Currently C keeps up (Most benchmarks seem to have a few C compilers running faster than java and a few slower, but the difference is often under 10% both ways) but C is on it's umpteenth year of optimization, whereas the JVM has only been compiling for a few years now and has a lot of improving to do...
Look at some of those results (The best code submitted by expert programmers for each language)--Java and C are always in the top few, C is almost always a few ticks quicker, but virtually tied.
If you think the C code must suck, please help C win by improving their code--I'm fairly sure it's already been streamlined past what a mortal programmer can improve in most of those languages. Until someone improves these I'm going to go with C and Java being the same speed, but Java improving more rapidly.
Let's say it's called 1000 times with the same parameters, it could be short-circuited to simply insert a 6 instead of calling the funciton.
The next day, it's called 1000 times with 1,5,5000.
After analyzing ALL inputs (including references from within the method to outside objects) It could be short-circuited to return 5006.
This is not hard within the JVM, it is virtually impossible within C. This is why you are having trouble comprehending what the JVM can do--I can't blame you, it takes a while to grok the difference between code running natively and code that can be analyzed at runtime.
>The 'const' function attribute does that and works fine
Really?
I don't think you get it. I'm talking about a regular function that takes, say a and b and returns the sum of a and b. Can C really notice that you happen to be calling it with 3,7 a lot and cache the return value of 10, then the next day notice that you are calling it with 1023,2042 and return 3065?
Or can C notice that you almost always call a function with a parameter that causes a particular path through that function, then compile (to binary, not bytecode) a version of that function that contains only code used in that path and use it for a particular sub-set of parameters?
If so, C has changed a lot since the last time I used it.
A program run by a VM has much more potential than one run without.. currently we are only scratching the surface of what can be done and java is already running at the same speed as C! (Well faster than some compilers, slower than others for a given solution--but Java is rarely more than a couple percent off)
The functional languages seem to have it locked up, or perhaps their C implementation needs you to step up and fix it.
There is no reason any other compiler couldn't put out code as good as C, better in fact since C allows pointers (which stops the compiler from making quite a few optimizations). It's just that C tends to be easier to hand-optimize right now (just like assembly is easier than C). That doesn't make assembly better for 99% of the cases though, and the same could be said of C.
> So for all the non-volatile stuff, the compiler can perform the same static analysis that a Java/C# compiler does to decide whether a function has your specified behavior or not.
No it can't. It can't recognize that a function happened to be called 30 times in the last second with the parameters (1, 5, "Hello") and returned 17, and just return 17 for those values--and the next day, do the same thing for different values.
Sure you could program it to, but it would all be your code--C cannot do it for you on every single function, it wouldn't make sense (then C would need a runtime like java--it would no longer be C)
Also--the language itself would make this impossible. Java can know for sure that nothing is modified without the runtime's knowledge. There are no pointers in Java, and the runtime can analyze a class to ensure that things it relies on haven't changed. C could not do that generically, You would have to double the size of every method to get that kind of functionality.
> And what's to stop people from writing a linker which does some "post-production" optimizations on the object code?
You'd have to relink. I suppose linking could be done at runtime automatically, and C could have a runtime that was updated and understood how to restructure the code and add new optimizations. It would probably have to eliminate pointers and have a pretty serious runtime component to do so. Perhaps it could take on a new name--call it C# I guess.
>Also, note that traversing data structures representing byte code isn't free. If later JVMs do more work to optimize code before running it, I predict they will take longer to start up.
Not really, they can (and do) just make the JVM more efficient. The chances also tend to make the JVM smaller and faster to load.
>Are people shipping fancy linkers that speed up C code? No, they're not. Are JVMs employing fancy optimization techniques at run-time? Yes, they are. Is C substantially faster than Java at run-time? Yes, it is.
What makes you say it's substantially faster? Until you get fairly high on the C optimization scale, Java tends to be faster--There was a programming challenge on Cedric's blog that became really interesting--people optimized the hell out of a routine and then re-ported it to a few languages. I believe the Java routine was slightly faster than the C routine (including startup) until it was compiled above -O3, then the differences were minimal (IIRC). In a few cases java is much worse (maybe even 10x), but for most stuff it tends to be 2x as slow.
One of the worst cases is floating-point math where Java refuses to use the math co-processor because they do not all return the same results for a given operation--this infuriates the graphics folks who don't care about accuracy anywhere near as much as speed (and here lies one of the REAL advantages of C, you can't fix this without recompiling the java source--a daunting task--where in C you just link against a different library.)
Anyway, the point is, compare Java and C's speed to say that of Python and Ruby (100x slower) and you'll see that Java and C are extremely closely tied.
I've used Java on multiple embedded platforms with oddball chipsets and very low power (including high performance graphics).
So Can you back up your "Substantially faster" statement? Where do you get your data? Are you just using the same logic and assuming it has to be faster?
I really love my MAC, I've completely switched over after using PCs since early dos days.
Lately I've been trying to install parallels so I can run a few Windows games.
Parallels struggles for a while, then says that there are "unmovable files" and that I need to back up my hard disk and re-install OS-X!
After looking into it, The problem is that the mac drive is fragmented and the mac has no way to defragment some system files (the file in question appears to be the latest OS upgrade which seems to be kept inside it's original file).
So, I looked around for defragmenting programs, but nearly every reference is either Apple or Apple fanboys telling you that the mac doesn't need defragmenting.
Well, I guess it's true, the mac does NOT need defragmenting, just the occasional wipe and re-install!
I'm not really disagreeing with the concepts here--the OS does self-defragment to a degree, the file IS a system file and shouldn't be movable, etc. What I hate is the damn arrogance, every reply to a post on defragmenting was along the lines of "Man are you STUPID, MACs don't need defragmenting! That's so PC" (and yet apple itself recommending a re-install to force a defragment when it is needed).
Makes me hate this cult I appear to be a member of.
Actually, there are things you can do with Java/C# that you can't do with C period.
C (and even assembly) can't realize that the same inputs to a routine always cause the same output, and therefore cache the return value and just return it (not without a lot of buggy, custom code anyway). (I'm not saying Java/C# DO this, they may--I understand they were working on it... But just trying to give you an idea of what CAN be done)
Java/C# do compile to assembly by the way--only the parts that are run often. And the compile step can know a lot more about the runtime configuration of the system.
Currently these kind of optimizations don't actually have Java running faster than C, currently it runs about 1/2 the speed on average and significantly less for some operations. A very few operations can be faster.
The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster without touching the compiled system.
All I'm really doing is offering a counter to your discussion about assembly being clearly faster--Logically I assumed it would be too--just makes sense--but I assumed wrong.
Personally I've always thought they should be randomly selected like Jury Duty, that along with some hefty jail-time for power-abuse related crimes should fix up most of the problems.
It would also require group rule at all levels--you couldn't use this to choose a governor or President, but it would work great for State and federal Congress.
It might also help to only turn over 10% or so a year rather than 33% or 50% to keep a little more consistency.
I think the point here is to have something that creates a new "Sense" not something that tells you which way is north. A compass can tell you which way is north.
That said, I wonder if a small choker might do a better job. Something with very small vibrators that fit around your neck where you are more sensitive.
Of course, the less sensitive waist might be chosen deliberately since those senses aren't used for much except to ensure that your ass-crack is covered.
It just struck me that I may be communicating much more poorly than I would have thought.
Did you think that in some way I was defending the hacker? If so, I apologize. I was not. To hack in and cause damage is unforgivable! I was simply stating that if we had a system in place where hackers had been rewarded to find holes, their hole would have been found and fixed years ago and this wouldn't have happened.
The guy who did it is a complete asshole... but who knows, maybe he would have been the one that found the hole and reported it instead under different circumstances.
A more accurate analogy would be if there were two types of rats, one that tended to find a hole in your cellar, walk through and might be willing leave you a little note where your hole is before leaving, and a second that carried plague and loved to come in and bite your kids.
So yes, you give the first guys a little nibble of cheese for their service and plug the hole.
Or I guess you could chase the good ones with a broom just like the bad ones and never know where your hole is.
Since there are an endless number of type II rats and they are often encouraged by your neighbors to spread the plague and steal whatever they can from your house and bring it back to theirs, slapping both types equally seems like an ignorant waste of resources.
To not be able to see that seems to me to be just--I don't know, beyond words.
I completely agree. The ones that become "Security Experts" are completely worthless--(Which is why most security experts are...)
That isn't what I was suggesting at all. A pattern of paying bounties for finding bugs would encourage SOME of the hackers that actually know what they are doing to report it and collect the bounty--and some is really all it would take (assuming the admins would actually fix what was found).
Even just giving them amnesty if they report a bug instead of treating them like criminals might be nice, I mean it's a damn public service.
If someone who might report it is discouraged from doing so, then someone who won't report it WILL find it and abuse it.
Or pay them to find shit like this before someone does this.
The logic behind "Destroy your only resource that can work to actually help you fix the holes that will be exploited by foreign hackers or terrorists" is completely beyond me.
In fact, it seems so utterly stupid that I get furious every time I hear some thoughtless moron spout "Punish the hackers". Suggesting they should be killed? I'd personally sooner keep those intelligent if misguided people--being the only ones that are really going to be useful at preventing external penetration of our systems--and kill assholes who can't think of a solution beyond a statement like "Kill the hackers".
Not that I'd really condone either, but if I had to choose...
"Code" is in a pretty frightening state. I've worked on embedded systems and larger systems, and have noticed something kind of interesting.
Code for embedded systems is often pretty horrific. They get away with it because they have a limited number of inputs and can test pretty much every possible combination. If you test them all and your product can get through without failing, chances are the bugs won't be very visible.
When the really hard issues are found like memory leaks or threading problems, the manufacturer can take an approach like "Force a reboot" instead of messing with the mess.
The larger non-embedded systems tend to be a little better written because there are usually too many combinations to test.
But over all, there are very few people out there producing "Good" code--and if you think about it that makes sense. How many basketball players (out of all the players in the US) play a truly better game? What percentage of painters in history have made truly good paintings?
Programming is an art, and you can't really expect much better. Every programmer wants to think they are one of the good ones, just like I'm sure every painter aspires to have a permanent place in a world-class museum.
So I guess this is just another call for getting the code for these important systems out there. Although there aren't many true artists out there, I've seen many cases of iterative improvement as more eyes looked at and revised a routine. If something is critical to the operation of our state, government, health or safety then we should all be able to validate it.
The best basketball team out there isn't going to do much against a team made up of 5000 average players where each player can contribute only that one perfect lucky shot.
Not disagreeing with you at all--but do you recognize that you are putting crack dealers on the same level as wineries? Many addictive drug dealers have used these techniques for years--The creators of cigarettes, wine and beer have often given their drugs away to try to create new addicts--in fact if I'm not mistaken, cigarettes were given to the military as part of rations WWII (and WWI?).
Makes you think--I mean the cigarette manufactures are more aggressive in that way than dealers of every other drug (possibly even including alcohol) combined and they have killed many more people and cost society much more...
I don't know where I'm going with this, but there is a point to be made there somewhere.
Of course government computers with classified information should NOT BE RUNNING ANY SOFTWARE THAT IS NOT COMPLETELY UNDERSTOOD AND PROPERLY CONFIGURED.
Also, of course, it sucks that a p-p network in Iran is hosting secret information.
How does passing a law regarding p-p in the US have any effect on these problems?
Slashdot Mirror
Of course it's true that it should be boring, rigorous and correct, but right now it can't be. The first few thousand years of bridge building, they REALLY DID just build it and have guys walk across it until it collapsed, then rebuild it.
If you told someone to build a sky-scraper with only knowledge of the first 50 years of architecture to work on, it would be a really big FAIL.
And computer software can be many times more complex than anything else humanity's ever accomplished. It's virtually impossible to get it ALL, so we build in layers. The analogy would be trying to build a bridge to Hawaii. You'd build out a little way, test, make sure stuff works, re-enforce it, then build on what's already been built. Nobody could do the entire trip, but between different techniques, building on each others work, and some very crafty, creative artistic thought--it just might be doable (I'm not saying I'd want to USE it).
There are very few tasks in today's workplace that require as much thought as programming, and for most problems there is no "correct" solution. A guy building a high performance 3-d game can't use a library built to be readable over fast. I good server can't use a library built for speed, scalability and maintainability or more important.
Software engineering can't even build on the other engineering disciplines--it's too different so we're starting over from scratch.
So yeah, until we've been programming for a thousand years or so, I don't know if it's fair to expect to see the same kind of discipline.
So, I'm sure, are a lot of things I don't recognize, like designing a sky-scraper or space shuttle.
Programming is an art, Anyone can follow instructions and follow an existing style or try to paint a realistic scene, but to come up with a skilled interpretation that really conveys a meaning takes a better painter. To bring together 20 painters, outline a collaboration and manage the production of some giant, detailed interpretation takes a master--at this point natural talent starts to mean more than training, and no level of training can improve someone without talent.
Anyone can write a small program. You can fit 20 generic programmers in a room and have them each write a small program. You might even be able to get them to join the programs somewhat-properly, but the whole thing will never go smoothly.
One or two really good programmers will probably out-produce 20 people that "know how to program".
How many amateur painters do you need to create something like the sistine chapel?
Just because most people can't see the art that allows large programs to work doesn't mean it's not there. In fact, most people can't tell any type of good art from bad without some training.
We do backups, but if we never do a restore, we don't really know that the restore procedure will work. If you REALLY want to make your downtime minimal, you occasionally test your restore procedure.
I'd like to suggest that any life critical application like this be forced, at least one day a month, to run without computers.
If it causes them to hire another employee, good--we need more employment. It should also help them gauge how many extra people they will need to handle a situation where the computer services are unavailable.
Computers are nice, the internet is nice, email is nice, NONE of these should be required for the normal functioning of a country--it's too big a vulnerability. We already know the effects of an EMP, do we really want a single attack to be able to shut down all the hospitals in a state?
If it get's broken, it's not a law.
What's the obsession these days with calling observations "laws"?
Moore's law is simply an observation, as is this. Actually software will be as slow as hardware of the period allows, rarely faster. Can we call this Bill's Law? Note the relationship between Moore's and Page's is obvious when you consider Bill's law.
Hmph, it's all just observations that happen to hold true for a short period. If that period happens to be 20 years, us short-lived humans extrapolate it to a constant like "Housing prices will always rise".
Not that I really care, but it seems to be an insult to people who actually discover real laws of nature an physics to have a casual observation given as much verbal weight.
What motivates me is the fact that they can install a keylogger and scan for passwords after you type something like "wamu.com". Since I don't trust ANYTHING to detect rootkits, I've just completely stopped using windows to access anything financial... No credit cards, nothing.
Not that Linux/Macs are invulnerable, but at least they don't default to a state equivalent to the swiss cheese of security.
Thank you! Holding down shift while I booted the mac worked, I was able to create my 10gb msdos partition and will be able to play Oblivion as soon as I can figure out the driver situation.
Note: this makes Apples recomendation to wipe/reinstall even more appropriate for this topic!
> I meant for the specific case of knowing whether to inline a function or not. Collecting metrics for that seems like a big overhead considering the benefit.
I know it collects various metrics, but the big deal right now is JIT compiling. My feeling is there is a lot of room for improvement with the JVM--The JIT compiler is only a few years old.
Then there are the potential big improvements that could jump it above most assembly language such as Microcode in a CPU or co-processor with the ability to process Java bytecode instructions natively--remember bytecode is MUCH more compact than the x86 assembly instruction set. A powerful, optimized CPU should be able to do much more with it than with x86 code because it wouldn't have to spend so much effort trying to move code in and out of caches--less data does significantly more work.
In fact, did you know that even in the early 90's, excel and Word, even though they were written in C, used an embedded bytecode VM for code size? (I forget where I heard that, it was when Java first appeared on the scene, so I really should check my references).
I'm not half as vested in this as I sound--It's just that the OP put out that C can't be beat, and I really think a lot of people miss the advantages of an active runtime. I get the feeling that people think Java is like 100x slower, and yet many of the same people will use Ruby which actually IS 100x slower. Confuses me a little.
>>Also, how do you prove that pointers haven't modified the values you depend on without checking each one?
>>The same way that the runtime would do it.
The java runtime doesn't have to because it doesn't allow arbitrary pointers to memory. I do kind of wonder about C# and if it affects performance optimizations.
>Is that improvement worth it when you have to constantly gather statistics about every function call? There's two sides to this coin, you know. Does Java implement that?
Yes, Java currently collects runtime statistics so that it knows which calls might benefit from compiling to machine language.
>How would it prove that the two paths don't interact, in a way which can't be done by a compiler? The compiler can also simulate the running of code.
I admit this one is reaching a bit. You can do a lot of compile-time optimization, but you could use runtime statistics to show which functions might benefit from their own thread.
>I looked, and it's a bit weird that the results for C and C++ often differ by a lot (which makes me think the programs are not that optimized, as for small programs like that it should be trivial to make C and C++ as fast as each other).
Since the programs are submitted by language advocates and repeatedly revised, I'm guessing none of them have really big obvious time-sinks.
I found a lot of those results strange as well--the compiler used often seemed to have more of an effect than the language! There is also one case where functional languages are far faster than C or Java.
But notice that there are very few edge cases where C is a few times quicker, and mostly they are within a few percent. This is with all Java's VM overhead you mentioned above. It won't take but a few small incremental improvements before Java is regularly beating C--and C's so optimized already I'm not sure how much more can be done.
If you add heap allocation of small objects (Very common with good OO code), you may find that Java starts to blow C out of the water (at least C using standard malloc). 99% of Java's heap allocation should perform like C's stack allocation, it uses some very neat tricks to accomplish that. I'd actually like to test this sometime, but I don't write much C code these days--not since the early 90's.
I'm guessing multiple small allocations are what makes the thread-ring test prefer functional languages over the best C/Java times by a factor of 10x+ though.
Yes, you are correct. If you were to make C run in a VM and remove pointers (for improved optimization, with pointers around it's harder for the VM to know what can and can't change at runtime). You might also make it cleaner while you're at it, remove stupid compiler tricks like header files. Make it OO as well with memory management (you might as well now that you've got a VM there, it'll be a good deal more efficient than malloc/free for heap memory).
Yes, you can improve C. Someone should look into that.
Exactly, now do it for every single function, automatically determining (by call count and mutability of external references) if it makes sense or not. Now you DO have a runtime.
Also, how do you prove that pointers haven't modified the values you depend on without checking each one?
And that's just one of hundreds of things that are possible with a VM, none of which you can do with native code.
--Compiling code to native for a given state of a variable who's state rarely changes, eliminating calculations on that variable as though it was a constant.
--Compiling a second instance of that method if the variable DOES change, being able to alternate between which of the two you call at will.
--Inlining code like that (or not) based on runtime statistics.
--Taking code written as single-threaded and throwing multiple threads at it when it determines that two paths don't interact. (This could be done at compile time as well, but could be done more efficiently with code profiling information in memory.)
--Improving the efficiency without recompiling (Or, you could look at Java as ALWAYS recompiling to machine language)
In fact, that may be the point that the C people here are missing. How can C possibly compete with a language that compiles to machine language with more information than the C compiler has at compile time?
Currently C keeps up (Most benchmarks seem to have a few C compilers running faster than java and a few slower, but the difference is often under 10% both ways) but C is on it's umpteenth year of optimization, whereas the JVM has only been compiling for a few years now and has a lot of improving to do...
http://shootout.alioth.debian.org/u64q/benchmark.php?test=binarytrees&lang=all&box=1
Look at some of those results (The best code submitted by expert programmers for each language)--Java and C are always in the top few, C is almost always a few ticks quicker, but virtually tied.
If you think the C code must suck, please help C win by improving their code--I'm fairly sure it's already been streamlined past what a mortal programmer can improve in most of those languages. Until someone improves these I'm going to go with C and Java being the same speed, but Java improving more rapidly.
A function, sum(1,2,3) returns 6.
Let's say it's called 1000 times with the same parameters, it could be short-circuited to simply insert a 6 instead of calling the funciton.
The next day, it's called 1000 times with 1,5,5000.
After analyzing ALL inputs (including references from within the method to outside objects) It could be short-circuited to return 5006.
This is not hard within the JVM, it is virtually impossible within C. This is why you are having trouble comprehending what the JVM can do--I can't blame you, it takes a while to grok the difference between code running natively and code that can be analyzed at runtime.
>The 'const' function attribute does that and works fine
Really?
I don't think you get it. I'm talking about a regular function that takes, say a and b and returns the sum of a and b. Can C really notice that you happen to be calling it with 3,7 a lot and cache the return value of 10, then the next day notice that you are calling it with 1023,2042 and return 3065?
Or can C notice that you almost always call a function with a parameter that causes a particular path through that function, then compile (to binary, not bytecode) a version of that function that contains only code used in that path and use it for a particular sub-set of parameters?
If so, C has changed a lot since the last time I used it.
A program run by a VM has much more potential than one run without.. currently we are only scratching the surface of what can be done and java is already running at the same speed as C!
(Well faster than some compilers, slower than others for a given solution--but Java is rarely more than a couple percent off)
This seems to be one case where C could use some help:
http://shootout.alioth.debian.org/u32q/benchmark.php?test=threadring&lang=all&box=1
The functional languages seem to have it locked up, or perhaps their C implementation needs you to step up and fix it.
There is no reason any other compiler couldn't put out code as good as C, better in fact since C allows pointers (which stops the compiler from making quite a few optimizations). It's just that C tends to be easier to hand-optimize right now (just like assembly is easier than C). That doesn't make assembly better for 99% of the cases though, and the same could be said of C.
> So for all the non-volatile stuff, the compiler can perform the same static analysis that a Java/C# compiler does to decide whether a function has your specified behavior or not.
No it can't. It can't recognize that a function happened to be called 30 times in the last second with the parameters (1, 5, "Hello") and returned 17, and just return 17 for those values--and the next day, do the same thing for different values.
Sure you could program it to, but it would all be your code--C cannot do it for you on every single function, it wouldn't make sense (then C would need a runtime like java--it would no longer be C)
Also--the language itself would make this impossible. Java can know for sure that nothing is modified without the runtime's knowledge. There are no pointers in Java, and the runtime can analyze a class to ensure that things it relies on haven't changed. C could not do that generically, You would have to double the size of every method to get that kind of functionality.
> And what's to stop people from writing a linker which does some "post-production" optimizations on the object code?
You'd have to relink. I suppose linking could be done at runtime automatically, and C could have a runtime that was updated and understood how to restructure the code and add new optimizations. It would probably have to eliminate pointers and have a pretty serious runtime component to do so. Perhaps it could take on a new name--call it C# I guess.
>Also, note that traversing data structures representing byte code isn't free. If later JVMs do more work to optimize code before running it, I predict they will take longer to start up.
Not really, they can (and do) just make the JVM more efficient. The chances also tend to make the JVM smaller and faster to load.
>Are people shipping fancy linkers that speed up C code? No, they're not. Are JVMs employing fancy optimization techniques at run-time? Yes, they are. Is C substantially faster than Java at run-time? Yes, it is.
What makes you say it's substantially faster? Until you get fairly high on the C optimization scale, Java tends to be faster--There was a programming challenge on Cedric's blog that became really interesting--people optimized the hell out of a routine and then re-ported it to a few languages. I believe the Java routine was slightly faster than the C routine (including startup) until it was compiled above -O3, then the differences were minimal (IIRC). In a few cases java is much worse (maybe even 10x), but for most stuff it tends to be 2x as slow.
One of the worst cases is floating-point math where Java refuses to use the math co-processor because they do not all return the same results for a given operation--this infuriates the graphics folks who don't care about accuracy anywhere near as much as speed (and here lies one of the REAL advantages of C, you can't fix this without recompiling the java source--a daunting task--where in C you just link against a different library.)
Anyway, the point is, compare Java and C's speed to say that of Python and Ruby (100x slower) and you'll see that Java and C are extremely closely tied.
I've used Java on multiple embedded platforms with oddball chipsets and very low power (including high performance graphics).
So Can you back up your "Substantially faster" statement? Where do you get your data? Are you just using the same logic and assuming it has to be faster?
http://shootout.alioth.debian.org/gp4/benchmark.php?test=nbody&lang=all
I really love my MAC, I've completely switched over after using PCs since early dos days.
Lately I've been trying to install parallels so I can run a few Windows games.
Parallels struggles for a while, then says that there are "unmovable files" and that I need to back up my hard disk and re-install OS-X!
After looking into it, The problem is that the mac drive is fragmented and the mac has no way to defragment some system files (the file in question appears to be the latest OS upgrade which seems to be kept inside it's original file).
So, I looked around for defragmenting programs, but nearly every reference is either Apple or Apple fanboys telling you that the mac doesn't need defragmenting.
Well, I guess it's true, the mac does NOT need defragmenting, just the occasional wipe and re-install!
I'm not really disagreeing with the concepts here--the OS does self-defragment to a degree, the file IS a system file and shouldn't be movable, etc. What I hate is the damn arrogance, every reply to a post on defragmenting was along the lines of "Man are you STUPID, MACs don't need defragmenting! That's so PC" (and yet apple itself recommending a re-install to force a defragment when it is needed).
Makes me hate this cult I appear to be a member of.
Actually, there are things you can do with Java/C# that you can't do with C period.
C (and even assembly) can't realize that the same inputs to a routine always cause the same output, and therefore cache the return value and just return it (not without a lot of buggy, custom code anyway). (I'm not saying Java/C# DO this, they may--I understand they were working on it... But just trying to give you an idea of what CAN be done)
Java/C# do compile to assembly by the way--only the parts that are run often. And the compile step can know a lot more about the runtime configuration of the system.
Currently these kind of optimizations don't actually have Java running faster than C, currently it runs about 1/2 the speed on average and significantly less for some operations. A very few operations can be faster.
The real issue is, when Java 7, 8 or 9 comes out, ALL java code ever produced will run faster without touching the compiled system.
All I'm really doing is offering a counter to your discussion about assembly being clearly faster--Logically I assumed it would be too--just makes sense--but I assumed wrong.
Personally I've always thought they should be randomly selected like Jury Duty, that along with some hefty jail-time for power-abuse related crimes should fix up most of the problems.
It would also require group rule at all levels--you couldn't use this to choose a governor or President, but it would work great for State and federal Congress.
It might also help to only turn over 10% or so a year rather than 33% or 50% to keep a little more consistency.
I think the point here is to have something that creates a new "Sense" not something that tells you which way is north. A compass can tell you which way is north.
That said, I wonder if a small choker might do a better job. Something with very small vibrators that fit around your neck where you are more sensitive.
Of course, the less sensitive waist might be chosen deliberately since those senses aren't used for much except to ensure that your ass-crack is covered.
It just struck me that I may be communicating much more poorly than I would have thought.
Did you think that in some way I was defending the hacker? If so, I apologize. I was not. To hack in and cause damage is unforgivable! I was simply stating that if we had a system in place where hackers had been rewarded to find holes, their hole would have been found and fixed years ago and this wouldn't have happened.
The guy who did it is a complete asshole... but who knows, maybe he would have been the one that found the hole and reported it instead under different circumstances.
A more accurate analogy would be if there were two types of rats, one that tended to find a hole in your cellar, walk through and might be willing leave you a little note where your hole is before leaving, and a second that carried plague and loved to come in and bite your kids.
So yes, you give the first guys a little nibble of cheese for their service and plug the hole.
Or I guess you could chase the good ones with a broom just like the bad ones and never know where your hole is.
Since there are an endless number of type II rats and they are often encouraged by your neighbors to spread the plague and steal whatever they can from your house and bring it back to theirs, slapping both types equally seems like an ignorant waste of resources.
To not be able to see that seems to me to be just--I don't know, beyond words.
I completely agree. The ones that become "Security Experts" are completely worthless--(Which is why most security experts are...)
That isn't what I was suggesting at all. A pattern of paying bounties for finding bugs would encourage SOME of the hackers that actually know what they are doing to report it and collect the bounty--and some is really all it would take (assuming the admins would actually fix what was found).
Even just giving them amnesty if they report a bug instead of treating them like criminals might be nice, I mean it's a damn public service.
If someone who might report it is discouraged from doing so, then someone who won't report it WILL find it and abuse it.
Or pay them to find shit like this before someone does this.
The logic behind "Destroy your only resource that can work to actually help you fix the holes that will be exploited by foreign hackers or terrorists" is completely beyond me.
In fact, it seems so utterly stupid that I get furious every time I hear some thoughtless moron spout "Punish the hackers". Suggesting they should be killed? I'd personally sooner keep those intelligent if misguided people--being the only ones that are really going to be useful at preventing external penetration of our systems--and kill assholes who can't think of a solution beyond a statement like "Kill the hackers".
Not that I'd really condone either, but if I had to choose...
Or vote, or run your pacemaker.
"Code" is in a pretty frightening state. I've worked on embedded systems and larger systems, and have noticed something kind of interesting.
Code for embedded systems is often pretty horrific. They get away with it because they have a limited number of inputs and can test pretty much every possible combination. If you test them all and your product can get through without failing, chances are the bugs won't be very visible.
When the really hard issues are found like memory leaks or threading problems, the manufacturer can take an approach like "Force a reboot" instead of messing with the mess.
The larger non-embedded systems tend to be a little better written because there are usually too many combinations to test.
But over all, there are very few people out there producing "Good" code--and if you think about it that makes sense. How many basketball players (out of all the players in the US) play a truly better game? What percentage of painters in history have made truly good paintings?
Programming is an art, and you can't really expect much better. Every programmer wants to think they are one of the good ones, just like I'm sure every painter aspires to have a permanent place in a world-class museum.
So I guess this is just another call for getting the code for these important systems out there. Although there aren't many true artists out there, I've seen many cases of iterative improvement as more eyes looked at and revised a routine. If something is critical to the operation of our state, government, health or safety then we should all be able to validate it.
The best basketball team out there isn't going to do much against a team made up of 5000 average players where each player can contribute only that one perfect lucky shot.
Not disagreeing with you at all--but do you recognize that you are putting crack dealers on the same level as wineries? Many addictive drug dealers have used these techniques for years--The creators of cigarettes, wine and beer have often given their drugs away to try to create new addicts--in fact if I'm not mistaken, cigarettes were given to the military as part of rations WWII (and WWI?).
Makes you think--I mean the cigarette manufactures are more aggressive in that way than dealers of every other drug (possibly even including alcohol) combined and they have killed many more people and cost society much more...
I don't know where I'm going with this, but there is a point to be made there somewhere.
Of course government computers with classified information should NOT BE RUNNING ANY SOFTWARE THAT IS NOT COMPLETELY UNDERSTOOD AND PROPERLY CONFIGURED.
Also, of course, it sucks that a p-p network in Iran is hosting secret information.
How does passing a law regarding p-p in the US have any effect on these problems?