Slashdot Mirror


Linux On Alpha To Power Streaming Media Boxes

This CNET article, found at the new and itchin'-for-eyeballs AlphaNews site run by the AlphaLinux folks, says that Alpha Processor International (API) will be producing specialty boxes delivering streaming audio and video starting this Fall. "Alpha Processor's new machine will consist of a collection of smaller, two-processor Alpha computers, each running its own copy of Linux but the whole system acting essentially as a single large server," says the article, pointing out too that there already are Alpha-based dedicated streaming boxes from Network Appliances. Anything that increases Alpha production seems good to me, if it drives down the price of being 64-bit. Wonder what distro all those CPUs will be running ...

9 of 34 comments (clear)

  1. Re:Filesystems & number crunching by LinuxGeek · · Score: 3

    Surprise, surprise! Linux also has support for 64-bit file offsets. You failed to quote this comment I made though: "I know that there are ways around this with some filesystems, but there is a speed penalty when you get away from native cpu data sizes for variables."

    I have indeed run into this speed difference myself when I wrote some code recently to assist data recovery on large (20gig+) hard drives. I ended up with a much simpler (and faster) program by doing my own buffering and using only relative 32-bit lseeks and blockreads instead of the llseek 64bit offset functions. Since I wasn't trying to read a filesystem, but instead, rebuild data chains and recover information, 32bit-ness wasn't a problem aside from speed ( this process did involve *much* seeking. Granted, I didn't use FreeBSD, which may not have had a speed penalty ( and my speed differences could have been entirely caused by my crappy code ;o} ). Bottom line here is that for *my* application, 64bit-ness would have helped quite a bit in terms of getting the program written quickly and simply.

    BTW, Linux 2.2.xx supports 64bit llseek, but has a 32bit vfs. The 2.3.99 series and more importantly the 2.4 release series has a 64bit llseek and 64bit vfs. Go here for a small, current discussion thread

    --

    Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
  2. Re:which distro by Skapare · · Score: 2

    Hopefully Slackware will make it there, soon.

    --
    now we need to go OSS in diesel cars
  3. Filesystems & number crunching by LinuxGeek · · Score: 3

    With 32bit registers, a signed long is what limits file sizes to 2gigs. This is getting to be a bit of a limit for many applications (some of my custom apps and datafiles anyway). I know that there are ways around this with some filesystems, but there is a speed penalty when you get away from native cpu data sizes for variables. That is why a long on i386 is 32bit, and 64bit on 64bit cpus.

    Data can also be handled quite nicely in a 64bit register and the Alpha architecture has many registers for the compilers and programmers to play within which decreases the need for more memory bandwidth by just a bit. I'm still hoping for more mainstream pricing for the Alpha family processors and motherboards.

    --

    Kindness is the language which the deaf can hear and the blind can see. - Mark Twain
    1. Re:Filesystems & number crunching by Guy+Harris · · Score: 2
      Linux also has support for 64-bit file offsets.

      (Presumably meaning "support for 64-bit file offsets on 32-bit platforms.) And so do the other BSDs, Solaris 2.6 and later, and, I think, Windows NT, and probably other OSes.

      I ended up with a much simpler (and faster) program by doing my own buffering and using only relative 32-bit lseeks and blockreads instead of the llseek 64bit offset functions.

      How much of the "and faster" was due to "doing [your] own buffering" rather than "using only relative 32-bit lseeks"? Many file systems probably turn 64-bit file offsets into 32-bit block numbers and 32-bit offsets within blocks fairly early in the process of doing an I/O operation.

    2. Re:Filesystems & number crunching by Anonymous Coward · · Score: 2


      With 32bit registers, a signed long is what limits file sizes to 2gigs


      Nonsene. FreeBSD has had 64bit file offsets for years.


      there is a speed penalty when you get away from native cpu data sizes for variables.


      Is extfs so blisteringly fast that arithmetic operations get in its way?

  4. Re:Why does 64bit matter? by X · · Score: 3

    64-bits is not just about addressing memory.

    64-bit matters if you want to do integer arithmetic with large numbers. For example, factoring large numbers with a 64-bit processor can be 4x as fast as with a 32-bit processor. Additionally, the Alpha and various other ISA's have very cool support for manipulating each of the bytes in a 64-bit register independantly. This is of course 2x as fast as doing it with a 32-bit register. ;-)

    A good chunk of what Intel did with MMX was to allow for faster operations on 64-bit integer values. While that didn't make MS Word go faster you will recal various multi-media routines (like Photoshop filters) got a pretty big benefit from it.

    --
    sigs are a waste of space
  5. Why does 64bit matter? by abulafia · · Score: 2

    What's the big deal?

    Very few machines actually push the 32bit limits. I have ~20 boxes from Sun running Solaris 2.7 that are running in 32bit mode for one reason or another.

    I understand the push to move infrastructure forward; the day will soon come where 256G RAM makes sense. For something, I can't guess what at the moment, but it will.

    I see no speed benefit that the low (less than 1G RAM) end of things. What's the point right, from a business standpoint, right now?

    -j

    --
    I forget what 8 was for.
  6. Incorrect URL by orpheus · · Score: 2

    If you want to see Alphanews click the link.

    No wonder its itching for eyeballs. Their site is not available at http://www.alphanews.net as the Slashdot article stated. I presume that they advertise that URL, but their second level domain nameserver doesn't seem to resolve it yet. But a simple http://alphanews.net works just fine.

    -----------------
    Jes' doin' what I can to encourage people to read the links before commenting on them...
    _____________

    --

    If you can go to bed, knowing you did a valuable thing today, you're very lucky. If you can't... it's not bedtime

    1. Re:Incorrect URL by vectro · · Score: 2

      The really interesting thing is that www.alphanews.net is a different page than alphanews.net!