«
»

Google Chrome bug #9007, should we care?


Much dis­cus­sion spawned from Google Chrome bug #9007. The prob­lem is actu­allty quite sim­ple: Chrome depends on SSE2 instruc­tions and so, when run on proces­sors which do not sup­port such exten­sion, will crash cry­ing ‘Ille­gal instruc­tion’ . This arcane look­ing mes­sage sim­ply means: “Come on my friend, go buy a new computer.”

To under­stand my opin­ion, let me talk a bit about the SSE fam­ily of extensions.

MMX/SSE intro­duced in main­stream com­put­ing the SIMD com­pu­ta­tional model. SIMD means ‘Sin­gle Instruc­tion Mul­ti­ple Data’, so for each instruc­tion the same com­pu­ta­tion is exe­cuted over sev­eral indipen­dent data. This kind of instruc­tions are extremely use­ful in  math­e­mat­ics and mul­ti­me­dia appli­ca­tions. I don’t think SSE can be right­fully called an exten­sion. It’s actu­ally a nec­es­sary fea­ture which was miss­ing in the early Intel desings. SSE2 was intro­duced back in 2001. And it’s cur­rently sup­ported on every mod­ern proces­sor, from Atoms to bleed­ing edge quad core Xeons. Keep in mind that by using SIMD instruc­tions it is pos­si­ble to speedup the code by a fac­tor of 4 or 8. And this could make the dif­fer­ence between a real­time and an offline application.

I really think there is no rea­son for Google devel­op­ers to waste time and resource to sup­port obso­les­cent machines. Good code should be eff­i­cent in terms of proces­sor time, power con­sump­tion and mem­ory allo­ca­tion. To obtain such goals it is often nec­es­sary to exploit new features.

This con­sid­er­a­tion is also the foun­da­tion of the lightspark project design. I’m mak­ing use of every fea­ture a mod­ern plat­form offers, such as heavy mul­ti­thread­ing sup­port, mul­ti­le­dia exten­sions and pro­gram­ma­ble graphic cards. All of this to obtain a soft­ware which is fast and lean on resources, even on lim­ited plat­form such as Mobile Inter­net Deviced and sub-notebooks.

, , , ,

This entry was posted on May 29, 2009, 3:05 pm and is filed under Bar discussions. You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.

  • Roflor

    There are more proces­sor brands in the world, not just Intel.

    The main issue with this SSE2 depen­dency is with AMD Athlon/XP/MP, which has been pro­duced until 2005 and doesn’t sup­port SSE2, so not so obso­les­cent hard­ware is affected too.

    In addi­tion, depend­ing on SSE2 makes it impos­si­ble to port to other archi­tec­tures (Android on ARM, for a bleed­ing exam­ple). By the way you talk, obso­les­cent equals non-x86.

    What I still don’t under­stand is why would a web broser would need 128bit inte­ger reg­is­ters or any kind of heavy vec­to­r­ial float­ing point oper­a­tions, nor why hard­code them in assem­bly. Webkit itself, which would be the one more CPU demand­ing in these aspects DOES NOT depend on SSE2, but sur­pris­ingly the rest of Chrome, which is not much more than a GUI around Webkit, does. Mul­ti­me­dia appli­ca­tions? It’s Flash, or what­ever codecs or plu­g­ins used the ones doing the num­ber crunch­ing, not Chrome.

    The depen­dency lacks jus­ti­fi­ca­tion. Depend­ing on SSE2 is plain nonsensical.

    Another issue is that using x86 exten­sions with­out test­ing their pres­ence first is against the x86 spec­i­fi­ca­tion (so the pro­gram warns the require­ment instead of crashing).

  • Roflor

    There are more proces­sor brands in the world, not just Intel.

    The main issue with this SSE2 depen­dency is with AMD Athlon/XP/MP, which has been pro­duced until 2005 and doesn’t sup­port SSE2, so not so obso­les­cent hard­ware is affected too.

    In addi­tion, depend­ing on SSE2 makes it impos­si­ble to port to other archi­tec­tures (Android on ARM, for a bleed­ing exam­ple). By the way you talk, obso­les­cent equals non-x86.

    What I still don’t under­stand is why would a web broser would need 128bit inte­ger reg­is­ters or any kind of heavy vec­to­r­ial float­ing point oper­a­tions, nor why hard­code them in assem­bly. Webkit itself, which would be the one more CPU demand­ing in these aspects DOES NOT depend on SSE2, but sur­pris­ingly the rest of Chrome, which is not much more than a GUI around Webkit, does. Mul­ti­me­dia appli­ca­tions? It’s Flash, or what­ever codecs or plu­g­ins used the ones doing the num­ber crunch­ing, not Chrome.

    The depen­dency lacks jus­ti­fi­ca­tion. Depend­ing on SSE2 is plain nonsensical.

    Another issue is that using x86 exten­sions with­out test­ing their pres­ence first is against the x86 spec­i­fi­ca­tion (so the pro­gram warns the require­ment instead of crashing).

  • Alessan­dro

    Hi Roflor,

    I was not aware that recent units from AMD missed such a crit­i­cal fea­ture, but I guess that any­way being pro­duced 4 years ago those are grad­u­ally fad­ing away. But I have worked with VIA proces­sor and I can say that I could have really used SSE2 sup­port. This par­tic­u­lar exten­sion is not only use­ful for num­ber crunch­ing, but also for cache opti­miza­tion and mem­ory pre­load­ing. I can also agree that crash­ing against the user with­out check­ing for exten­sion pres­ence is not very polite.

    But any­way my point was not about the spe­cific case, I was just irri­tated by the angry response to such an issue. It seems rea­son­able to me to exploit as much as pos­si­ble the pow­er­ful fea­tures offered by mod­ern platforms.

    Regards,
    Alessandro

  • Alessan­dro

    Hi Roflor,

    I was not aware that recent units from AMD missed such a crit­i­cal fea­ture, but I guess that any­way being pro­duced 4 years ago those are grad­u­ally fad­ing away. But I have worked with VIA proces­sor and I can say that I could have really used SSE2 sup­port. This par­tic­u­lar exten­sion is not only use­ful for num­ber crunch­ing, but also for cache opti­miza­tion and mem­ory pre­load­ing. I can also agree that crash­ing against the user with­out check­ing for exten­sion pres­ence is not very polite.

    But any­way my point was not about the spe­cific case, I was just irri­tated by the angry response to such an issue. It seems rea­son­able to me to exploit as much as pos­si­ble the pow­er­ful fea­tures offered by mod­ern platforms.

    Regards,
    Alessandro

  • Yuhong Bao

    @Roflor
    Indeed, the only rea­son Chrome was com­piled with SSE2 instruc­tions was that a unit test was fail­ing due to a dif­fer­ence between x87 and SSE2 reg­is­ters. Let me explain. x87 uses a stack of 8 80-bit reg­is­ters. When the pro­gram push a floating-point num­ber onto the stack, it is always con­verted to 80-bit pre­ci­sion. Then other oper­a­tions that manip­u­late the num­bers on the stack are always based on that pre­ci­sion. Finally, when the num­ber is popped from the stack, it is always con­verted back. SSE2 do not work that way, though. It has a flat reg­is­ter file of 8 128-bit reg­is­ters in 16/32-bit modes or 16 of them in 64-bit mode. When a pro­gram loads a num­ber into one of these reg­is­ters, it is not con­verted and oper­a­tions on them always uses the pre­ci­sion that is stored into the reg­is­ters. As a result, the result is slightly dif­fer­ent, caus­ing the unit test to fail.

  • Yuhong Bao

    @Roflor
    Indeed, the only rea­son Chrome was com­piled with SSE2 instruc­tions was that a unit test was fail­ing due to a dif­fer­ence between x87 and SSE2 reg­is­ters. Let me explain. x87 uses a stack of 8 80-bit reg­is­ters. When the pro­gram push a floating-point num­ber onto the stack, it is always con­verted to 80-bit pre­ci­sion. Then other oper­a­tions that manip­u­late the num­bers on the stack are always based on that pre­ci­sion. Finally, when the num­ber is popped from the stack, it is always con­verted back. SSE2 do not work that way, though. It has a flat reg­is­ter file of 8 128-bit reg­is­ters in 16/32-bit modes or 16 of them in 64-bit mode. When a pro­gram loads a num­ber into one of these reg­is­ters, it is not con­verted and oper­a­tions on them always uses the pre­ci­sion that is stored into the reg­is­ters. As a result, the result is slightly dif­fer­ent, caus­ing the unit test to fail.

«
»

Google Chrome bug #9007, should we care?


Much dis­cus­sion spawned from Google Chrome bug #9007. The prob­lem is actu­allty quite sim­ple: Chrome depends on SSE2 instruc­tions and so, when run on proces­sors which do not sup­port such exten­sion, will crash cry­ing ‘Ille­gal instruc­tion’ . This arcane look­ing mes­sage sim­ply means: “Come on my friend, go buy a new computer.”

To under­stand my opin­ion, let me talk a bit about the SSE fam­ily of extensions.

MMX/SSE intro­duced in main­stream com­put­ing the SIMD com­pu­ta­tional model. SIMD means ‘Sin­gle Instruc­tion Mul­ti­ple Data’, so for each instruc­tion the same com­pu­ta­tion is exe­cuted over sev­eral indipen­dent data. This kind of instruc­tions are extremely use­ful in  math­e­mat­ics and mul­ti­me­dia appli­ca­tions. I don’t think SSE can be right­fully called an exten­sion. It’s actu­ally a nec­es­sary fea­ture which was miss­ing in the early Intel desings. SSE2 was intro­duced back in 2001. And it’s cur­rently sup­ported on every mod­ern proces­sor, from Atoms to bleed­ing edge quad core Xeons. Keep in mind that by using SIMD instruc­tions it is pos­si­ble to speedup the code by a fac­tor of 4 or 8. And this could make the dif­fer­ence between a real­time and an offline application.

I really think there is no rea­son for Google devel­op­ers to waste time and resource to sup­port obso­les­cent machines. Good code should be eff­i­cent in terms of proces­sor time, power con­sump­tion and mem­ory allo­ca­tion. To obtain such goals it is often nec­es­sary to exploit new features.

This con­sid­er­a­tion is also the foun­da­tion of the lightspark project design. I’m mak­ing use of every fea­ture a mod­ern plat­form offers, such as heavy mul­ti­thread­ing sup­port, mul­ti­le­dia exten­sions and pro­gram­ma­ble graphic cards. All of this to obtain a soft­ware which is fast and lean on resources, even on lim­ited plat­form such as Mobile Inter­net Deviced and sub-notebooks.

, , , ,

This entry was posted on May 29, 2009, 3:05 pm and is filed under Bar discussions. You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.