I can't find in the documentation which ARM architecture types V8
supports. Does it support older ARM9 devices (I'm specifically
interested in an ARMv5te architecture, ARM926ej-s device) or only
newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) build
on ARMv5te, but do all the JIT features work or is it running in a
byte code interpreter fallback or something? Can I expect good
performance?
There is no interpreter in V8 so you will be using the JIT every time, perfromance should be good (keep in mind CPU like 926-ej-s do not have L2 cache and this is going to have a visible impact). There is a new JIT infrastructure being developed (crankshaft) which features an optimising JIT and this will only be for ARMv7+VFP devices.
HTH, Rodolph.
On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> wrote:
> I can't find in the documentation which ARM architecture types V8 > supports. Does it support older ARM9 devices (I'm specifically > interested in an ARMv5te architecture, ARM926ej-s device) or only > newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) build > on ARMv5te, but do all the JIT features work or is it running in a > byte code interpreter fallback or something? Can I expect good > performance?
Just a follow-up note regarding the new optimizing compiler (crankshaft). This will be enabled by default for ARM quite soon, and the existing optimizing compiler will be removed at some point. For non ARMv7+VFP devices this means that the base JIT (non-optimizing/full-compiler) will be used. To measure the different compilers on a ARMv7+VFP device use following options:
--nocrankshaft (current optimizing JIT - the current default) --crankshaft (new optimizing JIT - the soon to be default) --always-full-compiler (base/non-optimizing compiler)
Going forward using --crankshaft on a non ARMv7+VFP device will have no effect and execution will fallback to --always-full-compiler.
Regards, Søren
On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta <rodolph.perfe...@gmail.com>wrote:
> There is no interpreter in V8 so you will be using the JIT every time, > perfromance should be good (keep in mind CPU like 926-ej-s do not have L2 > cache and this is going to have a visible impact). There is a new JIT > infrastructure being developed (crankshaft) which features an optimising JIT > and this will only be for ARMv7+VFP devices.
> HTH, > Rodolph.
> On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> wrote:
>> Hi,
>> I can't find in the documentation which ARM architecture types V8 >> supports. Does it support older ARM9 devices (I'm specifically >> interested in an ARMv5te architecture, ARM926ej-s device) or only >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) build >> on ARMv5te, but do all the JIT features work or is it running in a >> byte code interpreter fallback or something? Can I expect good >> performance?
How much slower is full-compiler than nocrankshaft on ARM926ej-s -
anyone have any benchmarks? I'm hesitant to invest time in using V8
for my project if it's going to get substantially slower soon. Is
there any estimated time frame for when nocrankshaft will be
deprecated?
Thanks,
Hugo
On Feb 23, 9:14 pm, Søren Gjesse <sgje...@chromium.org> wrote:
> Just a follow-up note regarding the new optimizing compiler (crankshaft).
> This will be enabled by default for ARM quite soon, and the existing
> optimizing compiler will be removed at some point. For non ARMv7+VFP devices
> this means that the base JIT (non-optimizing/full-compiler) will be used. To
> measure the different compilers on a ARMv7+VFP device use following options:
> --nocrankshaft (current optimizing JIT - the current default)
> --crankshaft (new optimizing JIT - the soon to be default)
> --always-full-compiler (base/non-optimizing compiler)
> Going forward using --crankshaft on a non ARMv7+VFP device will have no
> effect and execution will fallback to --always-full-compiler.
> Regards,
> Søren
> On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta
> <rodolph.perfe...@gmail.com>wrote:
> > V8 can run on ARMv4 devices (non T though).
> > There is no interpreter in V8 so you will be using the JIT every time,
> > perfromance should be good (keep in mind CPU like 926-ej-s do not have L2
> > cache and this is going to have a visible impact). There is a new JIT
> > infrastructure being developed (crankshaft) which features an optimising JIT
> > and this will only be for ARMv7+VFP devices.
> > HTH,
> > Rodolph.
> > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> wrote:
> >> Hi,
> >> I can't find in the documentation which ARM architecture types V8
> >> supports. Does it support older ARM9 devices (I'm specifically
> >> interested in an ARMv5te architecture, ARM926ej-s device) or only
> >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) build
> >> on ARMv5te, but do all the JIT features work or is it running in a
> >> byte code interpreter fallback or something? Can I expect good
> >> performance?
For ARM crankshaft is now the default. This change is in the repository starting from V8 version 3.2. To use the previous optimizing compiler --nocrankshaft will have to be used. When crankshaft for ARM has been fully stabilized the previous optimizing compiler will be removed from the repository and running with --nocrankshaft will no longer be possible. There is no specific date to when this will happen but most likely it will be within a month or two. The removal of the previous optimizing compiler will happen for all supported platforms simultaneously,
The previous optimizing compiler can of cause still be found in previous versions of V8.
On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> wrote: > How much slower is full-compiler than nocrankshaft on ARM926ej-s - > anyone have any benchmarks? I'm hesitant to invest time in using V8 > for my project if it's going to get substantially slower soon. Is > there any estimated time frame for when nocrankshaft will be > deprecated?
> Thanks, > Hugo
> On Feb 23, 9:14 pm, Søren Gjesse <sgje...@chromium.org> wrote: > > Just a follow-up note regarding the new optimizing compiler (crankshaft). > > This will be enabled by default for ARM quite soon, and the existing > > optimizing compiler will be removed at some point. For non ARMv7+VFP > devices > > this means that the base JIT (non-optimizing/full-compiler) will be used. > To > > measure the different compilers on a ARMv7+VFP device use following > options:
> > --nocrankshaft (current optimizing JIT - the current default) > > --crankshaft (new optimizing JIT - the soon to be default) > > --always-full-compiler (base/non-optimizing compiler)
> > Going forward using --crankshaft on a non ARMv7+VFP device will have no > > effect and execution will fallback to --always-full-compiler.
> > Regards, > > Søren
> > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > <rodolph.perfe...@gmail.com>wrote:
> > > V8 can run on ARMv4 devices (non T though).
> > > There is no interpreter in V8 so you will be using the JIT every time, > > > perfromance should be good (keep in mind CPU like 926-ej-s do not have > L2 > > > cache and this is going to have a visible impact). There is a new JIT > > > infrastructure being developed (crankshaft) which features an > optimising JIT > > > and this will only be for ARMv7+VFP devices.
> > > HTH, > > > Rodolph.
> > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> > wrote:
> > >> Hi,
> > >> I can't find in the documentation which ARM architecture types V8 > > >> supports. Does it support older ARM9 devices (I'm specifically > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) build > > >> on ARMv5te, but do all the JIT features work or is it running in a > > >> byte code interpreter fallback or something? Can I expect good > > >> performance?
> For ARM crankshaft is now the default. This change is in the repository
> starting from V8 version 3.2. To use the previous optimizing compiler
> --nocrankshaft will have to be used. When crankshaft for ARM has been fully
> stabilized the previous optimizing compiler will be removed from the
> repository and running with --nocrankshaft will no longer be possible. There
> is no specific date to when this will happen but most likely it will be
> within a month or two. The removal of the previous optimizing compiler will
> happen for all supported platforms simultaneously,
> The previous optimizing compiler can of cause still be found in previous
> versions of V8.
> Regards,
> Søren
> On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> wrote:
> > How much slower is full-compiler than nocrankshaft on ARM926ej-s -
> > anyone have any benchmarks? I'm hesitant to invest time in using V8
> > for my project if it's going to get substantially slower soon. Is
> > there any estimated time frame for when nocrankshaft will be
> > deprecated?
> > Thanks,
> > Hugo
> > On Feb 23, 9:14 pm, Søren Gjesse <sgje...@chromium.org> wrote:
> > > Just a follow-up note regarding the new optimizing compiler (crankshaft).
> > > This will be enabled by default for ARM quite soon, and the existing
> > > optimizing compiler will be removed at some point. For non ARMv7+VFP
> > devices
> > > this means that the base JIT (non-optimizing/full-compiler) will be used.
> > To
> > > measure the different compilers on a ARMv7+VFP device use following
> > options:
> > > --nocrankshaft (current optimizing JIT - the current default)
> > > --crankshaft (new optimizing JIT - the soon to be default)
> > > --always-full-compiler (base/non-optimizing compiler)
> > > Going forward using --crankshaft on a non ARMv7+VFP device will have no
> > > effect and execution will fallback to --always-full-compiler.
> > > Regards,
> > > Søren
> > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta
> > > <rodolph.perfe...@gmail.com>wrote:
> > > > V8 can run on ARMv4 devices (non T though).
> > > > There is no interpreter in V8 so you will be using the JIT every time,
> > > > perfromance should be good (keep in mind CPU like 926-ej-s do not have
> > L2
> > > > cache and this is going to have a visible impact). There is a new JIT
> > > > infrastructure being developed (crankshaft) which features an
> > optimising JIT
> > > > and this will only be for ARMv7+VFP devices.
> > > > HTH,
> > > > Rodolph.
> > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com>
> > wrote:
> > > >> Hi,
> > > >> I can't find in the documentation which ARM architecture types V8
> > > >> supports. Does it support older ARM9 devices (I'm specifically
> > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only
> > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) build
> > > >> on ARMv5te, but do all the JIT features work or is it running in a
> > > >> byte code interpreter fallback or something? Can I expect good
> > > >> performance?
Crankshaft is now enabled by default on ARM processors supporting VFPv3. v8 does not use NEON (it is not worth using, at least currently), but I believe no processors with this configuration (NEON without VFPv3) exist anyway. So if the CPU feature detection work correctly, v8 should assume that you have VFPv3 if it detects NEON, and thus use use Crankshaft.
If I remember correctly there has been some issues with incorrect feature detection. A simple run of the v8 benchmarks with the latest bleeding_edge and the frequency of your CPU should be enough to determine if crankshaft is enabled.
On Sat, Apr 2, 2011 at 7:40 AM, Arun M <arunm.chr...@gmail.com> wrote:
> Hi
> Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices > which does not have VFPv3 FPU?
> Thanks & Regards > Arun
> On Mar 9, 6:02 pm, Søren Gjesse <sgje...@chromium.org> wrote: > > For ARM crankshaft is now the default. This change is in the repository > > starting from V8 version 3.2. To use the previous optimizing compiler > > --nocrankshaft will have to be used. When crankshaft for ARM has been > fully > > stabilized the previous optimizing compiler will be removed from the > > repository and running with --nocrankshaft will no longer be possible. > There > > is no specific date to when this will happen but most likely it will be > > within a month or two. The removal of the previous optimizing compiler > will > > happen for all supported platforms simultaneously,
> > The previous optimizing compiler can of cause still be found in previous > > versions of V8.
> > Regards, > > Søren
> > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> > wrote: > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s - > > > anyone have any benchmarks? I'm hesitant to invest time in using V8 > > > for my project if it's going to get substantially slower soon. Is > > > there any estimated time frame for when nocrankshaft will be > > > deprecated?
> > > Thanks, > > > Hugo
> > > On Feb 23, 9:14 pm, Søren Gjesse <sgje...@chromium.org> wrote: > > > > Just a follow-up note regarding the new optimizing compiler > (crankshaft). > > > > This will be enabled by default for ARM quite soon, and the existing > > > > optimizing compiler will be removed at some point. For non ARMv7+VFP > > > devices > > > > this means that the base JIT (non-optimizing/full-compiler) will be > used. > > > To > > > > measure the different compilers on a ARMv7+VFP device use following > > > options:
> > > > --nocrankshaft (current optimizing JIT - the current default) > > > > --crankshaft (new optimizing JIT - the soon to be default) > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > Going forward using --crankshaft on a non ARMv7+VFP device will have > no > > > > effect and execution will fallback to --always-full-compiler.
> > > > Regards, > > > > Søren
> > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > V8 can run on ARMv4 devices (non T though).
> > > > > There is no interpreter in V8 so you will be using the JIT every > time, > > > > > perfromance should be good (keep in mind CPU like 926-ej-s do not > have > > > L2 > > > > > cache and this is going to have a visible impact). There is a new > JIT > > > > > infrastructure being developed (crankshaft) which features an > > > optimising JIT > > > > > and this will only be for ARMv7+VFP devices.
> > > > > HTH, > > > > > Rodolph.
> > > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> > > > wrote:
> > > > >> Hi,
> > > > >> I can't find in the documentation which ARM architecture types V8 > > > > >> supports. Does it support older ARM9 devices (I'm specifically > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) > build > > > > >> on ARMv5te, but do all the JIT features work or is it running in a > > > > >> byte code interpreter fallback or something? Can I expect good > > > > >> performance?
On Sat, Apr 2, 2011 at 08:40, Arun M <arunm.chr...@gmail.com> wrote:
> Hi
> Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices > which does not have VFPv3 FPU?
> Thanks & Regards > Arun
> On Mar 9, 6:02 pm, Søren Gjesse <sgje...@chromium.org> wrote: > > For ARM crankshaft is now the default. This change is in the repository > > starting from V8 version 3.2. To use the previous optimizing compiler > > --nocrankshaft will have to be used. When crankshaft for ARM has been > fully > > stabilized the previous optimizing compiler will be removed from the > > repository and running with --nocrankshaft will no longer be possible. > There > > is no specific date to when this will happen but most likely it will be > > within a month or two. The removal of the previous optimizing compiler > will > > happen for all supported platforms simultaneously,
> > The previous optimizing compiler can of cause still be found in previous > > versions of V8.
> > Regards, > > Søren
> > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> > wrote: > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s - > > > anyone have any benchmarks? I'm hesitant to invest time in using V8 > > > for my project if it's going to get substantially slower soon. Is > > > there any estimated time frame for when nocrankshaft will be > > > deprecated?
> > > Thanks, > > > Hugo
> > > On Feb 23, 9:14 pm, Søren Gjesse <sgje...@chromium.org> wrote: > > > > Just a follow-up note regarding the new optimizing compiler > (crankshaft). > > > > This will be enabled by default for ARM quite soon, and the existing > > > > optimizing compiler will be removed at some point. For non ARMv7+VFP > > > devices > > > > this means that the base JIT (non-optimizing/full-compiler) will be > used. > > > To > > > > measure the different compilers on a ARMv7+VFP device use following > > > options:
> > > > --nocrankshaft (current optimizing JIT - the current default) > > > > --crankshaft (new optimizing JIT - the soon to be default) > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > Going forward using --crankshaft on a non ARMv7+VFP device will have > no > > > > effect and execution will fallback to --always-full-compiler.
> > > > Regards, > > > > Søren
> > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > V8 can run on ARMv4 devices (non T though).
> > > > > There is no interpreter in V8 so you will be using the JIT every > time, > > > > > perfromance should be good (keep in mind CPU like 926-ej-s do not > have > > > L2 > > > > > cache and this is going to have a visible impact). There is a new > JIT > > > > > infrastructure being developed (crankshaft) which features an > > > optimising JIT > > > > > and this will only be for ARMv7+VFP devices.
> > > > > HTH, > > > > > Rodolph.
> > > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> > > > wrote:
> > > > >> Hi,
> > > > >> I can't find in the documentation which ARM architecture types V8 > > > > >> supports. Does it support older ARM9 devices (I'm specifically > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) > build > > > > >> on ARMv5te, but do all the JIT features work or is it running in a > > > > >> byte code interpreter fallback or something? Can I expect good > > > > >> performance?
On Mon, Apr 04, 2011 at 09:45:52AM +0100, Alexandre Rames wrote: > Hello Arun,
> Crankshaft is now enabled by default on ARM processors supporting VFPv3. > v8 does not use NEON (it is not worth using, at least currently), but I > believe no processors with this configuration (NEON without VFPv3) exist > anyway. So if the CPU feature detection work correctly, v8 should assume > that you have VFPv3 if it detects NEON, and thus use use Crankshaft.
> If I remember correctly there has been some issues with incorrect feature > detection. A simple run of the v8 benchmarks with the latest bleeding_edge > and the frequency of your CPU should be enough to determine if crankshaft is > enabled.
The CPU features detection is done parsing the /proc/cpuinfo file:
> On Sat, Apr 2, 2011 at 7:40 AM, Arun M <arunm.chr...@gmail.com> wrote:
> > Hi
> > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices > > which does not have VFPv3 FPU?
> > Thanks & Regards > > Arun
> > On Mar 9, 6:02 pm, S ren Gjesse <sgje...@chromium.org> wrote: > > > For ARM crankshaft is now the default. This change is in the repository > > > starting from V8 version 3.2. To use the previous optimizing compiler > > > --nocrankshaft will have to be used. When crankshaft for ARM has been > > fully > > > stabilized the previous optimizing compiler will be removed from the > > > repository and running with --nocrankshaft will no longer be possible. > > There > > > is no specific date to when this will happen but most likely it will be > > > within a month or two. The removal of the previous optimizing compiler > > will > > > happen for all supported platforms simultaneously,
> > > The previous optimizing compiler can of cause still be found in previous > > > versions of V8.
> > > Regards, > > > S ren
> > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> > > wrote: > > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s - > > > > anyone have any benchmarks? I'm hesitant to invest time in using V8 > > > > for my project if it's going to get substantially slower soon. Is > > > > there any estimated time frame for when nocrankshaft will be > > > > deprecated?
> > > > Thanks, > > > > Hugo
> > > > On Feb 23, 9:14 pm, S ren Gjesse <sgje...@chromium.org> wrote: > > > > > Just a follow-up note regarding the new optimizing compiler > > (crankshaft). > > > > > This will be enabled by default for ARM quite soon, and the existing > > > > > optimizing compiler will be removed at some point. For non ARMv7+VFP > > > > devices > > > > > this means that the base JIT (non-optimizing/full-compiler) will be > > used. > > > > To > > > > > measure the different compilers on a ARMv7+VFP device use following > > > > options:
> > > > > --nocrankshaft (current optimizing JIT - the current default) > > > > > --crankshaft (new optimizing JIT - the soon to be default) > > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > > Going forward using --crankshaft on a non ARMv7+VFP device will have > > no > > > > > effect and execution will fallback to --always-full-compiler.
> > > > > Regards, > > > > > S ren
> > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > There is no interpreter in V8 so you will be using the JIT every > > time, > > > > > > perfromance should be good (keep in mind CPU like 926-ej-s do not > > have > > > > L2 > > > > > > cache and this is going to have a visible impact). There is a new > > JIT > > > > > > infrastructure being developed (crankshaft) which features an > > > > optimising JIT > > > > > > and this will only be for ARMv7+VFP devices.
> > > > > > HTH, > > > > > > Rodolph.
> > > > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> > > > > wrote:
> > > > > >> Hi,
> > > > > >> I can't find in the documentation which ARM architecture types V8 > > > > > >> supports. Does it support older ARM9 devices (I'm specifically > > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only > > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) > > build > > > > > >> on ARMv5te, but do all the JIT features work or is it running in a > > > > > >> byte code interpreter fallback or something? Can I expect good > > > > > >> performance?
On Mon, Apr 04, 2011 at 10:46:29AM +0200, S ren Gjesse wrote: > The Crankshaft optimizing compiler requires VFPv3. Without VFPv3 the > non-optimizing will be used for all code. V8 cannot make use of NEON.
Why v8 cannot make use of NEON? Because of an specific reason?
> On Sat, Apr 2, 2011 at 08:40, Arun M <arunm.chr...@gmail.com> wrote:
> > Hi
> > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices > > which does not have VFPv3 FPU?
> > Thanks & Regards > > Arun
> > On Mar 9, 6:02 pm, S ren Gjesse <sgje...@chromium.org> wrote: > > > For ARM crankshaft is now the default. This change is in the repository > > > starting from V8 version 3.2. To use the previous optimizing compiler > > > --nocrankshaft will have to be used. When crankshaft for ARM has been > > fully > > > stabilized the previous optimizing compiler will be removed from the > > > repository and running with --nocrankshaft will no longer be possible. > > There > > > is no specific date to when this will happen but most likely it will be > > > within a month or two. The removal of the previous optimizing compiler > > will > > > happen for all supported platforms simultaneously,
> > > The previous optimizing compiler can of cause still be found in previous > > > versions of V8.
> > > Regards, > > > S ren
> > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> > > wrote: > > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s - > > > > anyone have any benchmarks? I'm hesitant to invest time in using V8 > > > > for my project if it's going to get substantially slower soon. Is > > > > there any estimated time frame for when nocrankshaft will be > > > > deprecated?
> > > > Thanks, > > > > Hugo
> > > > On Feb 23, 9:14 pm, S ren Gjesse <sgje...@chromium.org> wrote: > > > > > Just a follow-up note regarding the new optimizing compiler > > (crankshaft). > > > > > This will be enabled by default for ARM quite soon, and the existing > > > > > optimizing compiler will be removed at some point. For non ARMv7+VFP > > > > devices > > > > > this means that the base JIT (non-optimizing/full-compiler) will be > > used. > > > > To > > > > > measure the different compilers on a ARMv7+VFP device use following > > > > options:
> > > > > --nocrankshaft (current optimizing JIT - the current default) > > > > > --crankshaft (new optimizing JIT - the soon to be default) > > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > > Going forward using --crankshaft on a non ARMv7+VFP device will have > > no > > > > > effect and execution will fallback to --always-full-compiler.
> > > > > Regards, > > > > > S ren
> > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > There is no interpreter in V8 so you will be using the JIT every > > time, > > > > > > perfromance should be good (keep in mind CPU like 926-ej-s do not > > have > > > > L2 > > > > > > cache and this is going to have a visible impact). There is a new > > JIT > > > > > > infrastructure being developed (crankshaft) which features an > > > > optimising JIT > > > > > > and this will only be for ARMv7+VFP devices.
> > > > > > HTH, > > > > > > Rodolph.
> > > > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> > > > > wrote:
> > > > > >> Hi,
> > > > > >> I can't find in the documentation which ARM architecture types V8 > > > > > >> supports. Does it support older ARM9 devices (I'm specifically > > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only > > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) > > build > > > > > >> on ARMv5te, but do all the JIT features work or is it running in a > > > > > >> byte code interpreter fallback or something? Can I expect good > > > > > >> performance?
we have not found any of the NEON instructions useful to speed up computations in V8. We don't have anything against NEON. So far we have been able to do better without.
Cheers, -- Mads
On Mon, Apr 4, 2011 at 11:20 AM, Víctor M. Jáquez L. <vjaq...@igalia.com> wrote:
> On Mon, Apr 04, 2011 at 10:46:29AM +0200, Søren Gjesse wrote: >> The Crankshaft optimizing compiler requires VFPv3. Without VFPv3 the >> non-optimizing will be used for all code. V8 cannot make use of NEON.
> Why v8 cannot make use of NEON? Because of an specific reason?
> vmjl
>> Regards, >> Søren
>> On Sat, Apr 2, 2011 at 08:40, Arun M <arunm.chr...@gmail.com> wrote:
>> > Hi
>> > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices >> > which does not have VFPv3 FPU?
>> > Thanks & Regards >> > Arun
>> > On Mar 9, 6:02 pm, Søren Gjesse <sgje...@chromium.org> wrote: >> > > For ARM crankshaft is now the default. This change is in the repository >> > > starting from V8 version 3.2. To use the previous optimizing compiler >> > > --nocrankshaft will have to be used. When crankshaft for ARM has been >> > fully >> > > stabilized the previous optimizing compiler will be removed from the >> > > repository and running with --nocrankshaft will no longer be possible. >> > There >> > > is no specific date to when this will happen but most likely it will be >> > > within a month or two. The removal of the previous optimizing compiler >> > will >> > > happen for all supported platforms simultaneously,
>> > > The previous optimizing compiler can of cause still be found in previous >> > > versions of V8.
>> > > Regards, >> > > Søren
>> > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> >> > wrote: >> > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s - >> > > > anyone have any benchmarks? I'm hesitant to invest time in using V8 >> > > > for my project if it's going to get substantially slower soon. Is >> > > > there any estimated time frame for when nocrankshaft will be >> > > > deprecated?
>> > > > Thanks, >> > > > Hugo
>> > > > On Feb 23, 9:14 pm, Søren Gjesse <sgje...@chromium.org> wrote: >> > > > > Just a follow-up note regarding the new optimizing compiler >> > (crankshaft). >> > > > > This will be enabled by default for ARM quite soon, and the existing >> > > > > optimizing compiler will be removed at some point. For non ARMv7+VFP >> > > > devices >> > > > > this means that the base JIT (non-optimizing/full-compiler) will be >> > used. >> > > > To >> > > > > measure the different compilers on a ARMv7+VFP device use following >> > > > options:
>> > > > > --nocrankshaft (current optimizing JIT - the current default) >> > > > > --crankshaft (new optimizing JIT - the soon to be default) >> > > > > --always-full-compiler (base/non-optimizing compiler)
>> > > > > Going forward using --crankshaft on a non ARMv7+VFP device will have >> > no >> > > > > effect and execution will fallback to --always-full-compiler.
>> > > > > Regards, >> > > > > Søren
>> > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta >> > > > > <rodolph.perfe...@gmail.com>wrote:
>> > > > > > V8 can run on ARMv4 devices (non T though).
>> > > > > > There is no interpreter in V8 so you will be using the JIT every >> > time, >> > > > > > perfromance should be good (keep in mind CPU like 926-ej-s do not >> > have >> > > > L2 >> > > > > > cache and this is going to have a visible impact). There is a new >> > JIT >> > > > > > infrastructure being developed (crankshaft) which features an >> > > > optimising JIT >> > > > > > and this will only be for ARMv7+VFP devices.
>> > > > > > HTH, >> > > > > > Rodolph.
>> > > > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> >> > > > wrote:
>> > > > > >> Hi,
>> > > > > >> I can't find in the documentation which ARM architecture types V8 >> > > > > >> supports. Does it support older ARM9 devices (I'm specifically >> > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only >> > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) >> > build >> > > > > >> on ARMv5te, but do all the JIT features work or is it running in a >> > > > > >> byte code interpreter fallback or something? Can I expect good >> > > > > >> performance?
> we have not found any of the NEON instructions useful to speed up
> computations in V8. We don't have anything against NEON. So far we
> have been able to do better without.
> Cheers, -- Mads
> On Mon, Apr 4, 2011 at 11:20 AM, Víctor M. Jáquez L. <vjaq...@igalia.com> wrote:
> > On Mon, Apr 04, 2011 at 10:46:29AM +0200, Søren Gjesse wrote:
> >> The Crankshaft optimizing compiler requires VFPv3. Without VFPv3 the
> >> non-optimizing will be used for all code. V8 cannot make use of NEON.
> > Why v8 cannot make use of NEON? Because of an specific reason?
> > vmjl
> >> Regards,
> >> Søren
> >> On Sat, Apr 2, 2011 at 08:40, Arun M <arunm.chr...@gmail.com> wrote:
> >> > Hi
> >> > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices
> >> > which does not have VFPv3 FPU?
> >> > Thanks & Regards
> >> > Arun
> >> > On Mar 9, 6:02 pm, Søren Gjesse <sgje...@chromium.org> wrote:
> >> > > For ARM crankshaft is now the default. This change is in the repository
> >> > > starting from V8 version 3.2. To use the previous optimizing compiler
> >> > > --nocrankshaft will have to be used. When crankshaft for ARM has been
> >> > fully
> >> > > stabilized the previous optimizing compiler will be removed from the
> >> > > repository and running with --nocrankshaft will no longer be possible.
> >> > There
> >> > > is no specific date to when this will happen but most likely it will be
> >> > > within a month or two. The removal of the previous optimizing compiler
> >> > will
> >> > > happen for all supported platforms simultaneously,
> >> > > The previous optimizing compiler can of cause still be found in previous
> >> > > versions of V8.
> >> > > Regards,
> >> > > Søren
> >> > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com>
> >> > wrote:
> >> > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s -
> >> > > > anyone have any benchmarks? I'm hesitant to invest time in using V8
> >> > > > for my project if it's going to get substantially slower soon. Is
> >> > > > there any estimated time frame for when nocrankshaft will be
> >> > > > deprecated?
> >> > > > Thanks,
> >> > > > Hugo
> >> > > > On Feb 23, 9:14 pm, Søren Gjesse <sgje...@chromium.org> wrote:
> >> > > > > Just a follow-up note regarding the new optimizing compiler
> >> > (crankshaft).
> >> > > > > This will be enabled by default for ARM quite soon, and the existing
> >> > > > > optimizing compiler will be removed at some point. For non ARMv7+VFP
> >> > > > devices
> >> > > > > this means that the base JIT (non-optimizing/full-compiler) will be
> >> > used.
> >> > > > To
> >> > > > > measure the different compilers on a ARMv7+VFP device use following
> >> > > > options:
> >> > > > > --nocrankshaft (current optimizing JIT - the current default)
> >> > > > > --crankshaft (new optimizing JIT - the soon to be default)
> >> > > > > --always-full-compiler (base/non-optimizing compiler)
> >> > > > > Going forward using --crankshaft on a non ARMv7+VFP device will have
> >> > no
> >> > > > > effect and execution will fallback to --always-full-compiler.
> >> > > > > Regards,
> >> > > > > Søren
> >> > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta
> >> > > > > <rodolph.perfe...@gmail.com>wrote:
> >> > > > > > V8 can run on ARMv4 devices (non T though).
> >> > > > > > There is no interpreter in V8 so you will be using the JIT every
> >> > time,
> >> > > > > > perfromance should be good (keep in mind CPU like 926-ej-s do not
> >> > have
> >> > > > L2
> >> > > > > > cache and this is going to have a visible impact). There is a new
> >> > JIT
> >> > > > > > infrastructure being developed (crankshaft) which features an
> >> > > > optimising JIT
> >> > > > > > and this will only be for ARMv7+VFP devices.
> >> > > > > > HTH,
> >> > > > > > Rodolph.
> >> > > > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com>
> >> > > > wrote:
> >> > > > > >> Hi,
> >> > > > > >> I can't find in the documentation which ARM architecture types V8
> >> > > > > >> supports. Does it support older ARM9 devices (I'm specifically
> >> > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only
> >> > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to)
> >> > build
> >> > > > > >> on ARMv5te, but do all the JIT features work or is it running in a
> >> > > > > >> byte code interpreter fallback or something? Can I expect good
> >> > > > > >> performance?
>>>>>> For ARM crankshaft is now the default. This change is in the repository >>>>>> starting from V8 version 3.2.
> Thanks & Regards > Arun
> On Apr 4, 7:52 pm, Mads Sig Ager <a...@chromium.org> wrote: >> Hi Victor,
>> we have not found any of the NEON instructions useful to speed up >> computations in V8. We don't have anything against NEON. So far we >> have been able to do better without.
>> Cheers, -- Mads
>> On Mon, Apr 4, 2011 at 11:20 AM, V ctor M. J quez L. <vjaq...@igalia.com> wrote:
>>> On Mon, Apr 04, 2011 at 10:46:29AM +0200, S ren Gjesse wrote: >>>> The Crankshaft optimizing compiler requires VFPv3. Without VFPv3 the >>>> non-optimizing will be used for all code. V8 cannot make use of NEON.
>>> Why v8 cannot make use of NEON? Because of an specific reason?
>>> vmjl
>>>> Regards, >>>> S ren
>>>> On Sat, Apr 2, 2011 at 08:40, Arun M <arunm.chr...@gmail.com> wrote:
>>>>> Hi
>>>>> Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices >>>>> which does not have VFPv3 FPU?
>>>>> Thanks & Regards >>>>> Arun
>>>>> On Mar 9, 6:02 pm, S ren Gjesse <sgje...@chromium.org> wrote: >>>>>> For ARM crankshaft is now the default. This change is in the repository >>>>>> starting from V8 version 3.2. To use the previous optimizing compiler >>>>>> --nocrankshaft will have to be used. When crankshaft for ARM has been >>>>> fully >>>>>> stabilized the previous optimizing compiler will be removed from the >>>>>> repository and running with --nocrankshaft will no longer be possible. >>>>> There >>>>>> is no specific date to when this will happen but most likely it will be >>>>>> within a month or two. The removal of the previous optimizing compiler >>>>> will >>>>>> happen for all supported platforms simultaneously,
>>>>>> The previous optimizing compiler can of cause still be found in previous >>>>>> versions of V8.
>>>>>> Regards, >>>>>> S ren
>>>>>> On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> >>>>> wrote: >>>>>>> How much slower is full-compiler than nocrankshaft on ARM926ej-s - >>>>>>> anyone have any benchmarks? I'm hesitant to invest time in using V8 >>>>>>> for my project if it's going to get substantially slower soon. Is >>>>>>> there any estimated time frame for when nocrankshaft will be >>>>>>> deprecated?
>>>>>>> Thanks, >>>>>>> Hugo
>>>>>>> On Feb 23, 9:14 pm, S ren Gjesse <sgje...@chromium.org> wrote: >>>>>>>> Just a follow-up note regarding the new optimizing compiler >>>>> (crankshaft). >>>>>>>> This will be enabled by default for ARM quite soon, and the existing >>>>>>>> optimizing compiler will be removed at some point. For non ARMv7+VFP >>>>>>> devices >>>>>>>> this means that the base JIT (non-optimizing/full-compiler) will be >>>>> used. >>>>>>> To >>>>>>>> measure the different compilers on a ARMv7+VFP device use following >>>>>>> options:
>>>>>>>> --nocrankshaft (current optimizing JIT - the current default) >>>>>>>> --crankshaft (new optimizing JIT - the soon to be default) >>>>>>>> --always-full-compiler (base/non-optimizing compiler)
>>>>>>>> Going forward using --crankshaft on a non ARMv7+VFP device will have >>>>> no >>>>>>>> effect and execution will fallback to --always-full-compiler.
>>>>>>>> Regards, >>>>>>>> S ren
>>>>>>>> On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta >>>>>>>> <rodolph.perfe...@gmail.com>wrote:
>>>>>>>>> V8 can run on ARMv4 devices (non T though).
>>>>>>>>> There is no interpreter in V8 so you will be using the JIT every >>>>> time, >>>>>>>>> perfromance should be good (keep in mind CPU like 926-ej-s do not >>>>> have >>>>>>> L2 >>>>>>>>> cache and this is going to have a visible impact). There is a new >>>>> JIT >>>>>>>>> infrastructure being developed (crankshaft) which features an >>>>>>> optimising JIT >>>>>>>>> and this will only be for ARMv7+VFP devices.
>>>>>>>>> HTH, >>>>>>>>> Rodolph.
>>>>>>>>> On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> >>>>>>> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>> I can't find in the documentation which ARM architecture types V8 >>>>>>>>>> supports. Does it support older ARM9 devices (I'm specifically >>>>>>>>>> interested in an ARMv5te architecture, ARM926ej-s device) or only >>>>>>>>>> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) >>>>> build >>>>>>>>>> on ARMv5te, but do all the JIT features work or is it running in a >>>>>>>>>> byte code interpreter fallback or something? Can I expect good >>>>>>>>>> performance?
Crankshaft has been the default for V8 on both ARM and x64 starting from version 3.2.0. When you run the browser on the ARM machine what is shown for about:version? You could try to pass these
> But I still have not got any improvement on ARM platform for the V8 > benchmark suite.
> Which version of Chromium will include the crankshaft improvement for > V8 on ARM?
> Thanks & Regards > Arun
> On Apr 4, 7:52 pm, Mads Sig Ager <a...@chromium.org> wrote: > > Hi Victor,
> > we have not found any of the NEON instructions useful to speed up > > computations in V8. We don't have anything against NEON. So far we > > have been able to do better without.
> > Cheers, -- Mads
> > On Mon, Apr 4, 2011 at 11:20 AM, Víctor M. Jáquez L. <vjaq...@igalia.com> > wrote:
> > > On Mon, Apr 04, 2011 at 10:46:29AM +0200, Søren Gjesse wrote: > > >> The Crankshaft optimizing compiler requires VFPv3. Without VFPv3 the > > >> non-optimizing will be used for all code. V8 cannot make use of NEON.
> > > Why v8 cannot make use of NEON? Because of an specific reason?
> > > vmjl
> > >> Regards, > > >> Søren
> > >> On Sat, Apr 2, 2011 at 08:40, Arun M <arunm.chr...@gmail.com> wrote:
> > >> > Hi
> > >> > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices > > >> > which does not have VFPv3 FPU?
> > >> > Thanks & Regards > > >> > Arun
> > >> > On Mar 9, 6:02 pm, Søren Gjesse <sgje...@chromium.org> wrote: > > >> > > For ARM crankshaft is now the default. This change is in the > repository > > >> > > starting from V8 version 3.2. To use the previous optimizing > compiler > > >> > > --nocrankshaft will have to be used. When crankshaft for ARM has > been > > >> > fully > > >> > > stabilized the previous optimizing compiler will be removed from > the > > >> > > repository and running with --nocrankshaft will no longer be > possible. > > >> > There > > >> > > is no specific date to when this will happen but most likely it > will be > > >> > > within a month or two. The removal of the previous optimizing > compiler > > >> > will > > >> > > happen for all supported platforms simultaneously,
> > >> > > The previous optimizing compiler can of cause still be found in > previous > > >> > > versions of V8.
> > >> > > Regards, > > >> > > Søren
> > >> > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent < > hugo.vinc...@gmail.com> > > >> > wrote: > > >> > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s > - > > >> > > > anyone have any benchmarks? I'm hesitant to invest time in using > V8 > > >> > > > for my project if it's going to get substantially slower soon. > Is > > >> > > > there any estimated time frame for when nocrankshaft will be > > >> > > > deprecated?
> > >> > > > Thanks, > > >> > > > Hugo
> > >> > > > On Feb 23, 9:14 pm, Søren Gjesse <sgje...@chromium.org> wrote: > > >> > > > > Just a follow-up note regarding the new optimizing compiler > > >> > (crankshaft). > > >> > > > > This will be enabled by default for ARM quite soon, and the > existing > > >> > > > > optimizing compiler will be removed at some point. For non > ARMv7+VFP > > >> > > > devices > > >> > > > > this means that the base JIT (non-optimizing/full-compiler) > will be > > >> > used. > > >> > > > To > > >> > > > > measure the different compilers on a ARMv7+VFP device use > following > > >> > > > options:
> > >> > > > > --nocrankshaft (current optimizing JIT - the current > default) > > >> > > > > --crankshaft (new optimizing JIT - the soon to be default) > > >> > > > > --always-full-compiler (base/non-optimizing compiler)
> > >> > > > > Going forward using --crankshaft on a non ARMv7+VFP device > will have > > >> > no > > >> > > > > effect and execution will fallback to --always-full-compiler.
> > >> > > > > Regards, > > >> > > > > Søren
> > >> > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > >> > > > > <rodolph.perfe...@gmail.com>wrote:
> > >> > > > > > V8 can run on ARMv4 devices (non T though).
> > >> > > > > > There is no interpreter in V8 so you will be using the JIT > every > > >> > time, > > >> > > > > > perfromance should be good (keep in mind CPU like 926-ej-s > do not > > >> > have > > >> > > > L2 > > >> > > > > > cache and this is going to have a visible impact). There is > a new > > >> > JIT > > >> > > > > > infrastructure being developed (crankshaft) which features > an > > >> > > > optimising JIT > > >> > > > > > and this will only be for ARMv7+VFP devices.
> > >> > > > > > HTH, > > >> > > > > > Rodolph.
> > >> > > > > > On 23 February 2011 17:12, Hugo Vincent < > hugo.vinc...@gmail.com> > > >> > > > wrote:
> > >> > > > > >> Hi,
> > >> > > > > >> I can't find in the documentation which ARM architecture > types V8 > > >> > > > > >> supports. Does it support older ARM9 devices (I'm > specifically > > >> > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) > or only > > >> > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed > to) > > >> > build > > >> > > > > >> on ARMv5te, but do all the JIT features work or is it > running in a > > >> > > > > >> byte code interpreter fallback or something? Can I expect > good > > >> > > > > >> performance?
> On Mon, Apr 04, 2011 at 09:45:52AM +0100, Alexandre Rames wrote:
> > Hello Arun,
> > Crankshaft is now enabled by default on ARM processors supporting VFPv3.
> > v8 does not use NEON (it is not worth using, at least currently), but I
> > believe no processors with this configuration (NEON without VFPv3) exist
> > anyway. So if the CPU feature detection work correctly, v8 should assume
> > that you have VFPv3 if it detects NEON, and thus use use Crankshaft.
> > If I remember correctly there has been some issues with incorrect feature
> > detection. A simple run of the v8 benchmarks with the latest bleeding_edge
> > and the frequency of your CPU should be enough to determine if crankshaft is
> > enabled.
> The CPU features detection is done parsing the /proc/cpuinfo file:
> So, if your cpu information is not exposed correctly the detection will fail.
> I'd never seen an ARM with NEON but without VFPv3.
> vmjl
> > I hope this helps.
> > Regards,
> > Alexandre
> > On Sat, Apr 2, 2011 at 7:40 AM, Arun M <arunm.chr...@gmail.com> wrote:
> > > Hi
> > > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices
> > > which does not have VFPv3 FPU?
> > > Thanks & Regards
> > > Arun
> > > On Mar 9, 6:02 pm, S�ren Gjesse <sgje...@chromium.org> wrote:
> > > > For ARM crankshaft is now the default. This change is in the repository
> > > > starting from V8 version 3.2. To use the previous optimizing compiler
> > > > --nocrankshaft will have to be used. When crankshaft for ARM has been
> > > fully
> > > > stabilized the previous optimizing compiler will be removed from the
> > > > repository and running with --nocrankshaft will no longer be possible.
> > > There
> > > > is no specific date to when this will happen but most likely it will be
> > > > within a month or two. The removal of the previous optimizing compiler
> > > will
> > > > happen for all supported platforms simultaneously,
> > > > The previous optimizing compiler can of cause still be found in previous
> > > > versions of V8.
> > > > Regards,
> > > > S�ren
> > > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com>
> > > wrote:
> > > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s -
> > > > > anyone have any benchmarks? I'm hesitant to invest time in using V8
> > > > > for my project if it's going to get substantially slower soon. Is
> > > > > there any estimated time frame for when nocrankshaft will be
> > > > > deprecated?
> > > > > Thanks,
> > > > > Hugo
> > > > > On Feb 23, 9:14 pm, S�ren Gjesse <sgje...@chromium.org> wrote:
> > > > > > Just a follow-up note regarding the new optimizing compiler
> > > (crankshaft).
> > > > > > This will be enabled by default for ARM quite soon, and the existing
> > > > > > optimizing compiler will be removed at some point. For non ARMv7+VFP
> > > > > devices
> > > > > > this means that the base JIT (non-optimizing/full-compiler) will be
> > > used.
> > > > > To
> > > > > > measure the different compilers on a ARMv7+VFP device use following
> > > > > options:
> > > > > > --nocrankshaft (current optimizing JIT - the current default)
> > > > > > --crankshaft (new optimizing JIT - the soon to be default)
> > > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > > > Going forward using --crankshaft on a non ARMv7+VFP device will have
> > > no
> > > > > > effect and execution will fallback to --always-full-compiler.
> > > > > > Regards,
> > > > > > S�ren
> > > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta
> > > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > > There is no interpreter in V8 so you will be using the JIT every
> > > time,
> > > > > > > perfromance should be good (keep in mind CPU like 926-ej-s do not
> > > have
> > > > > L2
> > > > > > > cache and this is going to have a visible impact). There is a new
> > > JIT
> > > > > > > infrastructure being developed (crankshaft) which features an
> > > > > optimising JIT
> > > > > > > and this will only be for ARMv7+VFP devices.
> > > > > > > HTH,
> > > > > > > Rodolph.
> > > > > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com>
> > > > > wrote:
> > > > > > >> Hi,
> > > > > > >> I can't find in the documentation which ARM architecture types V8
> > > > > > >> supports. Does it support older ARM9 devices (I'm specifically
> > > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only
> > > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to)
> > > build
> > > > > > >> on ARMv5te, but do all the JIT features work or is it running in a
> > > > > > >> byte code interpreter fallback or something? Can I expect good
> > > > > > >> performance?
> On Apr 4, 6:19 pm, V ctor M. J quez L. <vjaq...@igalia.com> wrote: > > On Mon, Apr 04, 2011 at 09:45:52AM +0100, Alexandre Rames wrote: > > > Hello Arun,
> > > Crankshaft is now enabled by default on ARM processors supporting VFPv3.. > > > v8 does not use NEON (it is not worth using, at least currently), but I > > > believe no processors with this configuration (NEON without VFPv3) exist > > > anyway. So if the CPU feature detection work correctly, v8 should assume > > > that you have VFPv3 if it detects NEON, and thus use use Crankshaft.
> > > If I remember correctly there has been some issues with incorrect feature > > > detection. A simple run of the v8 benchmarks with the latest bleeding_edge > > > and the frequency of your CPU should be enough to determine if crankshaft is > > > enabled.
> > The CPU features detection is done parsing the /proc/cpuinfo file:
> > So, if your cpu information is not exposed correctly the detection will fail.
> > I'd never seen an ARM with NEON but without VFPv3.
> > vmjl
> > > I hope this helps.
> > > Regards,
> > > Alexandre
> > > On Sat, Apr 2, 2011 at 7:40 AM, Arun M <arunm.chr...@gmail.com> wrote:
> > > > Hi
> > > > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON devices > > > > which does not have VFPv3 FPU?
> > > > Thanks & Regards > > > > Arun
> > > > On Mar 9, 6:02 pm, S ren Gjesse <sgje...@chromium.org> wrote: > > > > > For ARM crankshaft is now the default. This change is in the repository > > > > > starting from V8 version 3.2. To use the previous optimizing compiler > > > > > --nocrankshaft will have to be used. When crankshaft for ARM has been > > > > fully > > > > > stabilized the previous optimizing compiler will be removed from the > > > > > repository and running with --nocrankshaft will no longer be possible. > > > > There > > > > > is no specific date to when this will happen but most likely it will be > > > > > within a month or two. The removal of the previous optimizing compiler > > > > will > > > > > happen for all supported platforms simultaneously,
> > > > > The previous optimizing compiler can of cause still be found in previous > > > > > versions of V8.
> > > > > Regards, > > > > > S ren
> > > > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <hugo.vinc...@gmail.com> > > > > wrote: > > > > > > How much slower is full-compiler than nocrankshaft on ARM926ej-s - > > > > > > anyone have any benchmarks? I'm hesitant to invest time in using V8 > > > > > > for my project if it's going to get substantially slower soon. Is > > > > > > there any estimated time frame for when nocrankshaft will be > > > > > > deprecated?
> > > > > > Thanks, > > > > > > Hugo
> > > > > > On Feb 23, 9:14 pm, S ren Gjesse <sgje...@chromium.org> wrote: > > > > > > > Just a follow-up note regarding the new optimizing compiler > > > > (crankshaft). > > > > > > > This will be enabled by default for ARM quite soon, and the existing > > > > > > > optimizing compiler will be removed at some point. For non ARMv7+VFP > > > > > > devices > > > > > > > this means that the base JIT (non-optimizing/full-compiler) will be > > > > used. > > > > > > To > > > > > > > measure the different compilers on a ARMv7+VFP device use following > > > > > > options:
> > > > > > > --nocrankshaft (current optimizing JIT - the current default) > > > > > > > --crankshaft (new optimizing JIT - the soon to be default) > > > > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > > > > Going forward using --crankshaft on a non ARMv7+VFP device will have > > > > no > > > > > > > effect and execution will fallback to --always-full-compiler.
> > > > > > > Regards, > > > > > > > S ren
> > > > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > > > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > > > There is no interpreter in V8 so you will be using the JIT every > > > > time, > > > > > > > > perfromance should be good (keep in mind CPU like 926-ej-s do not > > > > have > > > > > > L2 > > > > > > > > cache and this is going to have a visible impact). There is a new > > > > JIT > > > > > > > > infrastructure being developed (crankshaft) which features an > > > > > > optimising JIT > > > > > > > > and this will only be for ARMv7+VFP devices.
> > > > > > > > HTH, > > > > > > > > Rodolph.
> > > > > > > > On 23 February 2011 17:12, Hugo Vincent <hugo.vinc...@gmail.com> > > > > > > wrote:
> > > > > > > >> Hi,
> > > > > > > >> I can't find in the documentation which ARM architecture types V8 > > > > > > > >> supports. Does it support older ARM9 devices (I'm specifically > > > > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) or only > > > > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is (supposed to) > > > > build > > > > > > > >> on ARMv5te, but do all the JIT features work or is it running in a > > > > > > > >> byte code interpreter fallback or something? Can I expect good > > > > > > > >> performance?
> On Wed, Apr 06, 2011 at 12:00:27AM -0700, Arun M wrote: > > Hi Victor
> > Will this method of detecting VFPv3 work in chromium browser when > > sandbox is enabled? > > Will browser sandbox allow to fopen "/proc/cpuinfo" file?
> Sorry Arun, I don't know. I'm not familiar with chrome in general.
> vmjl
> > Arun
> > On Apr 4, 6:19 pm, Víctor M. Jáquez L. <vjaq...@igalia.com> wrote: > > > On Mon, Apr 04, 2011 at 09:45:52AM +0100, Alexandre Rames wrote: > > > > Hello Arun,
> > > > Crankshaft is now enabled by default on ARM processors supporting > VFPv3.. > > > > v8 does not use NEON (it is not worth using, at least currently), but > I > > > > believe no processors with this configuration (NEON without VFPv3) > exist > > > > anyway. So if the CPU feature detection work correctly, v8 should > assume > > > > that you have VFPv3 if it detects NEON, and thus use use Crankshaft.
> > > > If I remember correctly there has been some issues with incorrect > feature > > > > detection. A simple run of the v8 benchmarks with the latest > bleeding_edge > > > > and the frequency of your CPU should be enough to determine if > crankshaft is > > > > enabled.
> > > The CPU features detection is done parsing the /proc/cpuinfo file:
> > > So, if your cpu information is not exposed correctly the detection will > fail.
> > > I'd never seen an ARM with NEON but without VFPv3.
> > > vmjl
> > > > I hope this helps.
> > > > Regards,
> > > > Alexandre
> > > > On Sat, Apr 2, 2011 at 7:40 AM, Arun M <arunm.chr...@gmail.com> > wrote:
> > > > > Hi
> > > > > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON > devices > > > > > which does not have VFPv3 FPU?
> > > > > Thanks & Regards > > > > > Arun
> > > > > On Mar 9, 6:02 pm, S�ren Gjesse <sgje...@chromium.org> wrote: > > > > > > For ARM crankshaft is now the default. This change is in the > repository > > > > > > starting from V8 version 3.2. To use the previous optimizing > compiler > > > > > > --nocrankshaft will have to be used. When crankshaft for ARM has > been > > > > > fully > > > > > > stabilized the previous optimizing compiler will be removed from > the > > > > > > repository and running with --nocrankshaft will no longer be > possible. > > > > > There > > > > > > is no specific date to when this will happen but most likely it > will be > > > > > > within a month or two. The removal of the previous optimizing > compiler > > > > > will > > > > > > happen for all supported platforms simultaneously,
> > > > > > The previous optimizing compiler can of cause still be found in > previous > > > > > > versions of V8.
> > > > > > Regards, > > > > > > S�ren
> > > > > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent < > hugo.vinc...@gmail.com> > > > > > wrote: > > > > > > > How much slower is full-compiler than nocrankshaft on > ARM926ej-s - > > > > > > > anyone have any benchmarks? I'm hesitant to invest time in > using V8 > > > > > > > for my project if it's going to get substantially slower soon. > Is > > > > > > > there any estimated time frame for when nocrankshaft will be > > > > > > > deprecated?
> > > > > > > Thanks, > > > > > > > Hugo
> > > > > > > On Feb 23, 9:14 pm, S�ren Gjesse <sgje...@chromium.org> > wrote: > > > > > > > > Just a follow-up note regarding the new optimizing compiler > > > > > (crankshaft). > > > > > > > > This will be enabled by default for ARM quite soon, and the > existing > > > > > > > > optimizing compiler will be removed at some point. For non > ARMv7+VFP > > > > > > > devices > > > > > > > > this means that the base JIT (non-optimizing/full-compiler) > will be > > > > > used. > > > > > > > To > > > > > > > > measure the different compilers on a ARMv7+VFP device use > following > > > > > > > options:
> > > > > > > > --nocrankshaft (current optimizing JIT - the current > default) > > > > > > > > --crankshaft (new optimizing JIT - the soon to be default) > > > > > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > > > > > Going forward using --crankshaft on a non ARMv7+VFP device > will have > > > > > no > > > > > > > > effect and execution will fallback to --always-full-compiler.
> > > > > > > > Regards, > > > > > > > > S�ren
> > > > > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > > > > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > > > > There is no interpreter in V8 so you will be using the JIT > every > > > > > time, > > > > > > > > > perfromance should be good (keep in mind CPU like 926-ej-s > do not > > > > > have > > > > > > > L2 > > > > > > > > > cache and this is going to have a visible impact). There is > a new > > > > > JIT > > > > > > > > > infrastructure being developed (crankshaft) which features > an > > > > > > > optimising JIT > > > > > > > > > and this will only be for ARMv7+VFP devices.
> > > > > > > > > HTH, > > > > > > > > > Rodolph.
> > > > > > > > > On 23 February 2011 17:12, Hugo Vincent < > hugo.vinc...@gmail.com> > > > > > > > wrote:
> > > > > > > > >> Hi,
> > > > > > > > >> I can't find in the documentation which ARM architecture > types V8 > > > > > > > > >> supports. Does it support older ARM9 devices (I'm > specifically > > > > > > > > >> interested in an ARMv5te architecture, ARM926ej-s device) > or only > > > > > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is > (supposed to) > > > > > build > > > > > > > > >> on ARMv5te, but do all the JIT features work or is it > running in a > > > > > > > > >> byte code interpreter fallback or something? Can I expect > good > > > > > > > > >> performance?
> Have you tried running Chrome with the options Soren mentioned? The result
> should tell you if crankshaft is enabled or not.
> Rodolph.
> 2011/4/6 Víctor M. Jáquez L. <vjaq...@igalia.com>
> > On Wed, Apr 06, 2011 at 12:00:27AM -0700, Arun M wrote:
> > > Hi Victor
> > > Will this method of detecting VFPv3 work in chromium browser when
> > > sandbox is enabled?
> > > Will browser sandbox allow to fopen "/proc/cpuinfo" file?
> > Sorry Arun, I don't know. I'm not familiar with chrome in general.
> > vmjl
> > > Arun
> > > On Apr 4, 6:19 pm, Víctor M. Jáquez L. <vjaq...@igalia.com> wrote:
> > > > On Mon, Apr 04, 2011 at 09:45:52AM +0100, Alexandre Rames wrote:
> > > > > Hello Arun,
> > > > > Crankshaft is now enabled by default on ARM processors supporting
> > VFPv3..
> > > > > v8 does not use NEON (it is not worth using, at least currently), but
> > I
> > > > > believe no processors with this configuration (NEON without VFPv3)
> > exist
> > > > > anyway. So if the CPU feature detection work correctly, v8 should
> > assume
> > > > > that you have VFPv3 if it detects NEON, and thus use use Crankshaft.
> > > > > If I remember correctly there has been some issues with incorrect
> > feature
> > > > > detection. A simple run of the v8 benchmarks with the latest
> > bleeding_edge
> > > > > and the frequency of your CPU should be enough to determine if
> > crankshaft is
> > > > > enabled.
> > > > The CPU features detection is done parsing the /proc/cpuinfo file:
> > > > So, if your cpu information is not exposed correctly the detection will
> > fail.
> > > > I'd never seen an ARM with NEON but without VFPv3.
> > > > vmjl
> > > > > I hope this helps.
> > > > > Regards,
> > > > > Alexandre
> > > > > On Sat, Apr 2, 2011 at 7:40 AM, Arun M <arunm.chr...@gmail.com>
> > wrote:
> > > > > > Hi
> > > > > > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON
> > devices
> > > > > > which does not have VFPv3 FPU?
> > > > > > Thanks & Regards
> > > > > > Arun
> > > > > > On Mar 9, 6:02 pm, S�ren Gjesse <sgje...@chromium.org> wrote:
> > > > > > > For ARM crankshaft is now the default. This change is in the
> > repository
> > > > > > > starting from V8 version 3.2. To use the previous optimizing
> > compiler
> > > > > > > --nocrankshaft will have to be used. When crankshaft for ARM has
> > been
> > > > > > fully
> > > > > > > stabilized the previous optimizing compiler will be removed from
> > the
> > > > > > > repository and running with --nocrankshaft will no longer be
> > possible.
> > > > > > There
> > > > > > > is no specific date to when this will happen but most likely it
> > will be
> > > > > > > within a month or two. The removal of the previous optimizing
> > compiler
> > > > > > will
> > > > > > > happen for all supported platforms simultaneously,
> > > > > > > The previous optimizing compiler can of cause still be found in
> > previous
> > > > > > > versions of V8.
> > > > > > > Regards,
> > > > > > > S�ren
> > > > > > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <
> > hugo.vinc...@gmail.com>
> > > > > > wrote:
> > > > > > > > How much slower is full-compiler than nocrankshaft on
> > ARM926ej-s -
> > > > > > > > anyone have any benchmarks? I'm hesitant to invest time in
> > using V8
> > > > > > > > for my project if it's going to get substantially slower soon.
> > Is
> > > > > > > > there any estimated time frame for when nocrankshaft will be
> > > > > > > > deprecated?
> > > > > > > > Thanks,
> > > > > > > > Hugo
> > > > > > > > On Feb 23, 9:14 pm, S�ren Gjesse <sgje...@chromium.org>
> > wrote:
> > > > > > > > > Just a follow-up note regarding the new optimizing compiler
> > > > > > (crankshaft).
> > > > > > > > > This will be enabled by default for ARM quite soon, and the
> > existing
> > > > > > > > > optimizing compiler will be removed at some point. For non
> > ARMv7+VFP
> > > > > > > > devices
> > > > > > > > > this means that the base JIT (non-optimizing/full-compiler)
> > will be
> > > > > > used.
> > > > > > > > To
> > > > > > > > > measure the different compilers on a ARMv7+VFP device use
> > following
> > > > > > > > options:
> > > > > > > > > --nocrankshaft (current optimizing JIT - the current
> > default)
> > > > > > > > > --crankshaft (new optimizing JIT - the soon to be default)
> > > > > > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > > > > > > Going forward using --crankshaft on a non ARMv7+VFP device
> > will have
> > > > > > no
> > > > > > > > > effect and execution will fallback to --always-full-compiler.
> > > > > > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta
> > > > > > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > > > > > There is no interpreter in V8 so you will be using the JIT
> > every
> > > > > > time,
> > > > > > > > > > perfromance should be good (keep in mind CPU like 926-ej-s
> > do not
> > > > > > have
> > > > > > > > L2
> > > > > > > > > > cache and this is going to have a visible impact). There is
> > a new
> > > > > > JIT
> > > > > > > > > > infrastructure being developed (crankshaft) which features
> > an
> > > > > > > > optimising JIT
> > > > > > > > > > and this will only be for ARMv7+VFP devices.
> > > > > > > > > > On 23 February 2011 17:12, Hugo Vincent <
> > hugo.vinc...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > >> Hi,
> > > > > > > > > >> I can't find in the documentation which ARM architecture
> > types V8
> > > > > > > > > >> supports. Does it support older ARM9 devices (I'm
> > specifically
> > > > > > > > > >> interested in an ARMv5te architecture, ARM926ej-s device)
> > or only
> > > > > > > > > >> newer ARMv7 (Cortex-A8 etc)? I can see that it is
> > (supposed to)
> > > > > > build
> > > > > > > > > >> on ARMv5te, but do all the JIT features work or is it
> > running in a
> > > > > > > > > >> byte code interpreter fallback or something? Can I expect
> > good
> > > > > > > > > >> performance?
These are interesting experiments, and it would be great to get ot the bottom of this.
I assume that /proc/cpuinfo contains the strings "ARMv7" and "vfpv3", as that is the exact strings which are checked for. You could also try to run chrome with the --no-sandbox option to see whether that makes a diffrence. V8 has a number of options which can be used to trace the optimizations performed by crankshaft, try --js-flags="--trace-opt --trace-deopt --trace-osr --trace-bailout" for the full monty.
If you know that VFPv3 is available you could try to hack the CPU detection in OS:::ArmCpuHasFeature (platform-linux.cc) always return true for VFP3.
> > Have you tried running Chrome with the options Soren mentioned? The > result > > should tell you if crankshaft is enabled or not.
> > Rodolph.
> > 2011/4/6 Víctor M. Jáquez L. <vjaq...@igalia.com>
> > > On Wed, Apr 06, 2011 at 12:00:27AM -0700, Arun M wrote: > > > > Hi Victor
> > > > Will this method of detecting VFPv3 work in chromium browser when > > > > sandbox is enabled? > > > > Will browser sandbox allow to fopen "/proc/cpuinfo" file?
> > > Sorry Arun, I don't know. I'm not familiar with chrome in general.
> > > vmjl
> > > > Arun
> > > > On Apr 4, 6:19 pm, Víctor M. Jáquez L. <vjaq...@igalia.com> wrote: > > > > > On Mon, Apr 04, 2011 at 09:45:52AM +0100, Alexandre Rames wrote: > > > > > > Hello Arun,
> > > > > > Crankshaft is now enabled by default on ARM processors supporting > > > VFPv3.. > > > > > > v8 does not use NEON (it is not worth using, at least currently), > but > > > I > > > > > > believe no processors with this configuration (NEON without > VFPv3) > > > exist > > > > > > anyway. So if the CPU feature detection work correctly, v8 should > > > assume > > > > > > that you have VFPv3 if it detects NEON, and thus use use > Crankshaft.
> > > > > > If I remember correctly there has been some issues with incorrect > > > feature > > > > > > detection. A simple run of the v8 benchmarks with the latest > > > bleeding_edge > > > > > > and the frequency of your CPU should be enough to determine if > > > crankshaft is > > > > > > enabled.
> > > > > The CPU features detection is done parsing the /proc/cpuinfo file:
> > > > > So, if your cpu information is not exposed correctly the detection > will > > > fail.
> > > > > I'd never seen an ARM with NEON but without VFPv3.
> > > > > vmjl
> > > > > > I hope this helps.
> > > > > > Regards,
> > > > > > Alexandre
> > > > > > On Sat, Apr 2, 2011 at 7:40 AM, Arun M <arunm.chr...@gmail.com> > > > wrote:
> > > > > > > Hi
> > > > > > > Is Crankshaft optimizing compiler enabled for ARMv7-A + NEON > > > devices > > > > > > > which does not have VFPv3 FPU?
> > > > > > > Thanks & Regards > > > > > > > Arun
> > > > > > > On Mar 9, 6:02 pm, S�ren Gjesse <sgje...@chromium.org> > wrote: > > > > > > > > For ARM crankshaft is now the default. This change is in the > > > repository > > > > > > > > starting from V8 version 3.2. To use the previous optimizing > > > compiler > > > > > > > > --nocrankshaft will have to be used. When crankshaft for ARM > has > > > been > > > > > > > fully > > > > > > > > stabilized the previous optimizing compiler will be removed > from > > > the > > > > > > > > repository and running with --nocrankshaft will no longer be > > > possible. > > > > > > > There > > > > > > > > is no specific date to when this will happen but most likely > it > > > will be > > > > > > > > within a month or two. The removal of the previous optimizing > > > compiler > > > > > > > will > > > > > > > > happen for all supported platforms simultaneously,
> > > > > > > > The previous optimizing compiler can of cause still be found > in > > > previous > > > > > > > > versions of V8.
> > > > > > > > Regards, > > > > > > > > S�ren
> > > > > > > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent < > > > hugo.vinc...@gmail.com> > > > > > > > wrote: > > > > > > > > > How much slower is full-compiler than nocrankshaft on > > > ARM926ej-s - > > > > > > > > > anyone have any benchmarks? I'm hesitant to invest time in > > > using V8 > > > > > > > > > for my project if it's going to get substantially slower > soon. > > > Is > > > > > > > > > there any estimated time frame for when nocrankshaft will > be > > > > > > > > > deprecated?
> > > > > > > > > Thanks, > > > > > > > > > Hugo
> > > > > > > > > On Feb 23, 9:14 pm, S�ren Gjesse <sgje...@chromium.org> > > > wrote: > > > > > > > > > > Just a follow-up note regarding the new optimizing > compiler > > > > > > > (crankshaft). > > > > > > > > > > This will be enabled by default for ARM quite soon, and > the > > > existing > > > > > > > > > > optimizing compiler will be removed at some point. For > non > > > ARMv7+VFP > > > > > > > > > devices > > > > > > > > > > this means that the base JIT > (non-optimizing/full-compiler) > > > will be > > > > > > > used. > > > > > > > > > To > > > > > > > > > > measure the different compilers on a ARMv7+VFP device use > > > following > > > > > > > > > options:
> > > > > > > > > > --nocrankshaft (current optimizing JIT - the current > > > default) > > > > > > > > > > --crankshaft (new optimizing JIT - the soon to be > default) > > > > > > > > > > --always-full-compiler (base/non-optimizing compiler)
> > > > > > > > > > Going forward using --crankshaft on a non ARMv7+VFP > device > > > will have > > > > > > > no > > > > > > > > > > effect and execution will fallback to > --always-full-compiler.
> > > > > > > > > > On Wed, Feb 23, 2011 at 18:33, Rodolph Perfetta > > > > > > > > > > <rodolph.perfe...@gmail.com>wrote:
> > > > > > > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > > > > > > There is no interpreter in V8 so you will be using the > JIT > > > every > > > > > > > time, > > > > > > > > > > > perfromance should be good (keep in mind CPU like > 926-ej-s > > > do not > > > > > > > have > > > > > > > > > L2 > > > > > > > > > > > cache and this is going to have a visible impact). > There is > > > a new > > > > > > > JIT > > > > > > > > > > > infrastructure being developed (crankshaft) which > features > > > an > > > > > > > > > optimising JIT > > > > > > > > > > > and this will only be for ARMv7+VFP devices.
I tried all options.
When i disable sandbox or hack the CPU detection
in OS:::ArmCpuHasFeature and run v8 benchmark,
the browser tab crashes.
I am trying to find the issue.
Regards
Arun
On Apr 7, 4:22 pm, Søren Gjesse <sgje...@chromium.org> wrote:
> These are interesting experiments, and it would be great to get ot the
> bottom of this.
> I assume that /proc/cpuinfo contains the strings "ARMv7" and "vfpv3", as
> that is the exact strings which are checked for. You could also try to run
> chrome with the --no-sandbox option to see whether that makes a diffrence.
> V8 has a number of options which can be used to trace the optimizations
> performed by crankshaft, try --js-flags="--trace-opt --trace-deopt
> --trace-osr --trace-bailout" for the full monty.
> If you know that VFPv3 is available you could try to hack the CPU detection
> in OS:::ArmCpuHasFeature (platform-linux.cc) always return true for VFP3.
> Regards,
> Søren
> On Thu, Apr 7, 2011 at 03:25, Arun M <arunm.chr...@gmail.com> wrote:
> > Hi
> > I ran with --js-flags="--crankshaft" and --js-flags="--nocrankshaft"
> > options.
> > But the V8 scores are nearly same.
> > V8::DisableCrankshaft() function is called from cpu-arm.cc.
> > I think Chromium is not able to parse /proc/cpuinfo file and get VFPv3
> > information.
> > > Have you tried running Chrome with the options Soren mentioned? The
> > result
> > > should tell you if crankshaft is enabled or not.
> > > Rodolph.
> > > 2011/4/6 Víctor M. Jáquez L. <vjaq...@igalia.com>
> > > > On Wed, Apr 06, 2011 at 12:00:27AM -0700, Arun M wrote:
> > > > > Hi Victor
> > > > > Will this method of detecting VFPv3 work in chromium browser when
> > > > > sandbox is enabled?
> > > > > Will browser sandbox allow to fopen "/proc/cpuinfo" file?
> > > > Sorry Arun, I don't know. I'm not familiar with chrome in general.
> > > > vmjl
> > > > > Arun
> > > > > On Apr 4, 6:19 pm, Víctor M. Jáquez L. <vjaq...@igalia.com> wrote:
> > > > > > On Mon, Apr 04, 2011 at 09:45:52AM +0100, Alexandre Rames wrote:
> > > > > > > Hello Arun,
> > > > > > > Crankshaft is now enabled by default on ARM processors supporting
> > > > VFPv3..
> > > > > > > v8 does not use NEON (it is not worth using, at least currently),
> > but
> > > > I
> > > > > > > believe no processors with this configuration (NEON without
> > VFPv3)
> > > > exist
> > > > > > > anyway. So if the CPU feature detection work correctly, v8 should
> > > > assume
> > > > > > > that you have VFPv3 if it detects NEON, and thus use use
> > Crankshaft.
> > > > > > > If I remember correctly there has been some issues with incorrect
> > > > feature
> > > > > > > detection. A simple run of the v8 benchmarks with the latest
> > > > bleeding_edge
> > > > > > > and the frequency of your CPU should be enough to determine if
> > > > crankshaft is
> > > > > > > enabled.
> > > > > > The CPU features detection is done parsing the /proc/cpuinfo file:
> > > > > > > > On Mar 9, 6:02 pm, S�ren Gjesse <sgje...@chromium.org>
> > wrote:
> > > > > > > > > For ARM crankshaft is now the default. This change is in the
> > > > repository
> > > > > > > > > starting from V8 version 3.2. To use the previous optimizing
> > > > compiler
> > > > > > > > > --nocrankshaft will have to be used. When crankshaft for ARM
> > has
> > > > been
> > > > > > > > fully
> > > > > > > > > stabilized the previous optimizing compiler will be removed
> > from
> > > > the
> > > > > > > > > repository and running with --nocrankshaft will no longer be
> > > > possible.
> > > > > > > > There
> > > > > > > > > is no specific date to when this will happen but most likely
> > it
> > > > will be
> > > > > > > > > within a month or two. The removal of the previous optimizing
> > > > compiler
> > > > > > > > will
> > > > > > > > > happen for all supported platforms simultaneously,
> > > > > > > > > The previous optimizing compiler can of cause still be found
> > in
> > > > previous
> > > > > > > > > versions of V8.
> > > > > > > > > On Tue, Mar 8, 2011 at 20:05, Hugo Vincent <
> > > > hugo.vinc...@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > How much slower is full-compiler than nocrankshaft on
> > > > ARM926ej-s -
> > > > > > > > > > anyone have any benchmarks? I'm hesitant to invest time in
> > > > using V8
> > > > > > > > > > for my project if it's going to get substantially slower
> > soon.
> > > > Is
> > > > > > > > > > there any estimated time frame for when nocrankshaft will
> > be
> > > > > > > > > > deprecated?
> > > > > > > > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > > > > > > > There is no interpreter in V8 so you will be using the
> > JIT
> > > > every
> > > > > > > > time,
> > > > > > > > > > > > perfromance should be good (keep in mind CPU like
> > 926-ej-s
> > > > do not
> > > > > > > > have
> > > > > > > > > > L2
> > > > > > > > > > > > cache and this is going to have a visible impact).
> > There is
> > > > a new
> > > > > > > > JIT
> > > > > > > > > > > > infrastructure being developed (crankshaft) which
> > features
> > > > an
> > > > > > > > > > optimising JIT
> > > > > > > > > > > > and this will only be for ARMv7+VFP devices.
> I tried all options. > When i disable sandbox or hack the CPU detection > in OS:::ArmCpuHasFeature and run v8 benchmark, > the browser tab crashes. > I am trying to find the issue.
> > These are interesting experiments, and it would be great to get ot the > > bottom of this.
> > I assume that /proc/cpuinfo contains the strings "ARMv7" and "vfpv3", as > > that is the exact strings which are checked for. You could also try to > run > > chrome with the --no-sandbox option to see whether that makes a > diffrence. > > V8 has a number of options which can be used to trace the optimizations > > performed by crankshaft, try --js-flags="--trace-opt --trace-deopt > > --trace-osr --trace-bailout" for the full monty.
> > If you know that VFPv3 is available you could try to hack the CPU > detection > > in OS:::ArmCpuHasFeature (platform-linux.cc) always return true for VFP3.
> > Regards, > > Søren
> > On Thu, Apr 7, 2011 at 03:25, Arun M <arunm.chr...@gmail.com> wrote: > > > Hi
> > > I ran with --js-flags="--crankshaft" and --js-flags="--nocrankshaft" > > > options. > > > But the V8 scores are nearly same.
> > > V8::DisableCrankshaft() function is called from cpu-arm.cc. > > > I think Chromium is not able to parse /proc/cpuinfo file and get VFPv3 > > > information.
> > > > Have you tried running Chrome with the options Soren mentioned? The > > > result > > > > should tell you if crankshaft is enabled or not.
> > > > Rodolph.
> > > > 2011/4/6 Víctor M. Jáquez L. <vjaq...@igalia.com>
> > > > > On Wed, Apr 06, 2011 at 12:00:27AM -0700, Arun M wrote: > > > > > > Hi Victor
> > > > > > Will this method of detecting VFPv3 work in chromium browser when > > > > > > sandbox is enabled? > > > > > > Will browser sandbox allow to fopen "/proc/cpuinfo" file?
> > > > > Sorry Arun, I don't know. I'm not familiar with chrome in general.
> > > > > vmjl
> > > > > > Arun
> > > > > > On Apr 4, 6:19 pm, Víctor M. Jáquez L. <vjaq...@igalia.com> > wrote: > > > > > > > On Mon, Apr 04, 2011 at 09:45:52AM +0100, Alexandre Rames > wrote: > > > > > > > > Hello Arun,
> > > > > > > > Crankshaft is now enabled by default on ARM processors > supporting > > > > > VFPv3.. > > > > > > > > v8 does not use NEON (it is not worth using, at least > currently), > > > but > > > > > I > > > > > > > > believe no processors with this configuration (NEON without > > > VFPv3) > > > > > exist > > > > > > > > anyway. So if the CPU feature detection work correctly, v8 > should > > > > > assume > > > > > > > > that you have VFPv3 if it detects NEON, and thus use use > > > Crankshaft.
> > > > > > > > If I remember correctly there has been some issues with > incorrect > > > > > feature > > > > > > > > detection. A simple run of the v8 benchmarks with the latest > > > > > bleeding_edge > > > > > > > > and the frequency of your CPU should be enough to determine > if > > > > > crankshaft is > > > > > > > > enabled.
> > > > > > > The CPU features detection is done parsing the /proc/cpuinfo > file:
> > > > > > > > > On Mar 9, 6:02 pm, S�ren Gjesse <sgje...@chromium.org> > > > wrote: > > > > > > > > > > For ARM crankshaft is now the default. This change is in > the > > > > > repository > > > > > > > > > > starting from V8 version 3.2. To use the previous > optimizing > > > > > compiler > > > > > > > > > > --nocrankshaft will have to be used. When crankshaft for > ARM > > > has > > > > > been > > > > > > > > > fully > > > > > > > > > > stabilized the previous optimizing compiler will be > removed > > > from > > > > > the > > > > > > > > > > repository and running with --nocrankshaft will no longer > be > > > > > possible. > > > > > > > > > There > > > > > > > > > > is no specific date to when this will happen but most > likely > > > it > > > > > will be > > > > > > > > > > within a month or two. The removal of the previous > optimizing > > > > > compiler > > > > > > > > > will > > > > > > > > > > happen for all supported platforms simultaneously,
> > > > > > > > > > The previous optimizing compiler can of cause still be > found > > > in > > > > > previous > > > > > > > > > > versions of V8.
> > > > > > > > > > > > > V8 can run on ARMv4 devices (non T though).
> > > > > > > > > > > > > There is no interpreter in V8 so you will be using > the > > > JIT > > > > > every > > > > > > > > > time, > > > > > > > > > > > > > perfromance should be good (keep in mind CPU like > > > 926-ej-s > > > > > do not > > > > > > > > > have > > > > > > > > > > > L2 > > > > > > > > > > > > > cache and this is going to have a visible impact). > > > There is > > > > > a new > > > > > > > > > JIT > > > > > > > > > > > > > infrastructure being developed (crankshaft) which > > > features > > > > > an > > > > > > > > > > > optimising JIT > > > > > > > > > > > > > and this will only be for ARMv7+VFP devices.
> Which platform are you running on? Do you know which CPU? (maybe send your
> /proc/cpuinfo)
> Rodolph.
> On 13 April 2011 06:24, Arun M <arunm.chr...@gmail.com> wrote:
> > Hi
> > I tried all options.
> > When i disable sandbox or hack the CPU detection
> > in OS:::ArmCpuHasFeature and run v8 benchmark,
> > the browser tab crashes.
> > I am trying to find the issue.
> > > These are interesting experiments, and it would be great to get ot the
> > > bottom of this.
> > > I assume that /proc/cpuinfo contains the strings "ARMv7" and "vfpv3", as
> > > that is the exact strings which are checked for. You could also try to
> > run
> > > chrome with the --no-sandbox option to see whether that makes a
> > diffrence.
> > > V8 has a number of options which can be used to trace the optimizations
> > > performed by crankshaft, try --js-flags="--trace-opt --trace-deopt
> > > --trace-osr --trace-bailout" for the full monty.
> > > If you know that VFPv3 is available you could try to hack the CPU
> > detection
> > > in OS:::ArmCpuHasFeature (platform-linux.cc) always return true for VFP3.
> > > Regards,
> > > Søren
> > > On Thu, Apr 7, 2011 at 03:25, Arun M <arunm.chr...@gmail.com> wrote:
> > > > Hi
> > > > I ran with --js-flags="--crankshaft" and --js-flags="--nocrankshaft"
> > > > options.
> > > > But the V8 scores are nearly same.
> > > > V8::DisableCrankshaft() function is called from cpu-arm.cc.
> > > > I think Chromium is not able to parse /proc/cpuinfo file and get VFPv3
> > > > information.
> > > > > Have you tried running Chrome with the options Soren mentioned? The
> > > > result
> > > > > should tell you if crankshaft is enabled or not.
> > > > > Rodolph.
> > > > > 2011/4/6 Víctor M. Jáquez L. <vjaq...@igalia.com>
> > > > > > On Wed, Apr 06, 2011 at 12:00:27AM -0700, Arun M wrote:
> > > > > > > Hi Victor
> > > > > > > Will this method of detecting VFPv3 work in chromium browser when
> > > > > > > sandbox is enabled?
> > > > > > > Will browser sandbox allow to fopen "/proc/cpuinfo" file?
> > > > > > Sorry Arun, I don't know. I'm not familiar with chrome in general.
> > > > > > > > > Crankshaft is now enabled by default on ARM processors
> > supporting
> > > > > > VFPv3..
> > > > > > > > > v8 does not use NEON (it is not worth using, at least
> > currently),
> > > > but
> > > > > > I
> > > > > > > > > believe no processors with this configuration (NEON without
> > > > VFPv3)
> > > > > > exist
> > > > > > > > > anyway. So if the CPU feature detection work correctly, v8
> > should
> > > > > > assume
> > > > > > > > > that you have VFPv3 if it detects NEON, and thus use use
> > > > Crankshaft.
> > > > > > > > > If I remember correctly there has been some issues with
> > incorrect
> > > > > > feature
> > > > > > > > > detection. A simple run of the v8 benchmarks with the latest
> > > > > > bleeding_edge
> > > > > > > > > and the frequency of your CPU should be enough to determine
> > if
> > > > > > crankshaft is
> > > > > > > > > enabled.
> > > > > > > > The CPU features detection is done parsing the /proc/cpuinfo
> > file:
Thank you for the feedback. It is great to hear that you now get the performance benefit of V8 Crankshaft on ARM. We are working on a better way of detecting VFPv3 to correctly enable Crankshaft.
On Wed, Apr 27, 2011 at 11:23, Arun M <arunm.chr...@gmail.com> wrote: > Hi
> I updated the chromium browser version to 12.0.742.0. > V8 score has almost doubled after the hack in OS:::ArmCpuHasFeature.
> Thanks & Regards > Arun
> On Apr 13, 4:46 pm, Rodolph Perfetta <rodolph.perfe...@gmail.com> > wrote: > > Which platform are you running on? Do you know which CPU? (maybe send > your > > /proc/cpuinfo)
> > Rodolph.
> > On 13 April 2011 06:24, Arun M <arunm.chr...@gmail.com> wrote:
> > > Hi
> > > I tried all options. > > > When i disable sandbox or hack the CPU detection > > > in OS:::ArmCpuHasFeature and run v8 benchmark, > > > the browser tab crashes. > > > I am trying to find the issue.
> > > > These are interesting experiments, and it would be great to get ot > the > > > > bottom of this.
> > > > I assume that /proc/cpuinfo contains the strings "ARMv7" and "vfpv3", > as > > > > that is the exact strings which are checked for. You could also try > to > > > run > > > > chrome with the --no-sandbox option to see whether that makes a > > > diffrence. > > > > V8 has a number of options which can be used to trace the > optimizations > > > > performed by crankshaft, try --js-flags="--trace-opt --trace-deopt > > > > --trace-osr --trace-bailout" for the full monty.
> > > > If you know that VFPv3 is available you could try to hack the CPU > > > detection > > > > in OS:::ArmCpuHasFeature (platform-linux.cc) always return true for > VFP3.
> > > > Regards, > > > > Søren
> > > > On Thu, Apr 7, 2011 at 03:25, Arun M <arunm.chr...@gmail.com> wrote: > > > > > Hi
> > > > > I ran with --js-flags="--crankshaft" and > --js-flags="--nocrankshaft" > > > > > options. > > > > > But the V8 scores are nearly same.
> > > > > V8::DisableCrankshaft() function is called from cpu-arm.cc. > > > > > I think Chromium is not able to parse /proc/cpuinfo file and get > VFPv3 > > > > > information.
> > > > > > Have you tried running Chrome with the options Soren mentioned? > The > > > > > result > > > > > > should tell you if crankshaft is enabled or not.
> > > > > > Rodolph.
> > > > > > 2011/4/6 Víctor M. Jáquez L. <vjaq...@igalia.com>
> > > > > > > On Wed, Apr 06, 2011 at 12:00:27AM -0700, Arun M wrote: > > > > > > > > Hi Victor
> > > > > > > > Will this method of detecting VFPv3 work in chromium browser > when > > > > > > > > sandbox is enabled? > > > > > > > > Will browser sandbox allow to fopen "/proc/cpuinfo" file?
> > > > > > > Sorry Arun, I don't know. I'm not familiar with chrome in > general.
> > > > > > > > > > Crankshaft is now enabled by default on ARM processors > > > supporting > > > > > > > VFPv3.. > > > > > > > > > > v8 does not use NEON (it is not worth using, at least > > > currently), > > > > > but > > > > > > > I > > > > > > > > > > believe no processors with this configuration (NEON > without > > > > > VFPv3) > > > > > > > exist > > > > > > > > > > anyway. So if the CPU feature detection work correctly, > v8 > > > should > > > > > > > assume > > > > > > > > > > that you have VFPv3 if it detects NEON, and thus use use > > > > > Crankshaft.
> > > > > > > > > > If I remember correctly there has been some issues with > > > incorrect > > > > > > > feature > > > > > > > > > > detection. A simple run of the v8 benchmarks with the > latest > > > > > > > bleeding_edge > > > > > > > > > > and the frequency of your CPU should be enough to > determine > > > if > > > > > > > crankshaft is > > > > > > > > > > enabled.
> > > > > > > > > The CPU features detection is done parsing the > /proc/cpuinfo > > > file:
