Subject: [FEniCS-users] Assembly time of the latest Dolfin

From: Murtazo Nazarov <[email-masked]>
Date: Sun, 08 Nov 2009 01:53:53 +0100

Hi,

I am updating Unicorn against the fenics tip. But, I see some strange 
timing in the assembly loop. With Dolfin 0.7.1 the assembly time of the 
compressible Euler equations using cG(1)cG(1) method took 0.36 sec and 
Krylov solver took 0.11 sec, but with the latest Dolfin the assembly 
time is 1.73 sec, Krylov solver 0.1 sec.

In my code I check the timing as the following:

      // Assemble compressible vector                  
      info("Assemble vector: compressible");       
      tic();                                           
      assemble(A, *a, false);            
      assemble(b, *L, false);            
      info("Assemble took %g seconds",toc());

....

      // Solve the linear 
system                                                                                  

      info("Solve linear system: compressible");
      tic();
      solver.solve(A, w.vector(), b);
      info("Linear solve took %g seconds",toc());

Is something changed in the assembly loop in the latest Dolfin? Or am I 
missing to put some option? I installed the latest Fenics using Dorsal.

Regards,
Murtazo

---

From: Anders Logg <[email-masked]>
Date: Mon, 9 Nov 2009 13:38:12 +0100

Try compiling the forms first with the option

 -f tensor

and time the assembly again.

Then also try

 -O

and time the assembly again.

Does that make a difference?

--
Anders

On Sun, Nov 08, 2009 at 01:53:53AM +0100, Murtazo Nazarov wrote:
> _______________________________________________
> FEniCS-users mailing list
> [email-masked]
> http://fenics.org/mailman/listinfo/fenics-users

---

From: Murtazo Nazarov <[email-masked]>
Date: Mon, 09 Nov 2009 15:47:53 +0100

> Try compiling the forms first with the option

Did not help.

> and time the assembly again.

That helped. Now for 200x200 mesh in 2D the profiling is:
Assemble took 1.9 seconds
Linear solve took 0.46 seconds

400x400 mesh:
Assemble took 7.62 seconds
Linear solve took 1.43 seconds

Which is pretty close to the old result:
200x200 mesh:
Assemble took 1.42 seconds
Linear solve took 0.47 seconds

400x400 mesh:
Assemble took 5.66 seconds
Linear solve took 2.06 seconds

It seems for 400x400 mesh we are loosing 2sec in each assembly.

murtazo

---

From: Anders Logg <[email-masked]>
Date: Mon, 9 Nov 2009 17:45:31 +0100

> It seems for 400x400 mesh we are loosing 2sec in each assembly.

I've also noticed that assembly is slower than it used to be.

We (Ola and I) have just bought a new machine that we, aka Johannes
:-), will set up as a dedicated benchbot to run benchmarks nightly to
track regressions like this one.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 09 Nov 2009 16:51:31 +0000

> track regressions like this one.

Two issues spring to mind:

1. The check on the local dimension for each cell.

2. The new Function design that checks the mesh on which a Function is 
defined. The checks inside Function for every eval call don't sit well 
with me. This would impact the assembly time for the advection term in 
the NS eqns.

I've been wondering for some time if it's possible to create very 
general assembler that is efficient. My suspicion is that it's not.

Garth

>> ------------------------------------------------------------------------
>>

---

From: Anders Logg <[email-masked]>
Date: Mon, 9 Nov 2009 18:07:02 +0100

On Mon, Nov 09, 2009 at 04:51:31PM +0000, Garth N. Wells wrote:
> 2. The new Function design that checks the mesh on which a Function
> is defined. The checks inside Function for every eval call don't sit
> well with me. This would impact the assembly time for the advection
> term in the NS eqns.

We could collect most of the checking and do it before assembly.

Then there's also the matter of the dofmap of variable local dimension
that was recently introduced.

> general assembler that is efficient. My suspicion is that it's not.

I think it is possible. We just haven't put very much focus on making
the assembly truly efficient (as in profiling). We have put quite a
bit of focus on making the components (like computing the element
tensor) efficient, but assembly can be much improved.

--
Anders

---

From: "Garth N. Wells" <[email-masked]>
Date: Mon, 09 Nov 2009 17:10:10 +0000

> We could collect most of the checking and do it before assembly.

Yes, we need to think about how to do this. Perhaps sooner rather than 
later before the Function internals are consolidated and we forget about it.

> that was recently introduced.

That's Point 1 above.

Garth

---

From: Anders Logg <[email-masked]>
Date: Mon, 9 Nov 2009 22:27:49 +0100

On Mon, Nov 09, 2009 at 05:10:10PM +0000, Garth N. Wells wrote:
> Yes, we need to think about how to do this. Perhaps sooner rather
> than later before the Function internals are consolidated and we
> forget about it.

If we can get the benchbot up and running soon, that should put some
more focus on this issue. In particular if we can "backport" some
benchmarks to add some historic values to the graph.

Ola and Johannes, what is the status on the benchbot?

--
Anders

---

From: Johannes Ring <[email-masked]>
Date: Tue, 10 Nov 2009 08:16:19 +0100

> Ola and Johannes, what is the status on the benchbot?

I am not sure if it is running yet. I will ask drift.

Johannes

---

From: Ola Skavhaug <[email-masked]>
Date: Tue, 10 Nov 2009 08:49:17 +0100

> I am not sure if it is running yet. I will ask drift.

I think the responsible at drift is at a conference, so probably we
will not be able to get it up running until he gets back.

Ola

-- 
Ola Skavhaug