[SlugLUG] Question on C
Suraj N. Kurapati
skurapat at ucsc.edu
Tue Oct 10 09:43:59 PDT 2006
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Erich Blume wrote:
> Problem is, while doing that, I completely forgot how to write C.
> I've re-trained myself up to the basics, but what I really want
> to do now is write a hash table implementation in C. I can't for
> the life of me figure out how to get started, though. I've
> written a few half-hearted structs, slapped down some frivolous
> typedefs, and even put in a few useless prototypes.
>
> So my question is: where can I get started for this particular
> project? Who knows of a good resource for easy to understand
> implementations of hash tables in C? If it's a book, that's fine,
> but it'd be better if you could point me to a web page or
> something.
http://www.sparknotes.com/cs/searching/hashtables/section1.html
> Also, something that's been bugging me is whether or not I should
> learn C++. Ever since I learned perl, I've been reluctant to
> learn C++, being as more or less the only time I ever plan on
> writing compiled code now will be to optimize. I'd rather
> optimize in C than C++.
It doesn't matter what language is used when optimizing, because
optimization should involve choosing the correct data structures and
algorithms to solve the problem at hand. This will yield far greater
improvement than if you had randomly tweaked the code with pointer
tricks, etc.
Also, to paraphrase Amdahl's law, "something is only worth
optimizing if it is used frequently." That is, don't waste your time
optimizing a bunch of slow code if that slow code is only used, say,
2% of the time.
This leads to the conclusion that in order to optimize, you have to
know what to optimize. And knowing what to optimize comes from
profiling!
> But I've been doing a lot of reading and it sounds like maybe
> that wasn't such a good appraisal. From the context of a
> computational biologist, what's the safer bet?
Here's what you do:
0. Compile with a high optimization level: gcc -O3
1. Profile your code and find the bottlenecks.
2. Improve your choice of data structures and algorithms used in
those bottlenecks.
3. If that doesn't help, try re-writing the really slow parts in a
lower-level language.
4. If even that doesn't work, go ahead and be tricksy with pointers
and loops. Perhaps if the planets have favorable alignment tonight,
those tricks might help you. ;-)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iD8DBQFFK83PmV9O7RYnKMcRAhuFAJ9qN+2bRLlwjnNq52DpXd/FxuY8lACePpHW
h3+UJg0/lZhIsPIHUUaLgWk=
=36Ru
-----END PGP SIGNATURE-----
More information about the Sluglug
mailing list