as implemented in the linux kernel for a particular architecture, how'd he go about proving himself wrong?

I mean, wouldn't we expect the kernel's implementation to be mature, the product of many eyes, and hard to improve upon? Why would the kernel's implementation not be as fast as possible (all other things about code size and performance tradeoffs given various parameters being more or less equal)?

Is a speed 9/10ths to 4/5ths of the kernel's speed a non-negligible increase?

How'd you test your implementation on various platforms, given that you only have one particular platform of this architecture?

If you were still convinced you had a faster algorithm, to whose attention would you bring it? How?

When I first began noticing my faster algorithms, I chalked it up to stress. I'd been logging a lot of late hours at work, and my girlfriend wasn't returning my phone calls. (Sure, she said my kernel implementation wasn't mature enough, and she needed more from a man, but I thought we were doing okay. I mean, I keep the seat up, right?)

I think I've done the hard work, here. I've gone to the seminars about How To Improve Your Architecture and all like that, I consider myself a pretty liberated male. I even filled out the little manual they gave out at the Conference Center about the Seven Steps to Highly-Improved Time Efficiency.

But nothing worked. I even got my ass chewed by the boss at our last C Stdlib Function, right by the Christmas Tree and everything.

So now - I have no job, no girlfriend and you think you have the right to bitch?

The Linux kernel is far from mature or hard to improve upon. Read the more recent LKML submissions to get a feel for how to submit your patch, make one for the latest kernel, and send it in (and do follow kernel coding standards carefully - you'll be mocked and rejected immediately if you don'). Libc also still has room for improvement, particularly string handling. I'm sure the GNU page has contact info for patch submission.

I'm not sure about testing on various platforms, we at [Large Enterprise Linux Distro] have a large multi-architecture build & test farm that we were supposed to be giving people access to, but I don't think it's been opened to the public yet.

Well, having many eyes look at code doesn't make it better, some of those eyes have to actually come up with improvements. You just may be some of those eyes.

But your assumptions about the common average data set and the orignial implementors may be different, as may your trade-offs between common and edge cases.

Look at the mailing lists as cmonkey suggests, and submit your patch, the worst case is that it's not accepted.

Thanks guys.