Slashdot Mirror


User: james_northrup

james_northrup's activity in the archive.

Stories
0
Comments
3
First seen
Last seen
Profile
(view on slashdot.org)

Comments · 3

  1. newsflash: most teams are lame on Star Trek - Elite Force II Goes Gold, Team Laid Off · · Score: 1

    This headline means nothing. this article offers few facts. Software talent doesn't go unnoticed, but it is easier to flush a team and approach individuals in private.

  2. technical infrastructure considerations w/cdma2k on CDMA vs. GSM in Post-war Iraq · · Score: 1

    cdma2000 is worthy of asking for by name.

    cdma2000 conveniently interoperates with cdma traffic while allowing cdma2000 features to resize the channel per frame to 2^[1-5] channels out of 128 total. (cdma only sees 64 fixed channels).

    as t goes to infinity so does infrastructure capacity double by this sort of channel-doubling.

    The equipment's sensitivity and noise filtering limits, defined by component cost, supports "g3" today, but the sky's the limit for your regime's application without compromising the installed base...

    I cant comment on any recent progress with gsm for fair contrast, except that it's a wee bit simpler to code for.

  3. Performance & size tests, c, gcc & stlport on Downsides to the C++ STL? · · Score: 4, Informative
    I have been held to the java grindstone for 7 years and growing steadily despondant wishing I were back designing swift running systems of elegant templates... so this weekend I sat down for a personal STL refresher.

    g++ is just what i needed for a fun and relaxing weekend of random hacks.

    I was goofing off with a trivial c++ hack that provides a base64 iostream iterator. I've heard for a while about the relative bloat and performance hits on the IO side of c++ and wanted a peek for myself.. what I found was halting.. 50x performance increase from a simple C hack, all of it IO. Well, not to be defeated so easily, I plugged in STLPort with its spiffy optimized IO and gave a whirl. What resulted was not 1:1 with C but reasonably in the realm of hand tunable for IO buffering thereafter... this was after all, code that reads and writes a byte at a time vs. a c program that uses buffers...

    the relative results of this effort were as follows: test were conducted streaming 1 meg of data to >dev/null on an athlon 1800xp under debian sid dist.

    buildtimesize

    gnu uuencode, from gnu sharutils, compiled c code. ~0.12 seconds/meg binary 9k

    base64.h: using g++-3.0.4 -O6 -static
    ~3.5 seconds
    binary size 895k

    base64.h: using g++-3.0.4 -O6 (shared)
    ~4.8 seconds
    binary size 6k

    base64.h: using g++ and stlport -O6
    ~0.45 seconds
    binary size 10k&7k, static and shared.