Re: [webkit-dev] EFL bots for ARM architecture

[Gabor Rapcsanyi]

Hello Gyuyoung,

Yes, it would be good but now our build master gives different 
environments to the dependency update and the compilation step due to a 
cross-compilation issue. Once we solve this, we can connect them to the 
official master.


Gabor


Hello Gabor,

Thank you so much !  BTW, is there any reason you attach the bots to 
your build master (http://build.webkit.sed.hu) ?

Wouldn't it good to attach them to official WebKit buildbot master ?

Gyuyoung.


On Mon, Jan 13, 2014 at 11:13 PM, Gabor Rapcsanyi 
mailto:rga...@inf.u-szeged.hu>> wrote:


Hello WebKittens,

I would like to annonunce our fresh new EFL Linux bots for ARM
architecture. If you are interested, you can find them at:
http://build.webkit.sed.hu/waterfall

The bots:
 - EFL ARMv7 Linux Release (Build)
 - EFL ARMv7 Traditional Linux Release (Build)

These bots are just builders but we are also planning to support
jscore and layout testing as well later.

Regards,
    Gabor Rapcsanyi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org <mailto:webkit-dev@lists.webkit.org>
https://lists.webkit.org/mailman/listinfo/webkit-dev




___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] EFL bots for ARM architecture

[Gabor Rapcsanyi]

Hello WebKittens,

I would like to annonunce our fresh new EFL Linux bots for ARM 
architecture. If you are interested, you can find them at: 
http://build.webkit.sed.hu/waterfall


The bots:
 - EFL ARMv7 Linux Release (Build)
 - EFL ARMv7 Traditional Linux Release (Build)

These bots are just builders but we are also planning to support jscore 
and layout testing as well later.


Regards,
Gabor Rapcsanyi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] LLInt alignment problem on ARM

[Gabor Rapcsanyi]

Hello!

I'm fighting with a strange LLInt alignment problem on ARM. As I see we 
put the LLInt code into .rodata section instead of .text.
Is there a specific reason why we are doing this? If there is not I 
would put them to the .text section.


Here is the objdump:

./Source/JavaScriptCore/.obj/release-shared/llint/LowLevelInterpreter.o: 
file format elf32-littlearm


Disassembly of section .rodata:

 <_ZStL19piecewise_construct>:
   0:   andeq   r0, r0, r0

0004 <_ZStL13allocator_arg>:
   4:   andeq   r0, r0, r0

0008 <_ZStL6ignore>:
...

0009 :
   9:   e30b3eefmovwr3, #48879  ; 0xbeef
   d:   e34b3badmovtr3, #48045  ; 0xbbad
  11:   e583str r0, [r3]
  15:   e3a0mov r0, #0
  19:   e12fff30blx r0

001d :
  1d:   e1a0200emov r2, lr
  21:   e5852010str r2, [r5, #16]
  25:   e5951008ldr r1, [r5, #8]
...


The problem is that these traditional instructions are lying on odd 
adresses in the .rodata section.


Regards,
  Gabor

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] Baseline JIT, DFG JIT on separate thread

[Gabor Rapcsanyi]

Hello!

As I saw the DFG optimization and compilation are running on the main 
thread in JSC. I'm wondering if there is any known technical issue which 
block the parallelization of this? I would like to investigate this area 
if there is no strong objections to put these to separate thread.

Any comments or ideas would be appreciated.

Regards,
  Gabor Rapcsanyi
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] LLInt without JIT

[Gabor Rapcsanyi]

Hello!

I tried to compile JSC with LLInt CLoop backend and JIT but it didn't 
work for me. I tried it on Mac and Linux as well.

When I looked into it a little I saw some strange guards like this:

Source/JavaScriptCore/llint/LLIntOpcode.h

#if ENABLE(LLINT_C_LOOP)

#define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \
macro(getHostCallReturnValue, 1) \
macro(ctiOpThrowNotCaught, 1)

#else // !ENABLE(LLINT_C_LOOP)

#define FOR_EACH_LLINT_NOJIT_NATIVE_HELPER(macro) \
// Nothing to do here. Use the JIT impl instead.

#endif // !ENABLE(LLINT_C_LOOP)


It seems if we have CLoop we don't have JIT.
So is this configuration supported anyway or we just want to use CLoop 
backend if we don't have JIT support?


Regards,
  -Gabor



Awesome, thanks for the detailed response.

I did not realize that going to the assembly backend would not produce 
a substantial improvement.  But after you explanation, I can see the 
reasons.


I'll do some more testing to see the impact.  If I see it to 
be worthwhile and I can fix it, I'll submit a patch, otherwise a bug.



On Fri, Mar 8, 2013 at 11:28 PM, Filip Pizlo > wrote:


Yes.  You can use the assembly LLInt backend without using the
JIT.  That's how I was running it when I first wrote it.

I think that the code in Platform.h is being conservative, in the
sense that it assumes that if ENABLE(JIT) is not set then you're
compiling for a target that the LLInt wouldn't have a backend for.
 This makes sense, if you think about it: ENABLE_JIT is defined to
1 if we detect that we are on a hardware/OS configuration that the
JIT knows how to handle, and the LLInt has backends for strictly
fewer platforms than the JIT has backends for: JIT supports x86
(32 and 64), ARM (traditional and THUMB2), MIPS, and SH4; while
the LLInt currently only supports x86 (32 and 64), ARM THUMB2, and
MIPS.  In short, requiring the JIT to use LLInt assembly backends
is not a strong requirement of the LLInt; it's just an artifact of
Platform.h's logic.

On hardware/OS configurations where ENABLE(JIT) is set, and the
LLInt is compiled to assembly, it is still possible to run with
the JIT disabled. The JIT ends up being disabled at run-time in
that case. We often use this for testing - you can set the
JSC_useJIT environment variable to 'false' and then you're running
in a LLInt-only mode. This allows for quickly checking if a bug is
due to the JITs, or not.

But I would also note that the purpose of the LLInt assembly
backends is _not_ performance of the LLInt itself, but for
performance of the triple-tier system as a whole.  What those
assembly backends give us is the ability to run the LLInt using
the same ABI that the JSC JITs use; this in turn allows us to do
two things: (1) zero-cost OSR from the LLInt to the baseline JIT,
and (2) perform every JS function call assuming opportunistically
that the callee has been JITed; if it isn't then the machine code
entrypoint that the callee reports is just the shared LLInt
entrypoint.  That entrypoint, in turn, doesn't really have to do
anything special - it just loads the callee from the callee stack
frame, loads the bytecode pointer from the callee, and
indirect-jumps into the first bytecode instruction.  We wouldn't
be able to do either (1) or (2) easily with a C (or C++)
interpreter. I mean, we could do it, but JIT->interpreter calls
would be more expensive (because of the need to set up a C
interpreter stack frame). And OSR would take more effort - it
wouldn't be possible for the LLInt to just jump straight into
JITed code like it does now.

In summary, I don't expect the LLInt cloop backend to be any
slower than the LLInt assembly backends. Last I checked, it wasn't
slower. I would assume that a decent C compiler will take the
LLInt cloop code and do sufficient optimizations that it ends up
generating roughly the same assembly code that the LLInt assembly
backends generate. So, I wouldn't devote too much effort to
switching from the cloop to the assembly backends unless you had
evidence that (a) it would actually be faster on the benchmarks
you care about; or (b) you wanted to take advantage of the LLInt's
ability to rapidly tier-up to one of the JSC JITs. It is because
of (b), not (a), that JSC's triple tier configuration uses the
LLInt assembly backends instead of cloop.

But if you have reason to believe that the LLInt assembly backends
will be better for your purposes then I think all it will take is
hacking Platform.h appropriately. If this turns out to be hard,
then you should file a bug, or even better, I would love to see a
patch from you to improve the logic in Platform.h to make this use
case easier.

Hope this helps!

-Filip



On Mar 8, 2013, at 4:59 PM, Fritz Koenig mail

[webkit-dev] LLINT implementation for ARM traditional

[Gabor Rapcsanyi]

Hello!

I have started to implement LLINT for ARMv5 traditional and ARMv7 
traditional but most of the instructions are identical with the ARMv7 
ones, so I would like to reuse this instead of copy pasting. I think 
that the best way is doing the same what x86.rb does. So I'm planning to 
rename armv7.rb to arm.rb and put some conditional code in it since 
theminor differences.


Any thoughts or comments appreciated.

Regards,
  Gabor
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Transformations precision: double -> float

[Gabor Rapcsanyi]

On 10/12/2012 11:23 AM, Tom Hudson wrote:

Do you have particular bottleneck functions that you have reason to
believe would benefit from ARM SIMD optimizations? Under what
workloads, and how much benefit?

We've see a few ridiculously expensive transform functions in WebKit
that my colleagues in Chapel Hill might be able to recall, but usually
it's the rendering engines that are hot, not WebKit itself.

Yes, you're right that the rendering engine is usually the basic bottleneck,
but why shouldn't we optimize WebKit where it is possible.
For example the function what you asking is 
TransformationMatrix::multiply().
I made a test which could be speed up with optimizing this matrix 
multiplication.

I uploaded here: https://bugs.webkit.org/show_bug.cgi?id=98913

We have seen places where double math appears to be absolutely
required for correctness: matrix inversion and path convexity testing;
there are some other areas we're experimenting with that seem to
require it as well. You'd probably need to survey WebKit for stability
(or just hack in doubles and run layout tests) to see how many other
places will break if you throw away the extra precision.

I tried it in the Qt port and there were just a few (47) layout fails with
0.0 and -0.0 problems and one or two pixel differences. But we need more
investigations here.

The rest of Chromium's renderer (Skia) uses float, and we've deployed
SSE/NEON and played with float vs double quite a bit there. The
float->double conversion at the WebKit/Skia boundary doesn't seem to
be too much of a drag, but doing it in any sort of inner loop can
really kill performance.

Meanwhile, there are a lot of places where switching from ARM assembly
to NEON in the renderer hasn't given us as much win as we'd hoped for,
which is why the question "how much benefit?" seems important to
answer before spending too much time polishing a set of typedefs.

Tom

I can say the same as above. If there is a way to optimize WebKit,
but the benefit is just a half or one percent on an avrage page now
or maybe less, why shouldn't we do that, and of course on a specific
page/case we would benefit more.

-Gabor



On Fri, Oct 12, 2012 at 10:08 AM, Gabor Rapcsanyi
 wrote:

Yes I agree that we need to do some measures to see the benefits of floats.
But it's not just about the performance and memory gain of the floats, I
would like to make ARM SIMD optimizations for the transformation functions
to fasten up them, but ARM NEON technology only works with floats that's why
I want to change the doubles.
I would prefer a typedef solution to make this configurable as Ryosuke said,
and then the ports could chose whether they need floats, doubles or long
doubles.

- Gabor


On Oct 10, 2012, at 9:00 AM, Gabor Rapcsanyi 
wrote:


That was a long time ago and there were no objections

Unless there's something in the spec requiring double precision it makes
sense to move away from double precision throughout WebKit.

I’m a little concerned about this.

The programming interface to the graphics system on OS X uses doubles, so
it’s likely we’ll be introducing float to double conversions for at least
that platform if we change things inside WebKit that are currently doubles
to float en masse.

Similarly, the native data type for numbers in JavaScript is double. So
any time we are passing a number from JavaScript to WebKit it’s likely that
additional double to float conversions will be required as we change
internals to use doubles instead of floats.

On the other hand, there may also be performance boost or memory gains
from using float instead of double.

If we do make this change, I think we need to do performance testing as we
do so, perhaps on more than one platform, to see if these changes are
leading to benefits or not.

I also think that “we should always use float unless a spec mandates
double” is probably not the right rule of thumb. There are many factors
other than “a spec” at play here.

-- Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Transformations precision: double -> float

[Gabor Rapcsanyi]

Yes I agree that we need to do some measures to see the benefits of floats.
But it's not just about the performance and memory gain of the floats, I 
would like to make ARM SIMD optimizations for the transformation 
functions to fasten up them, but ARM NEON technology only works with 
floats that's why I want to change the doubles.
I would prefer a typedef solution to make this configurable as Ryosuke 
said, and then the ports could chose whether they need floats, doubles 
or long doubles.


- Gabor

On Oct 10, 2012, at 9:00 AM, Gabor Rapcsanyi  wrote:


That was a long time ago and there were no objections

Unless there's something in the spec requiring double precision it makes sense 
to move away from double precision throughout WebKit.

I’m a little concerned about this.

The programming interface to the graphics system on OS X uses doubles, so it’s 
likely we’ll be introducing float to double conversions for at least that 
platform if we change things inside WebKit that are currently doubles to float 
en masse.

Similarly, the native data type for numbers in JavaScript is double. So any 
time we are passing a number from JavaScript to WebKit it’s likely that 
additional double to float conversions will be required as we change internals 
to use doubles instead of floats.

On the other hand, there may also be performance boost or memory gains from 
using float instead of double.

If we do make this change, I think we need to do performance testing as we do 
so, perhaps on more than one platform, to see if these changes are leading to 
benefits or not.

I also think that “we should always use float unless a spec mandates double” is 
probably not the right rule of thumb. There are many factors other than “a 
spec” at play here.

-- Darin


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

Re: [webkit-dev] Transformations precision: double -> float

[Gabor Rapcsanyi]

Hello!

That was a long time ago and there were no objections so I made a bug 
for the further discussions and patches:

https://bugs.webkit.org/show_bug.cgi?id=98913

Regards,
  Gabor


What CPU executes single precision floating point values at the same speed as 
double precision?

Here's a benchmark from NASA giving a comparison of single vs. double precision 
performance for one of their simulations. 
https://modelingguru.nasa.gov/docs/DOC-1664.

Single precision maps better to GPU backends, and CPU's SIMD computations than 
double. Unless there's something in the spec requiring double precision it 
makes sense to move away from double precision throughout WebKit.

It's fairly trivial to make SIMD types that can have CPU architecture specific 
implementations. As an example of how to do this in the wild there's the Sony 
vectormath library that's present in the Bullet Physics Library.
http://bullet.svn.sourceforge.net/viewvc/bullet/trunk/Extras/vectormathlibrary/include/vectormath/.

As Kui noted the TransformationMatrix is a hotspot that could be helped by 
SIMD. Making the solution generic enough to target multiple architectures using 
SIMD should help the performance on all the platforms.

Don

-Original Message-
From: webkit-dev-boun...@lists.webkit.org 
[mailto:webkit-dev-boun...@lists.webkit.org] On Behalf Of Simon Fraser
Sent: Monday, May 21, 2012 10:35 AM
To: Zoltan Herczeg
Cc: webkit-dev@lists.webkit.org
Subject: Re: [webkit-dev] Transformations precision: double -> float

TransformationMatrix started out as floats, then got changed to doubles in 


This was done because on most hardware there is no penalty for using doubles 
over floats, and provided a better match with our system APIs that used doubles.

I'd prefer to take a forward-looking stance here, and assume that in time 
hardware will catch up.

Simon

On May 21, 2012, at 4:04 AM, Zoltan Herczeg wrote:


Hi,

is there any reason why the transformations in WebKit use doubles? We
could optimize some functions further with ARM SIMD if they would be
floats. Is there any objection to make them float if the change would
have no other side effects except some rounding because of the lower precision?

Regards,
Zoltan


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev


___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo/webkit-dev

[webkit-dev] New Qt buildbots

[Gabor Rapcsanyi]

Hi!
We have some stable Qt bots on http://www.sed.hu/webkit/qtbuildbot/ 
which we would like to connect to the Apple buildbot master.


The bot names are:
x86-32 Windows Qt Release   - QtWebKit release build on x86-32 
architecture
x86-32 Windows Qt Debug - QtWebKit debug build on x86-32 
architecture
x86-32 Linux Qt Release Minimal - QtWebKit release build with --minimal 
switch
ARMv7 Linux Qt Release  - QtWebKit release build on ARMv7 
architecture
ARMv5 Linux Qt Release  - QtWebKit release build on ARMv5 
architecture


These bots are stable and only build now, doesn't do any tests yet.
If you have any question about the bots we can discuss here.

Regards,
Gabor

___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev