altivec browser

pbpb
Posted:
in Mac Software edited January 2014
So this is my question: is it possible to design a web browser that would make use of the altivec unit of a G4? And the benefits from an altivec optimized browser would be enough to justify its development? I hope my question makes sense.



Thanks,

PB

Comments

  • Reply 1 of 11
    No.
  • Reply 2 of 11
    wfzellewfzelle Posts: 137member
    [quote]Originally posted by PB:

    <strong>So this is my question: is it possible to design a web browser that would make use of the altivec unit of a G4? And the benefits from an altivec optimized browser would be enough to justify its development? I hope my question makes sense.</strong><hr></blockquote>



    I guess that the Intel commercials got to you. "SSE makes the Internet go faster". In reality, Altivec (and SSE) will speed up mass computations. Using Photoshop plugins on images, compressing video, etc. When browsing the processor is usually waiting for the modem/ADSL/cabel to send data. When it gets the data it has to parse and display it, which cannot be enhanced much with Altivec since the processor has to do different things all the time:



    Processor during browsing:

    - Wait for data

    - Set title

    - draw line

    - draw some text

    - draw a picture

    ...etc



    Processor during a Photoshop plugin:

    - Change the color in pixel 1-32

    - Change the color in pixel 33-64

    - Change the color in pixel 65-96

    - Change the color in pixel 96-128

    ...etc



    Altivec can do the four plugin operations in one go because the operation is the same and there are no dependencies. That's the 'only' thing that Altivec is good for.
  • Reply 3 of 11
    serranoserrano Posts: 1,806member
    lol this is like the chimera thread over on ars
  • Reply 4 of 11
    pbpb Posts: 4,255member
    [quote]Originally posted by wfzelle:

    <strong>

    I guess that the Intel commercials got to you. "SSE makes the Internet go faster".</strong><hr></blockquote>



    I were not aware of that commercial.



    [quote]<strong>

    Altivec can do the four plugin operations in one go because the operation is the same and there are no dependencies. That's the 'only' thing that Altivec is good for.</strong><hr></blockquote>



    If I understand well, the problem is that the processor has to handle "chain-dependent events" during web browsing (that do not occur simultaneously and are of different nature). So no much room for altivec. But again, the drawing (line, text, picture etc.) step could not be altivec accelerated? Or the gains are not worth the effort?



    [ 11-07-2002: Message edited by: PB ]</p>
  • Reply 5 of 11
    relicrelic Posts: 4,735member
    However a Altivec aware browser would make the menu faster and resizing the window a bit smoother.
  • Reply 6 of 11
    [quote]Originally posted by PB:

    <strong>I were not aware of that commercial.</strong><hr></blockquote>



    It was a while ago already, but it was exactly of the type I mentioned. Get this Pentium MMX and the Internet will be faster. Of course, today we call MMX by the name SSE.



    [quote]<strong>If I understand well, the problem is that the processor has to handle "chain-dependent events" during web browsing (that do not occur simultaneously and are of different nature). So no much room for altivec. But again, the drawing (line, text, picture etc.) step could not be altivec accelerated? Or the gains are not worth the effort?</strong><hr></blockquote>



    Exactly, there could be some acceleration in drawing, although that would be in the Quartz layer. The browser just says to Quartz: "Draw this line from x to y" or "Draw this text in font Y" (this also explains why you can change anti-aliasing globally). If there is potential in Quartz for Altivec, I'm sure it's already taken advantage of. All in all, I cannot see big improvements in the browser arena coming from Altivec.



    [ 11-08-2002: Message edited by: wfzelle ]</p>
  • Reply 7 of 11
    scottscott Posts: 7,431member
    There is some stuff that can use it in browsing. For example I think most pages are compressed and then sent. I don't know enough about http to know if that's something that needs to be coded up or maybe it's in the system already?
  • Reply 8 of 11
    [quote]Originally posted by Scott:

    <strong>There is some stuff that can use it in browsing. For example I think most pages are compressed and then sent. I don't know enough about http to know if that's something that needs to be coded up or maybe it's in the system already?</strong><hr></blockquote>



    HTTP 1.1 supports on the fly compression of HTML, but no browser is fully HTTP 1.1 compliant. IE 5 doesn't decompress the pages properly for instance. There is some effort to compress the pages only when the browser supports it, but I don't know how fool-proof that is. AFAIK very few sites use this technology, it's still far too error-prone.



    Furthermore, it doesn't really matter much because no one is going to write custom decompression code just for a browser. They just use a generic library. That library is probably based on common sourcecode as to prevent incompatibilities and is already heavily optimized as is. It requires a substantial investment to create and maintain an Altivec enhanced compression library. I don't see anyone making that effort.



    Finally, compressed HTML boosts your browsing a lot because decompressing HTML is going to be far, far faster than downloading an uncompressed page which is 10x bigger. The cost of decompressing that page is fairly small on a half-decent computer. Speeding up something that is already quite fast isn't the best way to improve performance.
  • Reply 9 of 11
    dfilerdfiler Posts: 3,420member
    [quote]Originally posted by wfzelle:

    <strong>Finally, compressed HTML boosts your browsing a lot because decompressing HTML is going to be far, far faster than downloading an uncompressed page which is 10x bigger. The cost of decompressing that page is fairly small on a half-decent computer. Speeding up something that is already quite fast isn't the best way to improve performance.</strong><hr></blockquote>



    I would assert the exact opposite. Compressed html offers nearly no speed improvement. html code itself is incredibly small. Its the images on web pages which comprise the bulk of a page's size. These are already compressed via popular standards like jpeg, gif, and png.



    More aggressive image compression algorithms are available but haven't caught on yet. They trade CPU time for decreased file size. There is far more potential in increased image compression than there is in html code compression.



    The good news is that some image decompression algorithms can be greatly accelerated by parallel processing units like altivec. I'm not familiar with the jpg and gif compression shemes. Does anyone know if they are suitable for altivec acceleration?



    One browser function that could definately bennefit from altivec acceleration would be live image resizing. While current browsers only offer user scalable text, images could also be scaled. Resolution independent rendering is coming, but the transition will be quite messy. Myself? I can't wait until the day that web pages can be scaled perfectly without messing up text-flow and page-element alignment!
  • Reply 10 of 11
    wmfwmf Posts: 1,164member
    Some sites have a lot of "fat" in their HTML, so they benefit from compression. I know a guy who did the compression code for a Web caching product, and they were getting better performance from it.



    AltiVec can definitely be used for JPEG.
  • Reply 11 of 11
    arnarn Posts: 21member
    [quote]Originally posted by dfiler:

    <strong>



    I would assert the exact opposite. Compressed html offers nearly no speed improvement. html code itself is incredibly small. </strong><hr></blockquote>



    Let me clear the air here...



    Most modern browsers support compressed HTML (gzip'd). Information is compressed on the fly on the server side and sent to client's browsers only if the browser supports it. If the browser doesn't support it, raw HTML is sent.



    Benefit from this can be about 30-40% decrease in overall bandwidth.



    Many sites you visit already gzip their content... it's 100% transparent to the end user.



    Let's look at MacNN's main page. Is it <a href="http://leknor.com/code/gziped.php?url=http://www.macnn.com&quot; target="_blank">gziped?</a>



    No it's not. It's 62k in raw HTML. It would only be 16k if it were gziped. MacNN would save 46k per visitor if they were to turn it on. It does cost you a bit more processing though on the server side.



    GZiping your content can make things faster for viewers of your website - especially dialup users. They only have to download 16k instead of 62k in this example. Decompression is pretty quick on modern machines.



    Gziped sites:



    <a href="http://www.macrumors.com"; target="_blank">http://www.macrumors.com</a>;

    <a href="http://www.slashdot.org"; target="_blank">http://www.slashdot.org</a>;



    arn



    [ 11-13-2002: Message edited by: arn ]</p>
Sign In or Register to comment.