[webkit-dev] New Qt buildbots

2010-04-09 Thread 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


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

2012-10-10 Thread 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 
http://trac.webkit.org/changeset/40761

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


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

2012-10-12 Thread 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 rga...@inf.u-szeged.hu 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

2012-10-15 Thread 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
rga...@inf.u-szeged.hu 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 rga...@inf.u-szeged.hu
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


[webkit-dev] LLINT implementation for ARM traditional

2013-02-20 Thread 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


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

2013-06-26 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


[webkit-dev] LLInt alignment problem on ARM

2013-09-26 Thread 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 llint_begin:
   9:   e30b3eefmovwr3, #48879  ; 0xbeef
   d:   e34b3badmovtr3, #48045  ; 0xbbad
  11:   e583str r0, [r3]
  15:   e3a0mov r0, #0
  19:   e12fff30blx r0

001d llint_program_prologue:
  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] EFL bots for ARM architecture

2014-01-13 Thread 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


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

2014-01-13 Thread 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 
rga...@inf.u-szeged.hu 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