That thing that identifies you that you know? Its called a password (or sometimes passphrase).
The more passwords you have, the less attempts are necessary.
Worse still: These "passwords incase you forget your password" are things lots of people might know.
Passwords are only as strong as their secrecy, and since two is no better than half as good, these systems are _less_ secure than having a single password.
They do, however, have a benefit- and that's the cost of creating a new account. Users that have forgotten their password might click the forgot-password button instead of create-new-account, and it might just keep the number of accounts low.
Unfortunately, it's usually better to just delete the old accounts, since that keeps the number of "accounts" closer to the number of "active accounts" _AND_ it means there are less targets to attack.
Clustering means too many different things these days. I operate several clusters- but they're all so different that I can't say that any of them are the same.
I run ClamAV and Spamassassin- both very slow programs- with cexec which simply lets me farm regular unix tools across multiple (lots) of CPU servers. This lets me replace the clamscan and spamc programs with "wrappers" that use my farm. I like cexec because it doesn't make me create lists of clients and servers, but automatically load balances and fails out very nicely.
For my frontend web servers, I use fake/heartbeat and some custom proxy software for routing frontend requests to backend farms.
I haven't found a real reliable replicated directory- with one, I could use cexec as a filesystem... Maybe some day...
The real initial question is: Why would an advertiser want to pay money to reach someone not within their target market? The answer: They don't. The follow-up question: Why then don't advertisers use these available technologies to tackle this issue? The answer: They are behemoth, archacic, and stupid.
Well, they're historically sucessful. It's kind of hard to call someone stupid and have them believe it if they've enjoyed success in the past. After all, the only option at that point would be that they were "lucky", and nobody wants to believe their business venture succeeds through luck alone. It hurts their marketability:)
What's probably more accurate is that they're ignorant to why advertising may have worked in the past, and they have forgotten how to accurately measure it. As a result, I'm pretty sure advertisers believe that if they just get their ads watched more, they'll receive more conversions, and that means more money.
Unfortunately, it's just not true. Advertising is about informing people, and if people don't want that information, you should make every effort to pay less so that you're only spending for the information you're actually providing.
Because brand identity and recognition is important to successful marketing
That's a load of crap. Marketing is successful if it leads to conversions. It's unsuccessful if it doesn't.
Some of the best marketing is done by getting buy-in without brand identity or recognition- Wal*Mart Equate, for example, doesn't use the Wal*Mart logo, and the name is almost unknown- even to the people buying it. They buy it simply because they don't recognize the name, because they know that it's the same thing as the drug with the name that they do recognize.
Now. Sometimes brand identity and recognition leads to conversions, and I think what you're trying to say is that advertising is one part of a marketing campaign, but not the only one. I hope you really don't mean to say that brand identity and recognition is what advertising is about, and I really hope you don't mean that advertising is equal to marketing.
But back to the topic: In reality, however, if someone skips your ad, it didn't contribute to anything except a waste of your money.
Why are advertisers interested in paying for ads that people aren't interested in?
Surely, if they helped TiVO become mainstream and omnipresent, they'd be able to target their advertisement dollars better, but until they do, they're only going to know about a bunch of geeks think about their ads, not necessarily the least useful cross-section of their viewers, but probably the least forgiving.
So why do they [the advertisers] fight TiVO every chance they get?
Presuming that you are being facetious with your terminology, he doesn't act because he can't; there is nowhere near the support necessary for these sorts of actions in congress. He's done as much as he can: banned stem cell funding, stock the Supreme Court with conservatives, spoken out on gay marriage. He does not, as you contend, control the other branches of government.
So wait a minute, you're telling me that the guy can kill a thousand americans, tens of thousands of foreigners, raise taxes, start a war, expose state secrets, wiretap americans, stop american wiretransfers, put people in jail for as long as he damn well feels like it, and cover up a nipple on a statue, but he can't make a few executive orders for his "value voters"?
I'm sorry, I don't buy it. I'm not going to believe for a minute that throwing a writer in jail for something they didn't write about, is easier that throwing (what he calls) a murderer in jail.
If I was a conservative Christian (and I'm not), then I'd be pleased with what he's done, even if I were frustrated at the pace.
I think that's my point, that they are pleased with what he's done. I'm saying that its morally wrong for them to be pleased with what he's done, and that they shouldn't be pleased with what he's done.
Christianity really isn't a philosophy that can be adapted individually, like buddhism. It has well defined principles guiding morality, as defined in the entire Christian Greek scriptures.
I agree completely.
Now excuse me while I sell my daughter into slavery, murder all the people at the seafood resturaunt, and anyone I can find eating pork.
It already IS a Christian-run state, by the simple fact that Christians are the overwhelming majority in the US. What I think you mean to imply is that he would like the Christian ideals further forced upon all in the US, even non-Christians. For instance, he would like to ban stem cell research, abortion, and gay marriage because they conflict with his notion of Christian values.
Then why doesn't he?
He controls the house, the senate, and the courts, why the fuck doesn't he just stop the faggots and the baby-murders if it's an affront to his values!?
The Dems and Reps are BOTH beholden to corporate interests and Wall St. bankers. Choosing which of the 2 major parties to vote for is simply choosing WHICH set of corporate swine you want pulling the strings in DC.
Actually, not so much anymore, especially with the Delay K-street missions. Since Republican party controls all four branches of government right now (Executive, Legislative, Judicial, and Oversight^H^H^H^H^H^H^H^H^Hthe Media), I hope it's not exactly a big secret that coporate lobbyists are told that they either give to the GOP exclusively, or they'll be "shut down" by Republican votes.
Remember the "friendly donors" v. "unfriendly donors" lists?
What I don't understand is the Value Voters. Surely if the "representatives" were all about constitutionally protecting the American flag, mokney-ancestry [sic], fetus-rights, and faggot-beating, they'd have done so by now. Surely it's obvious to so-called Value voters that their party isn't the slightest-bit interested in their values unless it's time for re-election.
Back in the '90s they might have been able to say they didn't have a chance of getting it law, but now? They got wiretaps and secret prisons, and can put journalists in jail when the vee-pee's assistant breaks the law, they most certainly can get these laws passed if they really want to.
We offer all our customers non-proprietary services as well, but for significantly more money (150% costlier, actually). Our rates on our proprietary services are about 40% cheaper than the competition and we've proven our reliability by being in business for 16 years without a loss in that time frame.
So what? You're the good guy?
Even if I accept that, there are far more WAL*MARTs, Microsofts, and Enrons than you.
The market is providing for every consideration you threw at me here, keep them coming so I can find one that really requires the State to regulate.
This is what makes me worried. We need stronger state regulation. Microsoft has already been convicted of hurting people and companies, and their penalty allows them to continue to hurt people.
People that believe in Free Markets are either crooks or naive. Open Markets help people by guaranteeing that a market can never be closed to a single company, and that successes in one market cannot translate automatically (i.e. in the absense of a good product) into another.
No.. without the presence of the DMCA there would be a huge sector of our economy right now devoted to producing DRM cracks, one of which would be for your program.
So what you're saying is that in the absense of the DMCA, there wouldn't any DRM because any DRM that companies tried to make would be broken immediately.
Well, it may be, but you're still missing Grand Parents point.
If you believe in the free market, then DRM doesn't matter. Just as companies should be allowed to do whatever they want to stuff before you sell it, you should be able to do whatever you want with it after you bought it.
But I don't believe in a free market, and no sane economist does. Free Markets produce monopolies that are harmful to their customers. Free Markets produce more Enrons, Wal*Marts, and Microsofts than they do good.
I believe in an Open Market.
Isn't that tantamount to extortion?
They did defraud you? Did they lie? What does your contract say? What did they advertise their product with?
If they didn't in any way make any statements about how long your software would live, it's still your fault. If you bought a mission-critical piece of software from a non-reputable vendor, without checking messageboards or previous customers at all, I think you pretty much deserve what you got anyways.
Actually, the company that did this is convicted monopolist, and as a monopoly they were able to hurt lots of people this way.
I'm a vocal pro-market advocate, and I don't see any problems with DRM. If you have something you want to keep out of prying eyes, you should be free to protect it in any way possible -- including making it ultra-proprietary.
You're confused. DRM is about you keeping customers away from their data, not you keeping customers away from your data.
If I buy an accounting and compliance package, and it timebombs six months into full use, I should be able to buy another one, and transfer my data. I should be able to pay someone else to transfer that data because I feel the first vendor was untrustworthy.
DRM means I must pay the first vendor, or go out of business (compliance laws). Never mind what happens if they go out of business- I have no options anymore.
Now, you might think the government has no business protecting people from incompetent companies, what if the vendor did this on purpose? What if that company deliberately set up their accounting package to explode so that they could underbid the competition and recoup the costs later? Isn't that tantamount to extortion?
If the structure is meant to be interacted with directly by the program using the library, then it's not an internal data structure for the library, now is it ? Internal data structure would be something that the program doesn't even know exists.
No, but I mean the problem occurs because people aren't thinking ahead.
At least in Linux OpenGL library is part of the display driver package, and gets updated with the driver, and the new version may differ internally from the old (optimization, utilizing a new internal interface to the kernel driver, etc). So, as far as I can tell, if you inline functions from it you may run into very serious problems when it gets updated.
Err, you're referring to NVIDIA's "GL" drivers. If NVidia supported GLX correctly, this wouldn't be necessary.
Nonetheless, _those_ GL drivers _are_ tightly bound to the nvidia drivers, and as a result, _do_ get updated at the same time.
"Design flaw" suggests that they didn't consider this scenario. This is false. They absolutely did consider this scenario and decided it was still a good decision due to the performance implications. The developer documentation clearly warns against displaying high-priv GUI on a low-priv desktop.
How the hell do you know what "Microsoft" was considering? There's no documentation on this distributed with the Windows 3 SDKs, nor with Microsoft OS/2, or if there is, I can't find it.
I'm not sure what's worse! That they knew programmers couldn't tell it was a bad idea, and kept it secret, or that they didn't have the forethought and just got caught with their pants down.
I suspect they didn't know about it simply because a lot of Microsoft software was succeptable to this problem, but hey, if you're saying that they knew about it and just hate their customers and developers, well then I'll just have to take your word for it, because you're clearly on the Internet.
... then the library got updated. The user thinks that the program is using the new library, but in reality at least some of the functions used - the inlined ones - are from the old library.
This problem exists without inlining: What happened when Debian replaced libdbd-sqlite-perl with one that linked to libsqlite3? Everyone's SQLite databases stopped working.
But see below.
It's even more fun if the inlined functions handled some datatype internal to the library, and that datatype got changed during the update, resulting in memory getting randomly corrupted without any sensible reason.
This problem exists without inlining: libSDL changed the interior of the SDL_SysWMinfo structure- a structure that's designed to be interacted with directly. Programs that did so, when libSDL was upgraded, crashed..
Even better, suppose that the library in question is really a hardware access layer like OpenGL, and the compiler inlines some functions from it - do you need to recompile all OpenGL programs because you updated the display driver ?-)
In practice this can't happen because the OpenGL library doesn't bind directly to the HAL. If the dynamic linker did this (on the other hand) we might have more of an issue.
Actually, it wouldn't be such a bad idea to let the dynamic linker do it. If i386 had real PIC support, we could have a object format that represented a bunch of GLUE(a,b,c) functions that would resolve the appropriate code section at load-time. If the kernel knew about our GLUE() function, it could preserve mappings, say using mmap() with MAP_GLUE or something.
I see an implied non-sequitur here: Just because something can be altered BY an algorithm, it doesn't follow that the alteration represents a change OF an algorithm. (I'm not attacking the rest of that argument though)
Fundamentally? Probably not.
I think while it's helpful to point at an implementation and say "That is the PATRICIA algorithm" to mean it's the algorithm Morrison described, but what if they change some aspect? Maybe reorder some steps? Some algorithms - even presented in "formal papers" - are extremely sensitive to changes.
It may be helpful to say they model the same original function - that is, given the same inputs this new algorithm produces the same outputs as the original, but it can hardly be said that it's the same algorithm if it performs so differently.
Now you start to seem like you have a too broad view of what algorithmic improvement is. Algorithms have nothing to do with code, they're a level of abstraction above (as you can see in any scientific paper presenting a new algorithm, they rarely give anything more than pseudocode). Instruction scheduling is NOT an algorithmic improvement, it's an platform dependent implementation detail.
I think this is our sticking point then, because I do view instruction scheduling as an algorithmic improvement. I don't think I'm alone on this, djb has written a large number of papers regarding algorithm in this way, and he refers to other papers by other authors that regard algorithm in this way.
I think the reason many papers come with pseudocode has to do with the attention of the paper, and that many processes are improved with algorithms that produce big results in pseudo-code. Can you tell me that you never see a paper on processor scheduling algorithms? Or what about new circuits to take advantage of, or in the development of new scheduling algorithms?
Their FAQ answer which says compilers aren't good at it just shows that they also think a human is better at optimizing code.
I did not disagree with this. I only state that choice of language is a much smaller part of code optimization than is stated.
Even the only one which doesn't mention asm explictly is speaking about registers, which you can't manipulate directly in C. I don't want to sound like an ass but at least show some knowledge regarding what we're talking about...
First of all, the compiler can be instructed to use a register-passing ABI instead of using the stack. This is incompatible with other libraries, which is probably why he didn't use -mregparm so easily.
Secondly, he's talking about examining the assembly output, and tuning the input to tune the output. Look at the source, it's all C. It's layout is based heavily on the assembly that is produced by the compiler- but because it's C, it still _works_ on platforms that it hasn't been explicitly optimized for.
The assembly he's talking about is the MMX operations- he's used them in other projects.
And to clarify: my point is there a good assembly programmer can often do much better than any compiler, and that things will stay that way for some time to come. Eventually the situation may be the opposite, but right now it surely isn't!
I'll agree with this to a point: There are so few good assembly programmers, that anyone who says they are almost certainly is not. Furthermore, so few problems benefit the most from this method, that it is almost always prudent to disclaim any demonstrated improvement. Changing the algorithm almost always helps more.
Well, the code in question was a tight mathematical routine belonging to a distributed computing of a quite well known project, which was originally programmed by a mathematician and then adapted by another mathematician who is also a very good programmer.
If your assembly was better than his C, then you must have a forgiving definition of the term "good".
In fact, someone (later) came up with slightly faster code for the same routine. Unfortunately for your hypothetical argument, also coded in assembly.
Did you misunderstand me? I alluded that most speedups come from algorithmic shifts, rather than implementation shifts. But because of the mythos surrounding assembly programming, people believe just rewriting inner loops in assembly will get them better performance. djbfft demonstrates this is not the case.
Amusingly, check out this excerpt from the FAQ at the page you pointed to:
Check the source. It wasn't written in assembly. The entry you point to: Don't modern compilers take care of instruction scheduling? is highly revealing. The fact that djbfft was written in C demonstrates it's still possible to handle these things from C code. It demonstrates that there are more valuable speedups gained from a better algorithm.
And, a look at the TODO file reveals stuff such as: do properly scheduled Pentium/PMMX asm, pass parameters in registers, organize asm to fall through function entry when possible, organize asm to reduce i-cache pressure
So the author knows how to improve the algorithm. Why does this surprise you? You'll note that only one of them suggests writing assembly code, and it's to handle an obsolete case.
So thanks for helping me prove my point...
Your point? That assembly is faster than C? All you've demonstrated is that someone's assembly is faster than someone elses' C. I've provided an example: C code that outruns commonly used assembly. Is it necessary that you define assembly as the faster implementation, in order to prove it's faster than C? Will you need to say that "well, nobody has bothered to implement a faster FFT yet" in order to maintain your argument?
Correction: your C compiler is fater at multiplying by 9 than crappily written assembler. Thats a pretty small corner you've got yourself and your case into there.
So where do you draw the line? If it's faster than C code, then you've got an expert assembly programmer? So therefore, assembly is faster than C?
Yes: there are cases where expert assembly has beaten expert C, but those are extremely rare. More often, it's amateur assembly beating amateur C, when a better improvement would've been seen by an expert C programmer for the given architecture.
Consider: djbfft and note that it's written in C and yet outruns most implementations of FFT- including lots of those implemented in assembly. And it's still portable.
The more abstract a language is, the better a compiler can understand what you are doing
Except it doesn't. Nobody has written a compiler that smart, and I don't care what anyone says: I don't think anyone ever will.
Learning how to invent and develop algorithms is important. Learning how to translate those algorithms into various languages is important. And knowing how the compiler will translate those algorithms into machine instructions- and how the CPU itself will process those machine instructions, will yield a lot more performance than choice of languages.
Consider djbfft, one of the fastest FFT implementations, outruns many FFT implementations in Java, Haskell, Lisp, or assembly, and yet it's written in C.
Don't confuse me: I'm not saying C is fast, or C is good, I'm saying djbfft is good. Reordering the instructions in the C code will lower the efficiency- even if the code is otherwise equivelent.
That said, I agree with almost everything else in your post.
Not many years ago (with gcc), I got an 80% speed improvement just by rewriting a medium sized function to assembly.
And not many years ago (with gcc), I got a 700x speed improvement by rewriting (a coworkers) assembly inner-loops into C.
Does it even bother you to think for a minute that you might have chosen a slow algorithm to begin with?
I generally don't bother unless the optimization will bring me orders of 700x improvements, and then usually it's the algorithm that's flawed, and not the compiler. And believe me, I've written a large number of really flawed algorithms:)
An expert assembly programmer in a CPU which he knows well can still do much better than a compiler.
Consider djbfft, which is written in C, and yet outruns many FFT implementations that are written in assembly, some of which were written by experts.
I'm pretty sure lots of "expert programmers" have written FFT implementations, but they aren't expert algorithm designers, and I'll say with certainty that counts a lot more than whether you use assembly language or not.
No. Well, generally you'll have faster code if you code it in assembly.
I don't know about that. MY compiler knows it can multiply by nine fast using: lea eax,[edx][edx*8] but I know lots of people that "write in assembly" that still don't.
Result? My C compiler is faster than their assembly.
Compare the efficiency of GCC at auto-vectorising FORTRAN (which has a primitive vector type) and C (which doesn't), if you don't believe me.
In general, vectored operations are in the realm of hardware-specific stuff. FORTRAN's vector type doesn't translate into vector instructions for all sizes of vectors, and for all compilers, and for all systems. I'm not saying I don't love it, I'm just saying, it's not going to be the reason I write everything else in FORTRAN.
In practice, GCC's vector extensions are "pretty good", and GCC is on loads of architectures and platforms. So these days, and for the majority of C programming that goes on, I'd venture to say that GCC is C.
When you pass a C file to a compiler, it generates an object file. It has absolutely no way of knowing where functions declared in the header are defined. You can hack around this; pass multiple source files to the compiler at once and have it treat them as a single one, for example, but this falls down completely when the function is declared in a library (e.g. libc) and you don't have access to the source.
That's not true. The compiler can load the libraries, and remove the prolog and epilog of the function call and insert it directly into the object. I've written compilers that do this, it's not even very hard.
Slashdot Mirror
When will we see bindings for the most popular language?
That thing that identifies you that you know? Its called a password (or sometimes passphrase).
The more passwords you have, the less attempts are necessary.
Worse still: These "passwords incase you forget your password" are things lots of people might know.
Passwords are only as strong as their secrecy, and since two is no better than half as good, these systems are _less_ secure than having a single password.
They do, however, have a benefit- and that's the cost of creating a new account. Users that have forgotten their password might click the forgot-password button instead of create-new-account, and it might just keep the number of accounts low.
Unfortunately, it's usually better to just delete the old accounts, since that keeps the number of "accounts" closer to the number of "active accounts" _AND_ it means there are less targets to attack.
Clustering means too many different things these days. I operate several clusters- but they're all so different that I can't say that any of them are the same.
I run ClamAV and Spamassassin- both very slow programs- with cexec which simply lets me farm regular unix tools across multiple (lots) of CPU servers. This lets me replace the clamscan and spamc programs with "wrappers" that use my farm. I like cexec because it doesn't make me create lists of clients and servers, but automatically load balances and fails out very nicely.
For my frontend web servers, I use fake/heartbeat and some custom proxy software for routing frontend requests to backend farms.
I haven't found a real reliable replicated directory- with one, I could use cexec as a filesystem... Maybe some day...
What's probably more accurate is that they're ignorant to why advertising may have worked in the past, and they have forgotten how to accurately measure it. As a result, I'm pretty sure advertisers believe that if they just get their ads watched more, they'll receive more conversions, and that means more money.
Unfortunately, it's just not true. Advertising is about informing people, and if people don't want that information, you should make every effort to pay less so that you're only spending for the information you're actually providing.
Actually, that's kind of how the Internet works.
Because brand identity and recognition is important to successful marketing
That's a load of crap. Marketing is successful if it leads to conversions. It's unsuccessful if it doesn't.
Some of the best marketing is done by getting buy-in without brand identity or recognition- Wal*Mart Equate, for example, doesn't use the Wal*Mart logo, and the name is almost unknown- even to the people buying it. They buy it simply because they don't recognize the name, because they know that it's the same thing as the drug with the name that they do recognize.
Now. Sometimes brand identity and recognition leads to conversions, and I think what you're trying to say is that advertising is one part of a marketing campaign, but not the only one. I hope you really don't mean to say that brand identity and recognition is what advertising is about, and I really hope you don't mean that advertising is equal to marketing.
But back to the topic: In reality, however, if someone skips your ad, it didn't contribute to anything except a waste of your money.
Why are advertisers interested in paying for ads that people aren't interested in?
Surely, if they helped TiVO become mainstream and omnipresent, they'd be able to target their advertisement dollars better, but until they do, they're only going to know about a bunch of geeks think about their ads, not necessarily the least useful cross-section of their viewers, but probably the least forgiving.
So why do they [the advertisers] fight TiVO every chance they get?
I'm sorry, I don't buy it. I'm not going to believe for a minute that throwing a writer in jail for something they didn't write about, is easier that throwing (what he calls) a murderer in jail.
I think that's my point, that they are pleased with what he's done. I'm saying that its morally wrong for them to be pleased with what he's done, and that they shouldn't be pleased with what he's done.
There's a huge difference.
I agree completely.
Now excuse me while I sell my daughter into slavery, murder all the people at the seafood resturaunt, and anyone I can find eating pork.
He controls the house, the senate, and the courts, why the fuck doesn't he just stop the faggots and the baby-murders if it's an affront to his values!?
Remember the "friendly donors" v. "unfriendly donors" lists?
What I don't understand is the Value Voters. Surely if the "representatives" were all about constitutionally protecting the American flag, mokney-ancestry [sic], fetus-rights, and faggot-beating, they'd have done so by now. Surely it's obvious to so-called Value voters that their party isn't the slightest-bit interested in their values unless it's time for re-election.
Back in the '90s they might have been able to say they didn't have a chance of getting it law, but now? They got wiretaps and secret prisons, and can put journalists in jail when the vee-pee's assistant breaks the law, they most certainly can get these laws passed if they really want to.
Even if I accept that, there are far more WAL*MARTs, Microsofts, and Enrons than you.
This is what makes me worried. We need stronger state regulation. Microsoft has already been convicted of hurting people and companies, and their penalty allows them to continue to hurt people.
People that believe in Free Markets are either crooks or naive. Open Markets help people by guaranteeing that a market can never be closed to a single company, and that successes in one market cannot translate automatically (i.e. in the absense of a good product) into another.
I'm all for returning to pre-DMCA laws...
I believe in an Open Market.
Actually, the company that did this is convicted monopolist, and as a monopoly they were able to hurt lots of people this way.
You're confused. DRM is about you keeping customers away from their data, not you keeping customers away from your data.
If I buy an accounting and compliance package, and it timebombs six months into full use, I should be able to buy another one, and transfer my data. I should be able to pay someone else to transfer that data because I feel the first vendor was untrustworthy.
DRM means I must pay the first vendor, or go out of business (compliance laws). Never mind what happens if they go out of business- I have no options anymore.
Now, you might think the government has no business protecting people from incompetent companies, what if the vendor did this on purpose? What if that company deliberately set up their accounting package to explode so that they could underbid the competition and recoup the costs later? Isn't that tantamount to extortion?
Err, you're referring to NVIDIA's "GL" drivers. If NVidia supported GLX correctly, this wouldn't be necessary.
Nonetheless, _those_ GL drivers _are_ tightly bound to the nvidia drivers, and as a result, _do_ get updated at the same time.
I'm not sure what's worse! That they knew programmers couldn't tell it was a bad idea, and kept it secret, or that they didn't have the forethought and just got caught with their pants down.
I suspect they didn't know about it simply because a lot of Microsoft software was succeptable to this problem, but hey, if you're saying that they knew about it and just hate their customers and developers, well then I'll just have to take your word for it, because you're clearly on the Internet.
But see below.
This problem exists without inlining: libSDL changed the interior of the SDL_SysWMinfo structure- a structure that's designed to be interacted with directly. Programs that did so, when libSDL was upgraded, crashed..
In practice this can't happen because the OpenGL library doesn't bind directly to the HAL. If the dynamic linker did this (on the other hand) we might have more of an issue.
Actually, it wouldn't be such a bad idea to let the dynamic linker do it. If i386 had real PIC support, we could have a object format that represented a bunch of GLUE(a,b,c) functions that would resolve the appropriate code section at load-time. If the kernel knew about our GLUE() function, it could preserve mappings, say using mmap() with MAP_GLUE or something.
Just wacky thoughts at that point...
I think while it's helpful to point at an implementation and say "That is the PATRICIA algorithm" to mean it's the algorithm Morrison described, but what if they change some aspect? Maybe reorder some steps? Some algorithms - even presented in "formal papers" - are extremely sensitive to changes.
It may be helpful to say they model the same original function - that is, given the same inputs this new algorithm produces the same outputs as the original, but it can hardly be said that it's the same algorithm if it performs so differently.
I think the reason many papers come with pseudocode has to do with the attention of the paper, and that many processes are improved with algorithms that produce big results in pseudo-code. Can you tell me that you never see a paper on processor scheduling algorithms? Or what about new circuits to take advantage of, or in the development of new scheduling algorithms?
I did not disagree with this. I only state that choice of language is a much smaller part of code optimization than is stated.
First of all, the compiler can be instructed to use a register-passing ABI instead of using the stack. This is incompatible with other libraries, which is probably why he didn't use -mregparm so easily.
Secondly, he's talking about examining the assembly output, and tuning the input to tune the output. Look at the source, it's all C. It's layout is based heavily on the assembly that is produced by the compiler- but because it's C, it still _works_ on platforms that it hasn't been explicitly optimized for.
The assembly he's talking about is the MMX operations- he's used them in other projects.
I'll agree with this to a point: There are so few good assembly programmers, that anyone who says they are almost certainly is not. Furthermore, so few problems benefit the most from this method, that it is almost always prudent to disclaim any demonstrated improvement. Changing the algorithm almost always helps more.
Did you misunderstand me? I alluded that most speedups come from algorithmic shifts, rather than implementation shifts. But because of the mythos surrounding assembly programming, people believe just rewriting inner loops in assembly will get them better performance. djbfft demonstrates this is not the case.
Check the source. It wasn't written in assembly. The entry you point to: Don't modern compilers take care of instruction scheduling? is highly revealing. The fact that djbfft was written in C demonstrates it's still possible to handle these things from C code. It demonstrates that there are more valuable speedups gained from a better algorithm.
So the author knows how to improve the algorithm. Why does this surprise you? You'll note that only one of them suggests writing assembly code, and it's to handle an obsolete case.
Your point? That assembly is faster than C? All you've demonstrated is that someone's assembly is faster than someone elses' C. I've provided an example: C code that outruns commonly used assembly. Is it necessary that you define assembly as the faster implementation, in order to prove it's faster than C? Will you need to say that "well, nobody has bothered to implement a faster FFT yet" in order to maintain your argument?
Yes: there are cases where expert assembly has beaten expert C, but those are extremely rare. More often, it's amateur assembly beating amateur C, when a better improvement would've been seen by an expert C programmer for the given architecture.
Consider: djbfft and note that it's written in C and yet outruns most implementations of FFT- including lots of those implemented in assembly. And it's still portable.
The more abstract a language is, the better a compiler can understand what you are doing
Except it doesn't. Nobody has written a compiler that smart, and I don't care what anyone says: I don't think anyone ever will.
Learning how to invent and develop algorithms is important. Learning how to translate those algorithms into various languages is important. And knowing how the compiler will translate those algorithms into machine instructions- and how the CPU itself will process those machine instructions, will yield a lot more performance than choice of languages.
Consider djbfft, one of the fastest FFT implementations, outruns many FFT implementations in Java, Haskell, Lisp, or assembly, and yet it's written in C.
Don't confuse me: I'm not saying C is fast, or C is good, I'm saying djbfft is good. Reordering the instructions in the C code will lower the efficiency- even if the code is otherwise equivelent.
That said, I agree with almost everything else in your post.
Does it even bother you to think for a minute that you might have chosen a slow algorithm to begin with?
I generally don't bother unless the optimization will bring me orders of 700x improvements, and then usually it's the algorithm that's flawed, and not the compiler. And believe me, I've written a large number of really flawed algorithms
Consider djbfft, which is written in C, and yet outruns many FFT implementations that are written in assembly, some of which were written by experts.
I'm pretty sure lots of "expert programmers" have written FFT implementations, but they aren't expert algorithm designers, and I'll say with certainty that counts a lot more than whether you use assembly language or not.
Result? My C compiler is faster than their assembly.
But besides that, I agree with your post
In practice, GCC's vector extensions are "pretty good", and GCC is on loads of architectures and platforms. So these days, and for the majority of C programming that goes on, I'd venture to say that GCC is C.
That's not true. The compiler can load the libraries, and remove the prolog and epilog of the function call and insert it directly into the object. I've written compilers that do this, it's not even very hard.