MetaChat REGISTER   ||   LOGIN   ||   IMAGES ARE OFF   ||   RECENT COMMENTS




artphoto by splunge
artphoto by TheophileEscargot
artphoto by Kronos_to_Earth
artphoto by ethylene

Home

About

Search

Archives

Mecha Wiki

Metachat Eye

Emcee

IRC Channels

IRC FAQ


 RSS


Comment Feed:

RSS

05 July 2006

Linux kernel/C stdlib question Ok, if someone thought he'd improved the time-efficiency of a C stdlib function... [More:]
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?

posted by orthogonality 05 July | 15:30
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?
posted by Lipstick Thespian 05 July | 15:43
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.
posted by cmonkey 05 July | 15:51
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.

posted by Capn 05 July | 17:12
Thanks guys.
posted by orthogonality 06 July | 07:01
What parts would we play? || More rockin' recommendations.

HOME  ||   REGISTER  ||   LOGIN