Quantcast

tinyTree synchronized

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

tinyTree synchronized

fforster
I'm using saxon HE 9.5.1-2 to perform XSLT 2.0 transformations. I get namepool contention on 16-CPU boxes, so I created multiple TransformerFactory objects (each gets its own namepool), but I now hit another synchronization point: TinyTree.updateStatistics():

    /**
     * Update the statistics held in static data. We synchronize this, because updates to a double
     * are not atomic: see bug #1844
     */


Is there a way not to update those statistics at all or bypass TinyTree?

I'm using StreamSource input and output.

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tinyTree synchronized

Michael Kay
Presumably this workload is creating a large number of trees and therefore doing a lot of name allocation. I thought we had made considerable progress in reducing NamePool contention as a problem, it would be interesting to know more about this workload pattern to see whether anything can be done.

The introduction of synchronization for the statistics was very recent, as you can tell from the bug entry

https://saxonica.plan.io/issues/1844

so we don't yet have any real experience of the effect.

I guess one thing we could do would be to put the test on convergence outside the synchronized block:

if (treesCreated < 1000000 {
  synchronized (TinyTree.class) {

and we could also make the counters public so you could set the stats manually, and set treesCreated to a high value to prevent the adjustment taking place.

I think there is reasonably good evidence that "learning" a good allocation size to use is beneficial, and I would be reluctant to discard this.

The bug report mentions changes in 9.6 to use different statistics for different tree allocation events; this is intended primarily to give better learning of allocation sizes but it could also reduce contention in some cases. However, the chances are that if you are creating this many new trees, they are all using the same path.

It might be worth us looking at the workload to see why tree creation is so intensive. Perhaps it doesn't need to be. It's an expensive operation. Perhaps you care creating data in temporary trees where sequences or maps would be more effective.

Michael Kay
Saxonica


On 15 Oct 2013, at 05:15, fforster wrote:

> I'm using saxon HE 9.5.1-2 to perform XSLT 2.0 transformations. I get
> namepool contention on 16-CPU boxes, so I created multiple
> TransformerFactory objects (each gets its own namepool), but I now hit
> another synchronization point: TinyTree.updateStatistics():
>
>    /**
>     * Update the statistics held in static data. We synchronize this,
> because updates to a double
>     * are not atomic: see bug #1844
>     */
>
>
> Is there a way not to update those statistics at all or bypass TinyTree?
>
> I'm using StreamSource input and output.
>
>
>
>
>
> --
> View this message in context: http://saxon-xslt-and-xquery-processor.13853.n7.nabble.com/tinyTree-synchronized-tp12355.html
> Sent from the saxon-help mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> saxon-help mailing list archived at http://saxon.markmail.org/
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/saxon-help 


------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
saxon-help mailing list archived at http://saxon.markmail.org/
[hidden email]
https://lists.sourceforge.net/lists/listinfo/saxon-help 
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tinyTree synchronized

fforster
I'm transforming a lot of small XML fragments over and over again, but I happen to do it on a 16-cpu box, which exposes contention I don't see on a 8-cpu box (where I can easily saturate the CPU).

I will try changing my code to transform fewer bigger XML fragments to see if that makes a difference (I believe it should in this case)

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tinyTree synchronized

fforster
Forgot to mention that I think that per-configuration stats is the right long-term approach, as it matches the namepool scaling.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: tinyTree synchronized

fforster
Looks like issues went away when I applied the transform to fewer bigger XML fragments.
Loading...