Catch up on stories from the past week (and beyond) at the Slashdot story archive

 



Forgot your password?
typodupeerror
×
Slashback

Slashback: Memory, Constancy, Triumph 278

Tonight's slashback with news of how you can help rebuild the foundations of the Internet (at least a small corner), more on slimming down the old Cathode Ray Tube, a new compiler which costs a bit more than GCC, and more.

Why not put 'em on Freenet while you're at it ... Imran Ghory writes: "Google has put out an appeal to get NetNews CDs (produced by Sterling Software and CD Publishing Corporation) which archived usenet between 1992 to 1995. Looks like Google is reviving Deja's idea of a total usenet archive."

This sounds like a worthy objective, worth rooting around for -- maybe they'll even give you a credit somewhere.

They know that of which they speak. Hot on the heels of the inexorable GCC project's 3.0.1 release, zealot (and a number of other people) wrote with the news that "Intel will release its latest compilers (the ones that optimize for P4 and can do some auto-vectorization of code) for Linux this Thursday. I'd love to see some performance numbers for compiled code on a P4 if anyone gets their hands on this ... maybe the autovectorization could help some gimp plugins speed up."

You cannot stop the chess updates Álvaro Begué writes: "Junior is the new World Micro Computer Chess Champion, Shredder won in the single processor category (five years in a row) and Goliath won the blitz tournament. Congratulations to all of them. Check out the official website."

Maybe the durned things will stick around forever. In addition to the IBM research on making ultra-slim CRT monitors, an Anonymous Coward points to another article on the future of CRTs: "This is a new technology that can integrate into existing production lines and can halve the depth of a CRT type tube. A TV normally 22 inches deep would be only 11 inches."

This discussion has been archived. No new comments can be posted.

Slashback: Memory, Constancy, Triumph

Comments Filter:
  • Thanks, MSNBC (Score:1, Interesting)

    by 4thAce ( 456825 ) on Thursday August 23, 2001 @08:16PM (#2211474) Homepage

    S-Cubed works by bending beams of electrons in a way that allows the electron gun -- which shoots out the beams -- to be moved closer to the screen.

    This, to me is like saying "S-Cubed works by making CRTs smaller." With what, hyperspace? Gee, do you think you could be a little more specific?

    Would appreciate it if someone could find a relevant patent application.

  • by mikeage ( 119105 ) <.slashdot. .at. .mikeage.net.> on Thursday August 23, 2001 @08:17PM (#2211476) Homepage
    ...do they really work? If so, why doesn't AMD develop similar software for Athlons? Are they just too small... or is the intel stuff a bunch of marketing phooey for PHB's to swallow? Are there any more questions?
  • Re:GCC vs. Intel (Score:0, Interesting)

    by Anonymous Coward on Thursday August 23, 2001 @08:21PM (#2211496)
    It's bloated because every language and its mother is in there. What's wrong with breaking out the different language compilers into separate binaries? Or course, there's nothing really wrong with having a single binary that contains various languages.
  • Re:Compiler costs (Score:4, Interesting)

    by kurt555gs ( 309278 ) <<kurt555gs> <at> <ovi.com>> on Thursday August 23, 2001 @08:47PM (#2211594) Homepage
    The new corperate america, u would think Intel would be giving this away seeing how AMD is kicking their butts and without this optimization the P$ is a slug.

    Now they want to charge to make their dog chip work right?

    and no one else sees this?
  • Flattest CRT (Score:4, Interesting)

    by computechnica ( 171054 ) <PCGURUNO@SPAMCOMPUTECHNICA.com> on Thursday August 23, 2001 @09:05PM (#2211657) Homepage Journal
    Candescent Technologies [candescent.com] has been working on this technology since 1991 and it looks like its about ready to go prime time with it. It has the same brightness, contrast, refresh time, and viewing angle that normal CRTs have but uses less power than LCDs in the same size package. Can't wait to hang one of these on the wall.

  • KDE C++ question (Score:1, Interesting)

    by Anonymous Coward on Thursday August 23, 2001 @09:33PM (#2211722)
    Objprelink produces code that loads quicker - but is it at the expense of slower code - all virtual function jmp to a jmp of the real virtual function?
  • by Bob_Robertson ( 454888 ) on Thursday August 23, 2001 @09:45PM (#2211752) Homepage
    An LCD, at 30 Watts, is a substantial cost savings to use, especially when you have lots of screens.


    Yes, they cost more, but what are you really paying for?


    I'd also be curious about recycle potential. There is much less material in an LCD, how about polution from disposal? How much of that can be reused and recycled? How about compared to a CRT?


    Bob-

  • How is there any "may" about this? IBM would have to be nuts to not license this technology to a mass-producer or two, they'll rake in the dough from licensing fees!

    Every freelance graphic designer who has up until now had to surrender a big chunk of their living space to a hulking 19" or 21" CRT (because of finances or because of LCD color issues) will be flinging wads of money at the makers of slim CRT monitors. Not to mention the regular joes who just want a 17" or 18" LCD, but can't justify spending ~$1000 on a display.

    Hell, I'd pony up for two of the things, just to replace what I have now and get my desk to stop bowing in the middle from the weight of my old-school 17" and 14".

    ~Philly
  • Re:GCC vs. Intel (Score:5, Interesting)

    by wfmcwalter ( 124904 ) on Thursday August 23, 2001 @10:38PM (#2211865) Homepage
    >Would you be surprised if Intels compiler >produced faster code than GCC?

    Not really. As the GCC folks readily admit, GCC is presently suboptimal at generating code for highly superscalar instruction sets. This isn't too much of a problem for P1->P4 (but gets progressivly stickier) which aren't very rich in that regard, but it gets to be a significant issue for LIW and VLIW architectures (including IA64).

    This isn't a bad reflection on GCC or its developers, however - writing such a compiler (in particular, an instruction scheduler that keeps the various pipelines efficiently filled) is very hard, and this hitherto hasn't been an issue for the mainstream architectures at which GCC is targeted.

    I remember reading somewhere that Philips spent more writing the compiler for its TriMedia VLIW chip (which is 5x5, as I recall) than they did actually designing the chip itself.

  • by edhall ( 10025 ) <slashdot@weirdnoise.com> on Friday August 24, 2001 @12:17AM (#2212105) Homepage
    Because the output amplifiers are neither fully on nor fully off, they're running in linear mode.

    This isn't true, at least for horizontal deflection (which requires the most energy). The output amplifier is basically running in switching mode; the sawtooth is generated by the energy stored in and released from the yoke's inductance. The dI/dt energy released can be stored elsewhere for the next cycle (in another inductor or in a capacitor) or just dissipated -- but not in the amplifier.

    You're absolutely correct that wider defection angles require more drive energy (for a given beam energy). Unless they've found a way to do more deflection before the beam is fully accelerated (which would reduce deflection energy requirements while making focusing more difficult), these units are going to suck massive amounts of power.

    -Ed
  • Re:Bloated Compiler? (Score:2, Interesting)

    by kurowski ( 11243 ) on Friday August 24, 2001 @12:29AM (#2212132) Homepage
    I'm not exactly sure what
    compiler bloat is supposed to mean since what matters is the assemby the compiler generates
    Yeah, just like I don't know what word processor bloat is since what matters is what the document looks like [Word]. Or what's text editor bloat since what matters is the text generated [Emacs] (/me ducks). And what is language bloat [C++] since what matters is the implementation of the compiler? [g++] Oh hey, no wonder they've had such a hard time producing a good compiler... wonder if it's bloated like some of the languages it compiles?

    Point is, I'm betting that a compiler written for a specific chip and specific language (i.e. Intel's compiler) will perform better (i.e. produce better code) than a "compiler collection" wuth multiple pluggable front- and back-ends, all other things being equal. (Not that all other things necessarily are equal in this case (Go GNU!).)

    P.S. I don't think your trolling will help to improve the quality of the posts on Slashdot.

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (5) All right, who's the wiseguy who stuck this trigraph stuff in here?

Working...