You were off on the accuracy by two orders of magnitude, and not on the conservative side either. Now you are making excuses for why that error didnt matter. Really?
You were wrong. Its really that simple. It does not matter if the error matters or not. When errors like that do not matter, it is only through LUCK.
The dream of the FOSS fans was for Theora to be selected as the official codec for the video tag. You are suggesting that it should be a moving target, where nobody can remain compliant for long periods.
Your honor, I rest me case. It really IS badass. Stallman is now officialy linked with pedophilia on slashdot, and all I said way that he shouldn't be left alone with children because hes insane.
Apparently your dumb ignorant ass missed the part where you overestimated the accuracy of doubles by two orders of magnitude.
Here is a tip. When doing USD financial calculations, AT A MINIMUM you need to be accurate to the PENNY... and in fact the person you replied to even mentioned it..
I wasn't trolling.. I was observing your mistake.. Now I am observing your over-inflated ego and completely ignorant reluctance to find your error.
I dont give a flying fuck what programs you have written in the past and it is clear to me that distributed computing clients do not expressly need accuracy, or apparently a programmer that is critical of his own kneeJERK bullshit.
I dont believe that it was either Kernighan or Ritchie, unless we are thinking of seperate goto opponents. The opponent I am thinking of is Edsger Dijkstra.
If GoTo is 'considered harmful' then isn't Object/Event Spaghetti far more harmful? When looking at modern source code, its often impossible to figure out program flow, which was the exact same arguement against GoTo.
I'm sure the OOP proponents will now chime in and say that the seperation of duties principle means that you dont really need to grasp program flow.. and all I have to say to that is that there is a difference between theory and practice.
In practice there is external state and side effects, where Big Giant Function can be proven to be correct (even if it uses GoTo's) without the miles of safe-guard code that a Big Giant Object Graph would require for the same proof.
The end result of your line of thinking is that everything would use the same protocol, no matter how stupidly inefficient that protocol might be for the task, to avoid the throttling.
BitTorrent over HTTP. Video streaming over HTTP. Online games over HTTP. VOIP over HTTP.
To understand why this is bad, and to be quite accurate, it needs to be understood that there are only two common internet protocols: TCP and UDP.
Not HTTP? Thats right. HTTP isnt an Internet Protocol (IP), its an application protocol. The ISP does not need to know that a packet is an HTTP packet in order to deliver it, because HTTP is just an application-defined layer on top of the TCP protocol. A TCP packet consists of header and data. The header contains vital information necessary to facilitate the reliable delivery of the data. The data itself is irrelevant to that delivery.
This application defined layer that is HTTP consists of reserved data within the data section of the TCP packet, data that isn't necessary to facilitate the delivery of it. Data that has nothing to do with other applications and their needs. It is quite inefficient to include it when it isnt necessary, and quite frankly if ISP's are not allowed to throttle or eavesdrop, then they have no reason to look inside the data area of TCP packets at all.. that doing so would also be less efficient from their perspective. The only reason that they inspect the data area now is so that they can throttle and eavesdrop.
This whole tickless thing seems like a red herring.
What the hell is their tick rate set to? 1Mhz?
AFAIK, all versions of windows tick at one of 3 rates by default: 18.2hz, 66.6hz, or 100hz depending on hardware and particular OS version. At least from windows XP and beyond, this tick rate can be adjusted (at runtime) to up to 1000hz.
The tick is generated by one of the timing sources on the machine. The legacy method is via the Programmable Interval Timer (PIT) which raises IRQ0 at a rate of 18.2 times per second in its Power On state, which is exactly 65536 (16-bit derived value) increments of its own internal 1.19mhz counter.
Now, I do not believe that an IRQ0 handler responsible for incrementing a counter and then checking to see if a task switch is necessary (thats what windows does in its IRQ0 handler) will drain significant battery. Either Linux (the 'non-tickless' variety) is doing way more work than necessary in the handler, or the rate at which it ticks is unimaginably (fruitlessly) high.
My DOS-era knowledge on the matter was supposed to be acedemic. For christ sakes...
Whether Sun made a significant amount of money directly from Java or not it did not prevent them from improving it.
..and look where that got them.
The fact is that Oracle isn't aquiring the unprofitable (losing billions per year) Sun Microsystems so that they can continue the same failed strategy that made them unprofitable to begin with.
You seem to think otherwise..
So what is your point, Sun was not improving Java, Oracle will not improve Java, or Oracle does not make money off improving Java?
Sun does not make money off improving Java (they have been posting losses for quite awhile), therefore Oracle will likely not make money off improving Java. Oracle knows this, so they wont improve Java. Its a money pit thats already destroyed one company.
Sun does have a few significant products which Oracle would very much like, probably the most significant is MySQL. There are currently millions of installations of this database server and Oracle's business is database solutions. Sun's storage solutions division (solaris + hardware) will also be a signficant addition for Oracle because, and I repeat, Oracle's business is database solutions.
..and when I say that their business is database solutions, I mean that they have a market cap in the same neighborhood as IBM, Microsoft, Apple, and Cisco. Oracle is the king of its industry. Sun is about 5% the size of Oracle, and Java is only a small fraction of Sun. Once you know the facts, its quite clear that Java is just about the last thing Oracle cares about.
Three, Java development stagnates. Does new Java development make any money at all for Sun right now? I don't think so. I think supporting the existing codebase is whats been bring money in.
The h264 support goes well beyond Windows, Linux, and OSX. Well beyond Firefox, Safari, Chrome, and Opera. Well beyond Flash and Silverlight. It doesnt matter what Google does. You can't give the millions of existing iPhones acceptable Theora support. You can't give the millions of existing netbooks acceptable Theora support. They *do* have accepable h264 support.
The hardware support for h264 is already cheap, low powered, and mass produced for these segments.
Put the keyboard on the touch screen and your specific arguement goes away.
I had seen a multi-touch demonstration with an on-screen keyboard and one of the things they were doing with the keyboard was adapting it to the user in realtime. The demonstrator was being intentionally sloppy and the keyboard did things like follow his hands as they drifted (even rotating)
Mark my words. Laptops will be off the market in 5 years, replaced by double-screen multi-touchers, and netbooks will be replaced by multi-touch tablets.
But what do you do if someone wants to run your code on an ARM or (gasp) an Alpha?
They can't. Most programs written in HLL's can't simply be recompiled either. What does this have to do with anything?
The poster claimed that compilers at better at optimizing than humans. Hes wrong. Thats all. All the other stuff he brings up is irrelevant to his error.
You may bluster on about owning all his books, but apparently you never actually read them because he has talked in a number of his papers and in the book Literate Programming about the faults of trying to optimize every single inefficiency and about how premature optimization can lead to performance problems in a program.
If you can quote me where I said anything to the contrary, that you make you look smart.
Since you can't, that makes you look stupid and juvenile.
If this is FUD then Donald Knuth is the biggest spreader of FUD ever since he has talked about just such situations in his books.
Donald Knuth, the man uses his own assembly language when expressing algorithms? Pleeeeeaaaaaaseeeee....
I have all of his books (boxed set!), and even have all of the fasciles for the book he hasnt released yet. I've also watched all the videos online of his lextures/classes.
You picked the *wrong* name to be dropping. When you are conversing with a dedicated optimizer, thats the last person you should try to misrepresent. The second to last person you should try to misrepresent is Abrash.
I never did any such thing
You listed downsides of assembler and upsides of HLL's, while listing no upsides of assembler and no downsides of HLL's.
Maybe you just don't have the ability to detect your bias. As far as my assembler skill, I've been programming in x86 assembler since the 8086. I also use HLL's. I mix the two because I happen to choose the right tool for the job. I don't have this ignorant mindset that only one tool is great.
Encryption algorithms use a wide variety of bit twiddling operations such as rotations
So do a lot of other algorithms, and that algorithm you thought couldn't take advantage of them, probably also can.
otherwise the compiler would have to be smart enough to see that what you are doing is a rotation.
Most are. This includes VC and GCC. They are smart enough to convert (x >> c) | (x
Still further, most compilers have rotation intrinsics (including VC, GCC, and ICC)
The compilers still arent good enough. The reason they don't do well in this case (*) isnt what you think. Its because they just arent very good at scheduling instructions in spite of the claims to the contrary, because its just too complex to be expressed in a set of heuristics. Its actualy also too complex for humans most of the time, but humans have tools that allow them to find the scheduling inefficiencies during real world execution, and those can only be addressed in assembler.
(*) This case is actualy a simple one. Cache considerations are fairly minimal and the work that needs to be done isnt all that complex (its just tedious)
But any good programmer has learned that rewriting all parts of a program in assembler does not always gain significant returns for your effort and in some cases these "optimizations" can actually have deleterious effects on the overall execution speed of the program.
I beg to differ. Most good programmers think that their C compiler beats out assembler. Most good programmers are wrong, in spite of being good.
And, if something has a negative effect then its not an optimization. Programmers do this thing called profiling, so they KNOW what effect the change has. You are spitting up FUD here. Unlike HLL programmers, asm programmers seeking performance are constantly profiling, and I am not talking about the kind of crappy profiling that most C++ programmers do either. Most of the features of VTUNE and CodeAnalyst are worthless to HLL programmers (pipeline simulations, for example) but give the asm programmer the ability to really and truely ramp things up. They dont understand that the abstract machine they target is just a stunted toy compared to real machines.
Not to mention the fact that there are numerous assembly language programmers that just flat out suck at coding in it and can in many cases produce slower code than that output from a compiler (have seen this in many cases).
This isn't news. This is a well known concept fully backed by research. Skill Level > Language Choice. While its true, its also irrelevant.
There is no guarantee that just cause you wrote it in assembly that it's going to be faster than a compiled C/C++ program.
There is if (A) I wrote it, (B) I'm finished, (C) It wasn't something trivial.
HLL's have their place. When performance isnt a concern they are great. The rest of your points are all about when performance isnt a concern. So *clap* *clap* *clap* hurray for you pointing out that assemblers have their limited place while refusing to admit that compilers also have their limited place.
..and thats why the fastest encryption libraries are written in high level languages, right?
oh, erm.. encryption algorithms need the exact things you claim compilers are great at, yet the fastest encryption libraries are in hand-written assembler.
The fact is that this "compilers are better than humans" meme is complete bullshit and has always been bullshit. This fact can clearly be demonstrated by looking at the change logs of those compilers. For well over a decade this meme has been out there and for well over a decade there has been continual performance improvements to those compilers..
..and to top it all off, if you arent using ICC then your compiler is shitty even compared to other compilers. The easiest optimization a VC or GCC programmer can make is to switch to ICC.
What it all boils down to is that HLL's use an abstract machine that has nothing at all to do with the real world details of computing on a specific architecture, and that my friend is why hand written essembler will always win the performance war.
Slashdot Mirror
You were off on the accuracy by two orders of magnitude, and not on the conservative side either. Now you are making excuses for why that error didnt matter. Really?
You were wrong. Its really that simple. It does not matter if the error matters or not. When errors like that do not matter, it is only through LUCK.
The dream of the FOSS fans was for Theora to be selected as the official codec for the video tag. You are suggesting that it should be a moving target, where nobody can remain compliant for long periods.
Think about it.
Your honor, I rest me case. It really IS badass. Stallman is now officialy linked with pedophilia on slashdot, and all I said way that he shouldn't be left alone with children because hes insane.
Apparently your dumb ignorant ass missed the part where you overestimated the accuracy of doubles by two orders of magnitude.
..
Here is a tip. When doing USD financial calculations, AT A MINIMUM you need to be accurate to the PENNY... and in fact the person you replied to even mentioned it
I wasn't trolling.. I was observing your mistake.. Now I am observing your over-inflated ego and completely ignorant reluctance to find your error.
I dont give a flying fuck what programs you have written in the past and it is clear to me that distributed computing clients do not expressly need accuracy, or apparently a programmer that is critical of his own kneeJERK bullshit.
You mean like "Richard Stallman is fucking insane so he shouldn't be left alone with children!"
Your right. Thats a fucking badass way to spread the little irrelevant nuggets of truth.
Remind me not to hire you for any floating point work.
I dont believe that it was either Kernighan or Ritchie, unless we are thinking of seperate goto opponents. The opponent I am thinking of is Edsger Dijkstra.
If GoTo is 'considered harmful' then isn't Object/Event Spaghetti far more harmful? When looking at modern source code, its often impossible to figure out program flow, which was the exact same arguement against GoTo.
I'm sure the OOP proponents will now chime in and say that the seperation of duties principle means that you dont really need to grasp program flow.. and all I have to say to that is that there is a difference between theory and practice.
In practice there is external state and side effects, where Big Giant Function can be proven to be correct (even if it uses GoTo's) without the miles of safe-guard code that a Big Giant Object Graph would require for the same proof.
The end result of your line of thinking is that everything would use the same protocol, no matter how stupidly inefficient that protocol might be for the task, to avoid the throttling.
BitTorrent over HTTP. Video streaming over HTTP. Online games over HTTP. VOIP over HTTP.
To understand why this is bad, and to be quite accurate, it needs to be understood that there are only two common internet protocols: TCP and UDP.
Not HTTP? Thats right. HTTP isnt an Internet Protocol (IP), its an application protocol. The ISP does not need to know that a packet is an HTTP packet in order to deliver it, because HTTP is just an application-defined layer on top of the TCP protocol. A TCP packet consists of header and data. The header contains vital information necessary to facilitate the reliable delivery of the data. The data itself is irrelevant to that delivery.
This application defined layer that is HTTP consists of reserved data within the data section of the TCP packet, data that isn't necessary to facilitate the delivery of it. Data that has nothing to do with other applications and their needs. It is quite inefficient to include it when it isnt necessary, and quite frankly if ISP's are not allowed to throttle or eavesdrop, then they have no reason to look inside the data area of TCP packets at all.. that doing so would also be less efficient from their perspective. The only reason that they inspect the data area now is so that they can throttle and eavesdrop.
This whole tickless thing seems like a red herring.
What the hell is their tick rate set to? 1Mhz?
AFAIK, all versions of windows tick at one of 3 rates by default: 18.2hz, 66.6hz, or 100hz depending on hardware and particular OS version. At least from windows XP and beyond, this tick rate can be adjusted (at runtime) to up to 1000hz.
The tick is generated by one of the timing sources on the machine. The legacy method is via the Programmable Interval Timer (PIT) which raises IRQ0 at a rate of 18.2 times per second in its Power On state, which is exactly 65536 (16-bit derived value) increments of its own internal 1.19mhz counter.
Now, I do not believe that an IRQ0 handler responsible for incrementing a counter and then checking to see if a task switch is necessary (thats what windows does in its IRQ0 handler) will drain significant battery. Either Linux (the 'non-tickless' variety) is doing way more work than necessary in the handler, or the rate at which it ticks is unimaginably (fruitlessly) high.
My DOS-era knowledge on the matter was supposed to be acedemic. For christ sakes...
Whether Sun made a significant amount of money directly from Java or not it did not prevent them from improving it.
The fact is that Oracle isn't aquiring the unprofitable (losing billions per year) Sun Microsystems so that they can continue the same failed strategy that made them unprofitable to begin with.
You seem to think otherwise..
So what is your point, Sun was not improving Java, Oracle will not improve Java, or Oracle does not make money off improving Java?
Sun does not make money off improving Java (they have been posting losses for quite awhile), therefore Oracle will likely not make money off improving Java. Oracle knows this, so they wont improve Java. Its a money pit thats already destroyed one company.
..and when I say that their business is database solutions, I mean that they have a market cap in the same neighborhood as IBM, Microsoft, Apple, and Cisco. Oracle is the king of its industry. Sun is about 5% the size of Oracle, and Java is only a small fraction of Sun. Once you know the facts, its quite clear that Java is just about the last thing Oracle cares about.
Sun does have a few significant products which Oracle would very much like, probably the most significant is MySQL. There are currently millions of installations of this database server and Oracle's business is database solutions. Sun's storage solutions division (solaris + hardware) will also be a signficant addition for Oracle because, and I repeat, Oracle's business is database solutions.
Do you understand that devloping *in* Java is not the same as developing Java?
Three, Java development stagnates. Does new Java development make any money at all for Sun right now? I don't think so. I think supporting the existing codebase is whats been bring money in.
You missed something.
The h264 support goes well beyond Windows, Linux, and OSX. Well beyond Firefox, Safari, Chrome, and Opera. Well beyond Flash and Silverlight. It doesnt matter what Google does. You can't give the millions of existing iPhones acceptable Theora support. You can't give the millions of existing netbooks acceptable Theora support. They *do* have accepable h264 support.
The hardware support for h264 is already cheap, low powered, and mass produced for these segments.
Oh, and Linux is still a novely..
What does Linux development have to do with the obvious advantages of hardware acceleration?
Put the keyboard on the touch screen and your specific arguement goes away.
I had seen a multi-touch demonstration with an on-screen keyboard and one of the things they were doing with the keyboard was adapting it to the user in realtime. The demonstrator was being intentionally sloppy and the keyboard did things like follow his hands as they drifted (even rotating)
Mark my words. Laptops will be off the market in 5 years, replaced by double-screen multi-touchers, and netbooks will be replaced by multi-touch tablets.
You honestly think that arbitrary C programs can be recompiled on different platforms?
It is *you* that is smoking something. Most of the time, you can't even use a different compiler on the SAME platform.
But what do you do if someone wants to run your code on an ARM or (gasp) an Alpha?
They can't. Most programs written in HLL's can't simply be recompiled either. What does this have to do with anything?
The poster claimed that compilers at better at optimizing than humans. Hes wrong. Thats all. All the other stuff he brings up is irrelevant to his error.
You may bluster on about owning all his books, but apparently you never actually read them because he has talked in a number of his papers and in the book Literate Programming about the faults of trying to optimize every single inefficiency and about how premature optimization can lead to performance problems in a program.
If you can quote me where I said anything to the contrary, that you make you look smart.
Since you can't, that makes you look stupid and juvenile.
umm, that increases the overall sales...
To top it off..
Suppose they sel 100 units, and then 54 of them get replaced with new units.. thats 154 units, with 35% being replacements (not the 54% you claim)
Please think more clearly, then choose your words more carefully.
I guess we actualy only need 46 super-computers in the world.
If this is FUD then Donald Knuth is the biggest spreader of FUD ever since he has talked about just such situations in his books.
Donald Knuth, the man uses his own assembly language when expressing algorithms? Pleeeeeaaaaaaseeeee....
I have all of his books (boxed set!), and even have all of the fasciles for the book he hasnt released yet. I've also watched all the videos online of his lextures/classes.
You picked the *wrong* name to be dropping. When you are conversing with a dedicated optimizer, thats the last person you should try to misrepresent. The second to last person you should try to misrepresent is Abrash.
I never did any such thing
You listed downsides of assembler and upsides of HLL's, while listing no upsides of assembler and no downsides of HLL's.
Maybe you just don't have the ability to detect your bias. As far as my assembler skill, I've been programming in x86 assembler since the 8086. I also use HLL's. I mix the two because I happen to choose the right tool for the job. I don't have this ignorant mindset that only one tool is great.
Woops, html ate that roll expression (it was shift right by c, or'ed with a shift left by 32-c)
Encryption algorithms use a wide variety of bit twiddling operations such as rotations
So do a lot of other algorithms, and that algorithm you thought couldn't take advantage of them, probably also can.
otherwise the compiler would have to be smart enough to see that what you are doing is a rotation.
Most are. This includes VC and GCC. They are smart enough to convert (x >> c) | (x
Still further, most compilers have rotation intrinsics (including VC, GCC, and ICC)
The compilers still arent good enough. The reason they don't do well in this case (*) isnt what you think. Its because they just arent very good at scheduling instructions in spite of the claims to the contrary, because its just too complex to be expressed in a set of heuristics. Its actualy also too complex for humans most of the time, but humans have tools that allow them to find the scheduling inefficiencies during real world execution, and those can only be addressed in assembler.
(*) This case is actualy a simple one. Cache considerations are fairly minimal and the work that needs to be done isnt all that complex (its just tedious)
But any good programmer has learned that rewriting all parts of a program in assembler does not always gain significant returns for your effort and in some cases these "optimizations" can actually have deleterious effects on the overall execution speed of the program.
I beg to differ. Most good programmers think that their C compiler beats out assembler. Most good programmers are wrong, in spite of being good.
And, if something has a negative effect then its not an optimization. Programmers do this thing called profiling, so they KNOW what effect the change has. You are spitting up FUD here. Unlike HLL programmers, asm programmers seeking performance are constantly profiling, and I am not talking about the kind of crappy profiling that most C++ programmers do either. Most of the features of VTUNE and CodeAnalyst are worthless to HLL programmers (pipeline simulations, for example) but give the asm programmer the ability to really and truely ramp things up. They dont understand that the abstract machine they target is just a stunted toy compared to real machines.
Not to mention the fact that there are numerous assembly language programmers that just flat out suck at coding in it and can in many cases produce slower code than that output from a compiler (have seen this in many cases).
This isn't news. This is a well known concept fully backed by research. Skill Level > Language Choice. While its true, its also irrelevant.
There is no guarantee that just cause you wrote it in assembly that it's going to be faster than a compiled C/C++ program.
There is if (A) I wrote it, (B) I'm finished, (C) It wasn't something trivial.
HLL's have their place. When performance isnt a concern they are great. The rest of your points are all about when performance isnt a concern. So *clap* *clap* *clap* hurray for you pointing out that assemblers have their limited place while refusing to admit that compilers also have their limited place.
..and thats why the fastest encryption libraries are written in high level languages, right?
..and to top it all off, if you arent using ICC then your compiler is shitty even compared to other compilers. The easiest optimization a VC or GCC programmer can make is to switch to ICC.
oh, erm.. encryption algorithms need the exact things you claim compilers are great at, yet the fastest encryption libraries are in hand-written assembler.
The fact is that this "compilers are better than humans" meme is complete bullshit and has always been bullshit. This fact can clearly be demonstrated by looking at the change logs of those compilers. For well over a decade this meme has been out there and for well over a decade there has been continual performance improvements to those compilers..
What it all boils down to is that HLL's use an abstract machine that has nothing at all to do with the real world details of computing on a specific architecture, and that my friend is why hand written essembler will always win the performance war.