Comment #19 on issue 1630 by alonza...@gmail.com: Compiled raytrace code is
very slow
http://code.google.com/p/v8/issues/detail?id=1630
@svenpanne: Emscripten has several code generation modes, two with typed
arrays and one without. The one without is slower, but will work in all
browsers
Updates:
Status: Accepted
Owner: fschnei...@chromium.org
Comment #18 on issue 1630 by fschnei...@chromium.org: Compiled raytrace
code is very slow
http://code.google.com/p/v8/issues/detail?id=1630
Thanks for trying this. I can reproduce the slowness even when using the
whole
Comment #17 on issue 1630 by svenpa...@chromium.org: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
I'm just curious what this Array is used for in Emscripten code. If it's
the emulated memory, shouldn't Emscripten use typed arrays? This would be
the
Comment #16 on issue 1630 by alonmozi...@gmail.com: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
In your example the array is only 20% occupied.
If the entire array is used,
var v = Array(52428800);
var da = 52428800;
for (var D = 0; D < da;
Updates:
Status: WorkingAsIntended
Comment #15 on issue 1630 by fschnei...@chromium.org: Compiled raytrace
code is very slow
http://code.google.com/p/v8/issues/detail?id=1630
In your example the array is only 20% occupied. V8 will use a dense
representation if it requires less space
Comment #14 on issue 1630 by weiliang...@gmail.com: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
A small case extracted from fasta.js could reproduce this issue.
var v = Array(52428800);
var da = 10485760;
for (var D = 0; D < da; D++)
{
Comment #13 on issue 1630 by rmk...@gmail.com: Compiled raytrace code is
very slow
http://code.google.com/p/v8/issues/detail?id=1630
I have the some problem, I think there is something wrong with the v8
engine in arithmetic operations.
--
v8-dev mailing list
v8-dev@googlegroups.com
http:/
Comment #12 on issue 1630 by alonmozi...@gmail.com: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
Emscripten can compile code in various modes. One of the modes uses typed
arrays, which is often faster, but has the obvious limitation that it will
no
Comment #11 on issue 1630 by erik.corry: Compiled raytrace code is very slow
http://code.google.com/p/v8/issues/detail?id=1630
Sorry, I misunderstood the direction of your 'separate matter' comment.
Now I understand what you meant.
Modern versions of emscripten use typed arrays wherever pos
Comment #10 on issue 1630 by alonza...@gmail.com: Compiled raytrace code is
very slow
http://code.google.com/p/v8/issues/detail?id=1630
erik.corry and fschneider, I don't follow?
I filed this issue with one benchmark, and later attached another, where v8
is slow. These two benchmarks do no
Comment #9 on issue 1630 by erik.corry: Compiled raytrace code is very slow
http://code.google.com/p/v8/issues/detail?id=1630
Typed arrays are a different matter to typed arrays?
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
Comment #8 on issue 1630 by alonza...@gmail.com: Compiled raytrace code is
very slow
http://code.google.com/p/v8/issues/detail?id=1630
Typed array detection works fine in Chrome as far as I can tell. In the d8
console though there are problems (see issue 1822).
However, typed arrays are a
Comment #7 on issue 1630 by fschnei...@google.com: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
I noticed with a number of emscripten demos that they don't recognize or
use typed arrays when run in Chrome. Therefore we end up using slow arrays
for
Comment #6 on issue 1630 by fschnei...@chromium.org: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
From the profile it looks as if a lot of time is spent in slow-case
property-stores. (v8::internal::Runtime::SetObjectProperty and the function
it cal
Comment #5 on issue 1630 by andrew.s...@gmail.com: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
My student, Justin Pham, has been investigating and has been looking for
typical "bad practices" in emscripten'ed code following the suggestions
outline
Comment #4 on issue 1630 by erik.corry: Compiled raytrace code is very slow
http://code.google.com/p/v8/issues/detail?id=1630
The best direction on where to look is probably this set of slides on
profiling: http://s3.mrale.ph/nodecamp.eu/#1 and the series of articles on
Crankshaft from wing
Comment #3 on issue 1630 by andrew.s...@gmail.com: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
ammo.js (which is Emscripted Bullet Physics ) "workerized" example with
three.js runs much slower in Chrome than in Firefox
link here :
http://strelz1
Comment #2 on issue 1630 by alonmozi...@gmail.com: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
Here is another example of what I think is the same problem, also from the
Emscripten benchmarks, this time Fasta. It looks like this is an issue with
m
Updates:
Owner: jkumme...@chromium.org
Comment #1 on issue 1630 by jkumme...@chromium.org: Compiled raytrace code
is very slow
http://code.google.com/p/v8/issues/detail?id=1630
I'll take a look.
--
v8-dev mailing list
v8-dev@googlegroups.com
http://groups.google.com/group/v8-dev
19 matches
Mail list logo
