> 2. 7. 2018 v 15:50, Matthew Knepley <[email protected]>: > > On Mon, Jul 2, 2018 at 8:28 AM Vaclav Hapla <[email protected] > <mailto:[email protected]>> wrote: >> 2. 7. 2018 v 15:05, Matthew Knepley <[email protected] >> <mailto:[email protected]>>: >> >> On Mon, Jul 2, 2018 at 7:54 AM Vaclav Hapla <[email protected] >> <mailto:[email protected]>> wrote: >> >> >>> 2. 7. 2018 v 14:48, Matthew Knepley <[email protected] >>> <mailto:[email protected]>>: >>> >>> On Mon, Jul 2, 2018 at 3:48 AM Vaclav Hapla <[email protected] >>> <mailto:[email protected]>> wrote: >>> Barry wrote: >>>> This could get ugly real fast, for example, for vector operations, there >>>> may be dozens of named vectors and each one gets its own logging? You'd >>>> have to make sure that only the objects you care about get named, is that >>>> possible? >>>> >>>> I don't know if there is a good solution within the PETSc logging >>>> infrastructure to get what you want but maybe what you propose is the best >>>> possible. >>> >>> As I suggest, this behavior would be only triggered by a specific option. >>> >>> I think there are actually 4 strings which could be used as an event name >>> suffix in log view: >>> 1) name >>> 2) prefix >>> 3) type >>> 4) custom string (set by something like PetscObjectSetLogViewSuffix) >>> I think the best would be to let user choose by offering >>> -log_view_by_{name,prefix,type,suffix}. >>> >>> For example, with -log_view_by_prefix, you could readily distinguish >>> PCTelescope outer and inner apply, because you would see a separate >>> "PCApply (telescope_)" event. >>> With -log_view_by_type, you would see PCApply (telescope). >>> >>> I think this would be useful because the current class-wide events like >>> MatMult or PCApply aggregate very different operations from which some are >>> for free and some form hotspots. >>> >>> >>> Stefano wrote: >>>> The issue with this sort of “dynamic” logging is that now PETSc requires >>>> PetscLogEvent created during the registration of the class, so that all >>>> the ranks in PETSC_COMM_WORLD have the same events registered. >>>> What you propose is not generally supported for this specific reason. >>>> >>>> Your “log_name” may work if users register their own classes (with their >>>> own LogEvents created properly), and currently we don’t have support >>>> (maybe I’m wrong) to add an “InitializePackage” method for the users’ >>>> registered classes. >>> >>> >>> I don't agree. What I suggest is basically an ability to allow >>> automatically created object-wise events, so it _can't_ be managed during >>> the class registration. In presence of respective option, the event would >>> be created during PetscLogEventBegin by taking the class-wide event's name, >>> concatenating the suffix and registering a new event. The event id would be >>> stored in the PetscObject structure. >>> >>> >>> Matt wrote: >>>> As people have pointed out, this would not work well for Events. However, >>>> this is exactly what stages are for. >>>> Use separate stages for the different types of MatMult. I did this, for >>>> example, when looking at performance >>>> on different MG levels. >>> >>> Yes, performance on different MG levels is a nice use case. I don't >>> understand how you inject stages into MatMults. To me it's exactly the same >>> problem as with events - you have to define MatMult_custom where you take >>> the original mult and wrap into PetscStageLogPush/Pop and then use >>> MatSetOperation to redefine MatMult. Or do you mean something more elegant? >>> >>> You could do that, but usually I think of stages as being structural. I >>> think for your example I would push/pop the stage >>> inside your Mat operation wrapper (I don't see why you need another one), >>> and this behavior could be controlled with >>> another option so you could turn it off. >> >> I meant hierarchies of typically Mats or PCs, where you don't define any >> custom operations but compose together existing types (which should be >> promoted I believe). So no "my" wrapper. As I wrote below: >> >>>>> Think e.g. of having additive MATCOMPOSITE wrapping multiplicative >>>>> MATCOMPOSITE wrapping MATTRANSPOSE wrapping MATAIJ. You want to measure >>>>> this MATAIJ instance's MatMult separately but you surely don't want to >>>>> rewrite implementation of MatMult_Transpose or force yourself to use >>>>> MATSHELL just to hang the events on MatMult*. >> >> >> Its not enough to make separate stages for additive MC, multiplicative MC, >> and MT? If you want stages for every single >> combination created dynamically, you can push another stage when each of >> these combinations is created using GetTag() >> or something like that. You could switch between these behaviors with an >> option. > > I'm not sure I understand. Do you mean registering and pushing/popping these > stages in the user's code? You can surely call PetscStageLogRegister > somewhere after PetscInitialize, but where do you place your > PetscStageLogPush/Pop calls? > > No. You would create a stage when the MATCOMPOSITE is created (or once when > any MATCOMPOSITE is created), and push/pop > on application.
There's surely no problem with creating that stage. But still I don't see how can you push/pop on specific MatMult if it's aggregated together with another MatMults in a higher level MatMult without redefining the latter? And there can be arbitrary number of such levels. If you push/pop your stage in the code calling the top-level MatMult, you can't distinguish different MatMults occurring inside. And I don't understand what's in this context the advantage of using stages (which are typically registered by user and from his perspective they are generally spanning multiple different operations/function calls) against events which are precisely meant for single operations/function calls (at least I hope so based on thousands of use cases in PETSc itself). You want me to create a stage which is shorter than then the wrapping event which is I think much uglier than what I propose :-) Vaclav > > Matt > > Thanks > > Vaclav > >> >> The reason I think this is preferable is that we do not mess with any >> logging infrastructure, we just use stages inside of other objects. >> >> Thanks, >> >> Matt >> >> Thanks >> >> Vaclav >> >> >>> >>> Matt >>> >>> Thanks >>> >>> Vaclav >>> >>> >>> >>>> 29. 6. 2018 v 22:42, Smith, Barry F. <[email protected] >>>> <mailto:[email protected]>>: >>>> >>>> >>>> >>>>> On Jun 29, 2018, at 9:33 AM, Vaclav Hapla <[email protected] >>>>> <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> >>>>>> 22. 6. 2018 v 17:47, Smith, Barry F. <[email protected] >>>>>> <mailto:[email protected]>>: >>>>>> >>>>>> >>>>>> >>>>>>> On Jun 22, 2018, at 5:43 AM, Pierre Jolivet <[email protected] >>>>>>> <mailto:[email protected]>> wrote: >>>>>>> >>>>>>> Hello, >>>>>>> I’m solving a system using a MATSHELL and PCGAMG. >>>>>>> The MPIAIJ Mat I’m giving to GAMG has a specific structure (inherited >>>>>>> from the MATSHELL) I’d like to exploit during the solution phase when >>>>>>> the smoother on the finest level is doing MatMults. >>>>>>> >>>>>>> Is there some way to: >>>>>>> 1) decouple in -log_view the time spent in the MATSHELL MatMult and in >>>>>>> the smoothers MatMult >>>>>> >>>>>> You can register a new event and then inside your MATSHELL MatMult() >>>>>> call PetscLogEventBegin/End on your new event. >>>>>> >>>>>> Note that the MatMult() like will still contain the time for your >>>>>> MatShell mult so you will need to subtract it off to get the time for >>>>>> your non-shell matmults. >>>>> >>>>> In PERMON, we sometimes have quite complicated hierarchy of wrapped >>>>> matrices and want to measure MatMult{,Transpose,Add,TransposeAdd} >>>>> separately for particular ones. Think e.g. of having additive >>>>> MATCOMPOSITE wrapping multiplicative MATCOMPOSITE wrapping MATTRANSPOSE >>>>> wrapping MATAIJ. You want to measure this MATAIJ instance's MatMult >>>>> separately but you surely don't want to rewrite implementation of >>>>> MatMult_Transpose or force yourself to use MATSHELL just to hang the >>>>> events on MatMult*. >>>>> >>>>> We had a special wrapper type just adding some prefix to the events for >>>>> the given object but this is not nice. What about adding a functionality >>>>> to PetscLogEventBegin/End that would distinguish based on the first >>>>> PetscObject's name or option prefix? Of course optionally not to break >>>>> guys relying on current behavior - e.g. under something like >>>>> -log_view_by_name. To me it's quite an elegant solution working for any >>>>> PetscObject and any event. >>>> >>>> This could get ugly real fast, for example, for vector operations, there >>>> may be dozens of named vectors and each one gets its own logging? You'd >>>> have to make sure that only the objects you care about get named, is that >>>> possible? >>>> >>>> I don't know if there is a good solution within the PETSc logging >>>> infrastructure to get what you want but maybe what you propose is the best >>>> possible. >>>> >>>> Barry >>>> >>>>> >>>>> I can do that if I get some upvotes. >>>>> >>>>> Vaclav >>>>> >>>>>> >>>>>>> 2) hardwire a specific MatMult implementation for the smoother on the >>>>>>> finest level >>>>>> >>>>>> In the latest release you do MatSetOperation() to override the normal >>>>>> matrix vector product with anything else you want. >>>>>> >>>>>>> >>>>>>> Thanks in advance, >>>>>>> Pierre >>>>>>> >>>>>>> PS : here is what I have right now, >>>>>>> MatMult 118 1.0 1.0740e+02 1.6 1.04e+13 1.6 1.7e+06 >>>>>>> 6.1e+05 0.0e+00 47100 90 98 0 47100 90 98 0 81953703 >>>>>>> […] >>>>>>> PCSetUp 2 1.0 8.6513e+00 1.0 1.01e+09 1.7 2.6e+05 >>>>>>> 4.0e+05 1.8e+02 5 0 14 10 66 5 0 14 10 68 94598 >>>>>>> PCApply 14 1.0 8.0373e+01 1.1 9.06e+12 1.6 1.3e+06 >>>>>>> 6.0e+05 2.1e+01 45 87 72 78 8 45 87 72 78 8 95365211 // I’m guessing >>>>>>> a lot of time here is being wasted in doing inefficient MatMults on the >>>>>>> finest level but this is only speculation >>>>>>> >>>>>>> Same code with -pc_type none -ksp_max_it 13, >>>>>>> MatMult 14 1.0 1.2936e+01 1.7 1.35e+12 1.6 2.0e+05 >>>>>>> 6.1e+05 0.0e+00 15100 78 93 0 15100 78 93 0 88202079 >>>>>>> >>>>>>> The grid itself is rather simple (two levels, extremely aggressive >>>>>>> coarsening), >>>>>>> type is MULTIPLICATIVE, levels=2 cycles=v >>>>>>> KSP Object: (mg_coarse_) 1024 MPI processes >>>>>>> linear system matrix = precond matrix: >>>>>>> Mat Object: 1024 MPI processes >>>>>>> type: mpiaij >>>>>>> rows=775, cols=775 >>>>>>> total: nonzeros=1793, allocated nonzeros=1793 >>>>>>> >>>>>>> linear system matrix followed by preconditioner matrix: >>>>>>> Mat Object: 1024 MPI processes >>>>>>> type: shell >>>>>>> rows=1369307136, cols=1369307136 >>>>>>> Mat Object: 1024 MPI processes >>>>>>> type: mpiaij >>>>>>> rows=1369307136, cols=1369307136 >>>>>>> total: nonzeros=19896719360, allocated nonzeros=19896719360 >>> >>> >>> >>> -- >>> What most experimenters take for granted before they begin their >>> experiments is infinitely more interesting than any results to which their >>> experiments lead. >>> -- Norbert Wiener >>> >>> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> >> >> >> >> -- >> What most experimenters take for granted before they begin their experiments >> is infinitely more interesting than any results to which their experiments >> lead. >> -- Norbert Wiener >> >> https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/> > > > -- > What most experimenters take for granted before they begin their experiments > is infinitely more interesting than any results to which their experiments > lead. > -- Norbert Wiener > > https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>
