Susanne Fuchs

Pascal Perrier
email: pascal.perrier@gipsa-lab.grenoble-inp.fr

Mariam Hartinger

A critical

Introduction

The modeling of the dynamics of vocal tract articulators by means of a linear second order model (henceforth LSOM) has been very useful in understanding and characterizing some general aspects of speech production. For instance, vowel deletion in fast speech could be predicted by introducing the hypothesis of gestural overlap (Browman & Goldstein, 1990a), which involves competition between second-order dynamical attractors. The relation between articulators' dynamics and gesture durations has been investigated from the perspective of the relations between stiffness and oscillation frequency in the context of an LSOM [START_REF] Ostry | Control of rate and duration of speech movements[END_REF][START_REF] Kelso | A qualitative dynamical analysis of reiterant speech production: Phase portraits, kinematics and dynamic modeling[END_REF]. It could be shown that within a gesture, peak velocity V max , movement amplitude Amp, and duration T cannot be treated as independent variables.

Because of these and other ambitious studies in this framework (e.g. [START_REF] Saltzman | Task dynamic coordination of the speech articulators: A preliminary model[END_REF][START_REF] Saltzman | A dynamical approach to gestural patterning in speech production[END_REF], the LSOM has become very popular in speech production research. However, the model has not only been used to describe general aspects of speech production. It has also been used as a tool to quantitatively infer physical characteristics of articulators, such as stiffness, from speech kinematics. Based on such an approach [START_REF] Kelso | A qualitative dynamical analysis of reiterant speech production: Phase portraits, kinematics and dynamic modeling[END_REF] proposed that stiffness and rest position are the key control parameters for speech production and determine speech rate variations. [START_REF] Ackermann | Kinematic analysis of lower lip movements in ataxic dysarthria[END_REF] suggest that stiffness can be a key parameter to differentiate speech motor control between populations with different speech disorders. More recently, [START_REF] Perkell | Economy of effort in different speaking conditions. I. A preliminary study of intersubject differences and modeling issues[END_REF] measured stiffness based on undamped LSOM properties and discussed their results in the context of economy of effort in speech production. [START_REF] Kühnert | Speaker specific kinematic properties of alveolar reductions in English and German[END_REF] relate alveolar and velar articulatory reductions with respect to stiffness in the context of an undamped model. Similarly, in van [START_REF] Van Lieshout | Speech motor control in fluent and dysfluent speech production of an individual with apraxia of speech and Broca's aphasia[END_REF] stiffness was analyzed to account for control mechanisms in apraxia of speech. [START_REF] Xu | Organizing syllables into groups -Evidence from F 0 and duration patterns in Mandarin[END_REF] also proposed using the properties of a damped model to estimate stiffness with respect to the timing of f0 modulations in Mandarin Chinese. However, there is growing evidence that stiffness cannot be seen solely in the framework of an LSOM, but is physical in nature and therefore crucially dependent on biomechanics, muscular forces, and cocontraction, among other factors (e.g. [START_REF] Shiller | Voluntary control of human jaw stiffness[END_REF][START_REF] Gomi | Compensatory articulation during bilabial fricative production by regulating muscle stiffness[END_REF].

In the context of a linear second-order model, articulatory stiffness is computed based on the assumption (see Appendix) that the ratio V max /Amp is proportional to the square root of the mass-normalized stiffness K/m:

ౣ౮ ୫୮ ൌ α. ට ܭ ݉ ൗ (1)
In addition, articulatory stiffness can also be calculated based on the assumption (see Appendix) that the mass-normalized stiffness K/m is proportional to the duration T of the gesture:

ට ܭ ݉ ൗ ൌ β T ൗ (2)
This approach is implicitly based on three assumptions. However, in this case the influence of damping on peak velocity and gesture duration would be at least as strong as the influence of stiffness. Assumption (b) is only true if the system is undamped or if the same relation between damping and stiffness is found in all gestures (see Appendix). These two conditions are far from being realistic. First, the vocal tract is such a narrow space that during the course of their displacements, speech articulators are likely to be in contact with various structures (e.g., contact of the tongue with the teeth or the palate).

Hence, damping clearly exists due to interaction of the tongue with vocal tract structures and it is likely to vary across gestures as well as over the course of a gesture. Second, the mechanical properties of vocal tract articulators are very different. Tongue, lips, and velum are soft bodies while the jaw is a rigid body. Hence the nature of the damping is not the same for all these articulators. Assumption (c) may not hold true since damping can vary along the course of the articulator's displacement. The same holds true for stiffness. Oro-facial muscles and, more generally, human soft tissue have been shown to have non-linear passive elastic properties for which stiffness (Young Modulus) increases with strain [START_REF] Fung | Biomechanics, mechanical properties of living tissues[END_REF][START_REF] Gerard | Non-linear elastic properties of the lingual and facial tissues assessed by indentation technique: Application to the biomechanics of speech production[END_REF]. Moreover, stiffness increases with the level of muscular activity [START_REF] Mcmahon | Muscles, reflexes and locomotion[END_REF].

Assumption (c) also implies that the control parameters of the LSOM (stiffness and rest position) are set up instantaneously at the beginning of each gesture, without any transition period. Instantaneous changes are indeed non-physiological. Hence, in spite of its strengths in globally describing important trends of speech gestures, the LSOM remains a rough approximation of the physical characteristics of articulatory gestures.

Some of these limitations have already been acknowledged in previous studies. For example, [START_REF] Browman | Dynamic modeling of phonetic structure[END_REF] consider the problem raised by the existence of articulatory plateaus. They realize that plateaus cannot be accounted for without considering a specific time variation in the damping. [START_REF] Browman | Gestural specification using dynamically-defined articulatory structures[END_REF] also insist on the necessity of properly evaluating the damping for each gesture, and they agree with proposals made in the literature that the control parameters of the model should not vary as a step function. [START_REF] Kelso | A qualitative dynamical analysis of reiterant speech production: Phase portraits, kinematics and dynamic modeling[END_REF] address the fact that stiffness varies as a function of strain. They propose an alternative way to measure stiffness in the context of an undamped model.

The aim of the current study is to assess how reliably gestural stiffness can be inferred from articulatory amplitude and velocity or gestural duration as proposed by the LSOM.

Method

Articulatory data for various consonants, speakers and speaking rates were used to evaluate gestural stiffness in the context of the LSOM. This assessment was carried out first using an undamped linear second-order model and then using a damped LSOM.

Corpus

Subjects were asked to produce reiterant speech first at an increasing and then at a decreasing speaking rate over a time interval of 16 seconds, following an experimental scenario proposed by [START_REF] Rochet-Capellan | An articulatory basis for the labial-to-coronal effect: /pata/ seems a more stable articulatory pattern than /tapa[END_REF]. The corpus consisted of repetitions of bisyllabic CVCV words chosen from among /fata/, /kata/, /kapa/, /kaЀa/, /pasa/, /paЀa/, /pata/, /paka/, /sapa/, /Ѐapa/, /Ѐaka/, /tafa/, /tapa/ and /taka/. The variety of consonants and articulators involved and the different speech rates allowed us to evaluate the reliability of the LSOM in stiffness estimation. Movements were recorded by electromagnetic articulography (Carstens, AG 100). Three sensors were glued on the tongue at around 1 cm, 3 cm and 5 cm from the tongue tip. Lower lip and jaw movements were measured using sensors glued at the vermillion border and just below the lower incisors. Reference sensors glued on the upper incisors and on the bridge of the nose were used to compensate for head movements in the helmet. A bite plane served as a reference to determine the vertical and horizontal coordinates of each individual vocal tract. The contribution of the jaw was not subtracted from tongue and lower lip movements, since this decomposition is not straightforward.

Movements were sampled at 200 Hz. Movements and velocities were filtered with an 18 Hz and a 15 Hz low-pass Kaiser filter, respectively.

Nine speakers of German were recorded, 5 females (sp1 to sp5) and 4 males (sp6 to sp9).

They had no reported history of speech, language or hearing impairment. All procedures were in agreement with our institutional regulations. All subjects provided informed consent prior to testing. Subjects were between 30 and 42 years old, except sp7, who was 68 years old. Sp7

was included in the corpus because he is an ultra-fast speaker who has won several competitions for his fast and precise speech in the mass media [START_REF] Jannedy | Articulation beyond the usual: Evaluating the fastest German speaker under laboratory conditions[END_REF]. We expected that this speaker might use different articulatory strategies than the other subjects.

The speaking pace was given by a visual metronome (see Rochet-Capellan & Schwartz 2007) consisting of successively varying black and white images displayed on a computer screen. Their frequency of change varied between 3.3 and 20 Hz. Sp7, however, was free to choose the pace range according to his specific skills.

Measures

Closing and opening gestures were analyzed in the present study. They were labeled on the tangential velocity signal using the velocity minimum of the movements toward and from the consonants. To keep the amount of data at a reasonable level for each consonant, only the articulators that are known to be crucial for the production of a given consonant were considered. Tongue tip and jaw movements were analyzed for /t, s/, tongue dorsum and jaw movements for /Ѐ/, tongue back movements for /k/, and lower lip and jaw movements for /p, f/. Within each of the segmented gestures and for each of the crucial articulators, movement amplitude Amp, velocity peak V max and gesture duration T were measured. Movement amplitude was computed as the length of the articulatory path by computing the cumulative Euclidian distances from one sample to the next.

Stiffness estimation in the context of an undamped linear second-order model

In an undamped LSOM, equations ( 1) and ( 2), computed respectively with α=0.5 and β=π (see Appendix), are theoretically two strictly equivalent ways to compute the massnormalized stiffness k. Equation ( 1) is based on kinematic measures, and equation (2) on temporal measures.

Undamped LSOMs have essentially been used in speech production studies to evaluate differences in stiffness between two gestures, and not to consider absolute stiffness values.

For example, a stiffness increase from one gesture to another could be interpreted as an increase in articulatory effort [START_REF] Perkell | Economy of effort in different speaking conditions. I. A preliminary study of intersubject differences and modeling issues[END_REF]. Consequently our study focused on stiffness differences between gestures. The following procedure was carried out: For a given speaker and a given condition (split by word, syllable, consonant and articulator) all possible combinations of two gestures were selected and grouped in pairs. For each pair the stiffness difference was computed, once on the basis of equation 1 and once on the basis of equation 2.

All cases were considered as misleading (errors) where differences in stiffness showed a positive (or negative) sign on the basis of one equation and a negative (or positive) sign on the basis of the other. The percentage of gesture pairs for which such opposite estimations (henceforth OpposEstim) were found was taken as a measure of the inadequacy of an undamped LSOM to calculate stiffness. Whenever differences in stiffness showed the same sign, either positive or negative, the model was considered to be adequate.

In order to be as conservative as possible, only the following cases were selected: Since movement data were sampled at 200 Hz, a maximal potential inaccuracy of 5 ms exists in the time labeling. Hence, only gestures with a temporal difference longer than 5 ms were taken into account. OpposEstim was computed only for pairs in which stiffness differences could not be attributed to measurement inaccuracies. In line with classical principles used for measurement techniques in physics, only cases where stiffness differences correspond to a minimum of 10% of the stiffness for at least one gesture of the gestures pair were taken into account. This enabled the possible consequences of these inaccuracies in our evaluation to be minimized. The distribution of OpposEstim was analyzed for each speaker and condition as a function of the duration T1 and T2 of the paired gestures. To this end, the gesture duration plane (T 1 ,T 2 ) was divided into elementary squares, each 20 ms x 20 ms in size (Figure 1).

Stiffness estimations in the context of a damped second-order model

The second step of the evaluation consisted in finding the mass-normalized stiffness and damping factor in the context of an under-damped LSOM that would account for the experimental measures of V max /Amp and T. In the context of such a model, the movement of the speech articulator is assumed to obey an equation of the type (3)

ܽሺݐሻ ܾ • ݒሺݐሻ ݇ • ݔሺݐሻ ൌ 0 (3)
where x(t), v(t) and a(t) are the position, the velocity, and the acceleration of the articulator, respectively, and b and k are the mass-normalized damping factor and stiffness (hereafter simply damping and stiffness). The following two equations describe the relation between movement amplitude Amp, velocity peak V max , gesture duration T, stiffness k and damping b (see Appendix for details):

ܶ ൌ ଶ•గ √ସ•ି మ (4)
and

ೌೣ ൌ √ ଵା ష ್• మ • ݁ ି• మ ቂ• భ మ ି భ ഏ •୲ୟ୬ షభ ሺ ್• మ•ഏ ሻቃ (5)
If no solution can be found for the two equations (4, 5) when the kinematic parameters are experimentally measured for a particular speech gesture, then the production of this gesture cannot be assumed to behave like a damped linear second-order model. In this case gestural stiffness cannot be inferred from speech kinematics. If a solution for stiffness and damping exists for these two equations, an LSOM can be assumed to underlie the production of this gesture. To solve equations ( 4) and ( 5) the fsolve function in Matlab was used.

Results

Stiffness estimations based on an undamped linear second-order model: Opposite estimations

Considering all gestures together, the mass-normalized stiffness values computed either from equation (1) or from equation (2) ranged from 80 s -2 to 11000 s -2 . Figure 1 shows the corresponding distribution of the percentage OpposEstim. It can be seen that the percentage of opposite estimations is far from negligible (Minimum: 2.9%, Maximum: 47.1%; see Table 1).

However, opposite estimations do not occur everywhere in the (T 1 ,T 2 ) plane. They are found in 52.2% of the elementary squares (Table 1). These squares are mostly located in the neighborhood of the diagonal in the (T 1 ,T 2 ) plane. No case of opposite estimations was found when a very short gesture was compared with a very long one. The percentage of errors (OpposEstim) increases with gestural duration.

When data are split across speakers, similar observations can be made. Differences across subjects are only found in the percentage of elementary squares in which opposite estimations are found. This varies from 33.3% (sp6) to 60% (sp9). No significant difference was found across speakers in the minimum and maximum values of OpposEstim. In sum, the trends observed for the distribution of OpposEstim for all data taken together are confirmed for each speaker.

Results obtained for a damped linear second-order model

Considering all speakers and all repetitions together, the total number of analyzed gestures is 27531. For 5926 of these gestures, it was not possible to find a stiffness k and a damping b for the damped model that are compatible with both the measured V max /Amp value and the T duration value as specified in equations ( 4) and ( 5). This result represents 21.5% of the total number of data. When considering the data of each speaker separately, a similar percentage is found for 7 speakers (Table 2a). For the female speaker sp4, the percentage is clearly smaller (13.3%), and it is clearly larger (29.5%) for the ultra-fast male speaker sp7. When considering the data of all speakers together split by articulators and by gestures (Table 2b), a larger variability is observed: the percentage is significantly smaller than 21.5% in the closing gestures of the tongue tip and the lower lip, and it is significantly larger (close to 40%) for the tongue back. Nevertheless, the proportion of these data is generally substantial, and the value 20% is quite representative of the general trend observed across speakers, articulators and gestures.

To further investigate the characteristics of these 20% of data, all measures from all speakers were plotted in the (T, V max /Amp) plane. For the sake of clarity, it should be noted that for an LSOM, V max /Amp and T are theoretically linked by the relation

ೌೣ ൌ ் (6)
where c increases with the damping, with a minimum value equal to 1.57 (π/2) in the case of an undamped system. Speech data have often been found in the literature to be generally well accounted for by equation ( 6) with c values larger than 1.57 (see for example [START_REF] Ostry | Control of rate and duration of speech movements[END_REF], with c values ranging from 1.83 to 1.9), which is consistent with the hypothesis of the properties of an under-damped LSOM.

Figure 2 shows the distribution of the data. Data for which solutions do not exist for equations ( 4) and ( 5) (Set1, henceforth) are plotted in light gray. Other data (Set2) are plotted in dark gray. The bold solid curve corresponds to equation ( 6) with c=1.57. All the data of Set1 are located below this curve. Thus, all data of Set1 correspond to c values that are smaller than 1.57, which is not compatible with the characteristics of an LSOM. These data are well accounted for by equation ( 6) with c=1.44 (dashed-dotted curve). All the data of Set2 are above the bold solid line, and they are well accounted for by equation ( 6) with c=1.85 (dotted curve). Table 2 confirms that the properties of the Set1 and Set2 distributions and the c values computed for all data together are well representative of the data split by speakers, articulators and gestures.

In summary, for a significant percentage of the data (around 20%) the kinematic measures V max and Amp and the measured gesture duration T are not related in a way that is compatible with an LSOM. For the data, the ratio V max /Amp is smaller than the smallest value observed for an LSOM having the same gesture duration. These data can be seen as intermediate between gestures generated by an undamped LSOM, in which duration and V max /Amp are fully determined by the stiffness, and constant velocity gestures (corresponding to c=1), in which these variables are fully specified by an extrinsic controller. For these data, no reliable information about gestural stiffness can be extracted either from V max /Amp or from T.

In the rest of this section, only the data of Set2 will be considered. The c values are in good agreement with those found in former studies (for example [START_REF] Ostry | Control of rate and duration of speech movements[END_REF]. In addition, as predicted by an under-damped LSOM (equation ( 1)), the correlation between V max /Amp and √݇ is very strong (R=0.98 for all data), and it is constant across speakers, articulators and gestures (see Table 3 for details). Similarly, in agreement with equation ( 2), the correlation between 1/T and √݇ is strong too (R=0.81 for all data) and it varies just a little across speakers, articulators and gestures (see Table 3 for details). This confirms the fact that LSOMs account well for global dynamical characteristics of speech articulators. However, the damping values calculated from equations ( 4) and ( 5) are highly variable. Figure 3 shows the distribution of the normalized damping (damping divided by the critical damping) for data split by speakers and articulators. In all cases the normalized damping is largely distributed between values ranging between zero (undamped system) and 1 (critical damping). In general, the damping variability is huge and cannot be related to any physical properties of the articulatory system. Hence, these damping values should be considered as ad-hoc values fitting in both equations ( 4) and ( 5) rather than as reliable estimations of actual physical damping characteristics of speech gestures. Given equations ( 4) and ( 5) a large variability in damping should be associated with a noticeable variability in stiffness.

To quantitatively estimate this variability, two approaches were used. In the first approach, the standard deviation ݀ݏ and the mean value ݇ ത of the distribution of the stiffness within small intervals (0.5) of variation of V max /Amp was calculated. The relative variability of the stiffness was estimated as the ratio ሺ2. ݀ݏ ݇ ത ⁄ ሻ. Its variation was studied as a function of V max /Amp; its average and maximal values were calculated when V max /Amp varied. In a second approach, the same computations were done for 5 ms intervals of the gesture duration T.

Table 3 shows the results. The relative stiffness variability varies little with V max /Amp (the maximal value is close to the average value) and it is located around 20%. This amount of relative variability is found when all data are taken together as well as for data split by speakers, articulators and gestures. The relative stiffness variability is large enough to make any estimation of the stiffness from the ratio V max /Amp quite inaccurate. It is equally large for slow and for fast gestures as illustrated by the top panel of Figure 4 for all data taken together.

The relative stiffness variability varies significantly with gesture duration (the maximal value differs strongly from the average one). The average value is located around 60%, with small variations across speakers, articulators and gestures. The bottom panel of Figure 4 shows for all data taken together that the relative variability increases when gesture duration increases.

This result was also found when data were split across speakers, articulators or gestures.

Hence, stiffness estimations based on gesture durations are even more inaccurate than the estimations based on V max /Amp, and the longer the gesture is, the worse the estimation is.

Discussion

An evaluation was conducted of the LSOM's capacity to account for dynamical properties of speech articulators. The first part of the evaluation was made in the context of an undamped LSOM. It consisted of considering pairs of gestures and comparing the massnormalized stiffness differences between these gestures as estimated using equations ( 1) and

(2). These equations are two strictly equivalent ways to use the properties of an undamped LSOM to compute mass-normalized stiffness, one based on kinematic properties and the other one based on gesture duration. Our results reveal that both estimations are quite different in a significant number of cases. Cases in which one equation predicts a stiffness increase while the other equation predicts a stiffness decrease are numerous. For long gesture durations (above 200 ms) the percentage of such cases was found to be as high as 50%. Hence, a first important conclusion is that estimations of the mass-normalized stiffness based on an undamped LSOM should be considered with a great deal of caution.

It was also shown that the percentage of opposite estimations is small for short gestures (around 50 ms), but increases when gesture duration increases. A conceivable explanation for the deterioration of the estimation lies in the fact that due to their non-linear elastic properties (see Introduction) tongue and lip stiffnesses intrinsically vary when these soft articulators move. Since long gestures are often associated with larger deformations and displacements, long gestures should undergo greater variation in stiffness over time than short gestures.

Consequently, the longer the gesture is, the less correct a modeling based on an undamped LSOM is, which assumes per se that stiffness is constant over time.

In the second part of the evaluation, an under-damped LSOM was considered. Massnormalized stiffness and damping were computed from equations ( 4) and ( 5), which link these variables with the ratio V max /Amp and the duration T. In around 20% of the cases, no solution could be found, because the measures of V max , Amp, and T are not compatible with the physical laws of an LSOM. More specifically, the parameter c of equation ( 6) was found to be systematically smaller than the smallest value (c=1.57) possible for an LSOM. Hence, for these data, stiffness estimation from V max /Amp or T has no theoretical justification.

Consequently, a prerequisite for the estimation of stiffness from V max /Amp or T is to compute the c value and to remove those data where c is smaller than 1.57.

For the other 80% of the data, the stiffness and damping values computed from equations ( 4) and ( 5) depict significant variabilities. These variabilities make stiffness estimations quite inaccurate and, consequently, not very reliable. Just as for the estimation based on an undamped model, the inaccuracy of the estimation based on an under-damped model clearly increases when gesture duration increases. This general result shows that the relation between gesture duration and stiffness becomes always less strong when gesture duration increases. It is consistent with the hypothesis that extrinsic factors contribute to the control of gesture duration, especially when this duration is long and achievable for a broad range of stiffness.

Conclusion

To conclude, this study has shown that in speech production the relation between massnormalized stiffness, peak velocity, gesture amplitude and gesture duration cannot be reliably described by a unique formulation based on a linear second-order model. This result may originate in the variation in the damping factor across gestures. In addition, other factors such as variations in the stiffness and in the damping factor over time may also contribute to this low reliability. Furthermore, there are some indications that external time specification could significantly contribute to determining gesture durations and the kinematic properties of speech gestures. Hence, inferences about motor control and time control in speech production based on stiffness estimation using a linear second-order model should be considered with caution. Figure 2: Distribution of all data in the (T, V max /Amp) plane. Light gray: data for which no solution was found for equations ( 4) and ( 5); dark gray: data for which a solution was found for equations ( 4) and ( 5). Bold solid line: V max /Amp=1.57/T. Dashed-dotted line:

Figure Captions

V max /Amp=1.44/T, accounting for data plotted in light gray. Dotted line: V max /Amp=1.85/T, accounting for data plotted in dark gray. 4) and ( 5) "c1" c coefficient in V max /Amp=c/T for data compatible with Equations ( 4) and ( 5) "c2" c coefficient in V max /Amp=c/T for data not compatible with Equations ( 4) and ( 5) Speaker "all" corresponds to the analysis of all data together "Articul" refers to the EMMA sensors taken into account Gest: 'O' = opening; C=closing "dor": tongue dorsum sensor; "jaw": jaw sensor; "llip": lower lip sensor; "ttip": tongue tip sensor 3b -Data split by articulators and gestures' types for all speakers together "Corre1": correlation coefficient between √݇ and 1/T "Corre2": correlation coefficient between √݇ and V max /Amp "AvVari1": average relative stiffness variability when V max /Amp varies (cf Fig. 4a) "MaxVari1": the maximum relative stiffness variability when V max /Amp varies (cf Fig. 4a) "AvVari2" average relative stiffness variability when T varies (cf Fig. 4a) "MaxErr2" maximum relative stiffness variability when T varies (cf Fig. 4a) Speaker "all" corresponds to the analysis of all data together "Articul" refers to the EMMA sensors taken into account Gest: 'O' = opening; C=closing "dor": tongue dorsum sensor; "jaw": jaw sensor; "llip"=lower lip sensor; "ttip" = Tongue tip sensor Under these conditions:

ݔሺݐሻ ൌ ܣ • ଶ•√ √ସ•ି మ • cosሺ √ସ•ି మ ଶ • ݐ ߮ሻ • ݁ ି ್ మ •௧ (ii) with ߮ ൌ tan ିଵ ሺ െܾ √4 • ݇ െ ܾ ଶ ሻ and ߮ א ቂെ ߨ 2 , 0ቃ ݒሺݐሻ ൌ െܣ • ଶ• √ସ•ି మ • sinሺ √ସ•ି మ ଶ • ݐሻ • ݁ ି ್ మ •௧ (iii) ܽሺݐሻ ൌ ܣ • ଶ••√ √ସ•ି మ • cosሺ √ସ•ି మ ଶ • ݐ θሻ • ݁ ି ್ మ •௧
(iv)

with ߠ ൌ ሺtan ିଵ ሺ ܾ √4 • ݇ െ ܾ ଶ ሻ െ ߨሻ and ߠ א ቂെߨ, െ ߨ 2 ቃ

The displacement during the first half pseudo-period is assumed to represent the articulator displacement during a gesture. From these equations, the ratio V max /Amp and the movement duration T can be calculated according to the following equations:

ܶ ൌ ଶ•గ √ସ•ି మ (v) ೌೣ ൌ √ ଵା ష ್• మ • ݁ ି• మ ቂ• భ మ ି భ ഏ •୲ୟ୬ షభ ሺ ್• మ•ഏ ሻቃ (vi)
Equation (vi) can also be written as follows

  (a) Speech gestures correspond to half a period of an LSOM oscillating around its rest position. The position reached at the end of the movement should correspond to a turning point (the extreme position of the oscillation). (b) The proportionality factors α and β used in the equations (1) and (2) are assumed to be constant across gestures. (c) Stiffness and damping are constant during the whole duration of a gesture. In speech production, however, these three assumptions are problematic for the following reasons: There are speech sounds, like long vowels, sibilants or geminates, which can be kept relatively stable over fairly long time intervals. During these intervals plateaus are observed in the articulatory trajectory. These plateaus are not compatible with the turning point conception of assumption (a), unless the damping is stronger than the critical damping.

Figure 1 :

 1 Figure 1: Distribution of OpposEstim computed for all data as a function of gesture duration

Figure 3 :

 3 Figure 3: Distribution of the normalized damping (damping divided by the critical damping)

Figure 4 :

 4 Figure 4: Variation of the relative stiffness variability (see text) as a function of V max /Amp

  β being constant. If the system is undamped, b=0 and then α=1/2 and β=π.

  Figure1

Figure

  Figure 4.a

Figure

  Figure 4.b

Table 1 :

 1 Characteristics of the OpposEstim distributions. Speaker "all" corresponds to the analysis of all data together. "Min" and "Max" are the minimal and maximal values of OpposEstim in the distribution; "% non_zero" is the proportion of elementary (20 ms x 20 ms) squares of the gesture duration plane (T 1 ,T 2 ) in which opposite estimations were found;"Slope" is the slope of the linear regression between T 1 and the average value of OpposEstim computed around the diagonal in the (T 1 ,T 2 ) plane (see text);

	Speaker Max Min % non_zero Slope
	all	47.1 2.9	52.2	469.2
	sp1	46.7 3.3	46.2	409.5
	sp2	36.7 3.3	58.8	781.0
	sp3	41.9 3.2	54.8	649.8
	sp4	46.7 3.3	58.0	684.5
	sp5	41.0 2.56	52.6	809.5
	sp6	33.3 2.1	41.5	1031.3
	sp7	57.6 3.0	55.9	822.5
	sp8	51.5 3.0	56.0	535.7
	sp9	60.0 3.3	60.0	1290.5

Table 2 :

 2 Global analysis of the results computed from Equations (4) and (5) Table2a-Data split by speakers for all gestures together Table 2b -Data split by articulators and gestures' types for all speakers together "NoComp": percentage of data for which no solution is found for Equations (

Table 3

 3 Relative variations of stiffness as computed from Equations 4 and 5 Table3a-Data split by speakers for all gestures together Table

Articul Gest Cor1 Cor2 AvVari1 MaxVari1 AvVari2 MaxVari2 dor

	Speaker Cor1 Cor2 AvVari1 MaxVari1 AvVari2 MaxVari2
	all		0.81 0.98	21.4	23.9	66.2	118.7
	sp1		0.73 0.97	21.9	32.8	67.9	98.7
	sp2		0.76 0.97	20.3	25	61.5	119.7
	sp3		0.76 0.97	20.9	26.9	65.6	129.2
	sp4		0.75 0.97	20.2	24.3	65.6	104.9
	sp5		0.82 0.97	22.5	28.3	61.1	132.7
	sp6		0.81 0.97	19.7	29.9	54	103.7
	sp7		0.85 0.98	19.9	25.1	55.7	86.8
	sp8		0.77 0.97	21.3	25.3	61.4	84.6
	sp9		0.72 0.97	21.8	26.9	72.4	121.1
				3a
		C	0.81 0.97	20.4	24.9	51.7	72.1
	dor	O	0.84 0.98	20.2	26.7	57.9	97.9
	jaw	C	0.85 0.98	19.8	27.3	54.4	87.3
	jaw	O	0.83 0.98	19.4	22.8	58.3	114.8
	llip	C	0.83 0.97	19.8	23.8	52.1	101.6
	llip	O	0.81 0.97	19	22.2	51.5	93.4
	tback	C	0.87 0.98	20.5	26.4	57.2	102.1
	tback	O	0.87 0.98	20.5	26.4	58.6	97.4
	ttip	C	0.71 0.97	20.6	24.5	68.1	118.3
	ttip	O	0.78 0.97	21	26.7	63.7	116
				3b

Appendix: Linear damped second-order model

  Mass-normalized stiffness k; Mass-normalized damping factor b Position x(t); Velocity v(t); Acceleration a(t)

	Differential equation of movement:
	ܽሺݐሻ ܾ • ݒሺݐሻ ݇ • ݔሺݐሻ ൌ 0	(i)
	Initial conditions:	t=0, x(t)=A0 and v(t)=0.

Acknowledgments

This work was funded by a grant from the BMBF and the French-German University to the project PILIOS carried out jointly at Gipsa-lab in Grenoble and ZAS in Berlin. It is dedicated to Dieter Fuchs.


Antonio Wendell

O Rodrigues

Vincent Aranega
email: vincent.aranega@inria.fr

Anne Etien
email: anne.etien@lifl.fr

Frédéric Guyomarc'h §
email: frederic.guyomarch@inria.fr

Jean-Luc Dekeyser
email: jean-luc.dekeyser@lifl.fr

Enabling Traceability in MDE to Improve Performance of GPU Applications

Keywords: Profiling, GPU, OpenCL, MDE, Traceability, MARTE Profiling, GPU, OpenCL, MDE, Traçabilité, MARTE

Graphics Processor Units (GPUs) are known for offering high performance and power efficiency for processing algorithms that suit well to their massively parallel architecture. Unfortunately, as parallel programming for this kind of architecture requires a complex distribution of tasks and data, developers find it difficult to implement their applications effectively. Although approaches based on source-to-source and model-to-source transformations have intended to provide a low learning curve for parallel programming and take advantage of architecture features to create optimized applications, the programming remains difficult for neophytes. A Model Driven Engineering (MDE) approach for GPU intends to hide the low-level details of GPU programming by automatically generating the application from the high-level specifications. However, the application designer should take into account some adjustments in the source code to achieve better performance at runtime. Directly modifying the generated source code goes against the MDE philosophy. Moreover, the designer does not necessarily have the required knowledge to effectively modify the GPU generated code. This work aims at improving performance by returning to the high-level models, specific execution data from a profiling tool enhanced by smart advices from an analysis engine. In order to keep the link between execution and model, the process is based on a traceability mechanism. Once the model is automatically annotated, it can be re-factored by aiming performance on the re-generated code. Hence, this work allows us keeping coherence between model and code without forgetting to harness the power of GPUs. To illustrate and clarify key points of this approach, an experimental example taking place in a transformation chain from UML-MARTE models to OpenCL code is provided.

Introduction

Advanced engineering and scientific communities have used parallel programming to solve their large-scale complex problems for a long time. Despite the high level knowledge of the developers belonging to these communities, they find hard to effectively implement their applications on parallel systems. Some intrinsic characteristics of parallel programming contribute to this difficulty, e.g. race conditions, memory access bottleneck, granularity decision, scheduling policy or thread safety. In order to facilitate programming parallel applications, developers have specified several interesting programming approaches.

To increase the application development, software researchers have been creating abstractions layers that help themselves to program in terms of their design intent rather than the underlying architectures, e.g., CPU, memory, network devices. They shield themselves from the complexities of these architectures. As method to implement these abstraction layers, approaches based on Model Driven Engineering (MDE) have frequently been used as a solution to accelerate software development, in particular MDE compilers.

In general, MDE compilers have the same structure than traditional compilers, but at a different level. High-level models are taken as input for the MDE compiler and a specific source code language is produced as output. Dealing with high-level models gives to the model designer a twofold advantages: on the one hand it increases re-usability and on the other hand it hides specific low-level details of code generation from the designed model. In this context, the software is directly generated from the high-level models.

Obviously, the details hidden by the high-level modeling must be introduced by the MDE compiler to generate a usable software. These details depend highly on the used programming language and their complexity vary from a language to another. In 2008, the consortium managed by Khronos Group released the first specification to Open Computing Language (OpenCL) [START_REF] Group | OpenCL -The open standard for parallel programming of heterogeneous systems[END_REF]. The OpenCL language is the first open, royalty-free, standard for general-purpose parallel programming of heterogeneous systems. It provides a uniform programming environment for software developers who want to write efficient and portable code for high-performance computing servers, desktop computer systems and handheld devices using a diverse mix of multi-core CPUs, GPUs, Cell-type architectures and embedded processors.

As MDE framework for parallel embedded systems, Gaspard2 [START_REF] Gamatié | A Model Driven Design Framework for Massively Parallel Embedded Systems[END_REF] proposes, among others, an MDE compiler to several programming languages. The compiler takes UML models profiled with the MARTE standard profile [START_REF] Omg | Modeling and Analysis of Real-time and Embedded systems (MARTE)[END_REF] as input model and generates software for few target platforms to reach simulation and validation purposes. Among the different target languages, Gaspard2 includes an OpenCL branch introduced in [START_REF] Rodrigues | An MDE Approach for Automatic Code Generation from MARTE to OpenCL[END_REF]. Using such a framework, the designer can focus on the general software architecture without worrying about the OpenCL implementation details.

However, the generated software could produce low performance issues due to a poor model design, even if optimization stages are proposed or implemented by the MDE compiler. Indeed, automatic generation does not ensure application performances when the application is launched. In these cases, fine-tuning the generated code to improve the performances is a real need.

In an MDE approach, fixing the software implies applying modifications on one of the two artifacts: the designed models or the software source code.

Nevertheless, directly modifying the generated source code is a difficult task for the model designer that does not know details about the target platform. Actually, the designer does not necessarily have the knowledge to efficiently modify the code. Moreover, the designed models lose the synchronization with the source code. A good solution to keep the coherence between the designed models and the generated source code is to regenerate code from the model correctly modified. Thus, changes aiming to achieve better performance must be made directly in the designed input models.

However, two issues make this method difficult to initiate as solution. Firstly, when a performance issue is observed, it is hard to figure out which parts of the models are responsible for this issue [START_REF] Dorina | Applying the uml performance profile: Graph grammar-based derivation of lqn models from uml specifications[END_REF]. Thus, we have to keep a link between the models, the performance observations and the runtime results. Secondly, even if problems in the models are found, efficiently modifying it is not an easy task. Indeed, the improvement must often take into account details of the target architecture, usually unknown and hidden to the designer, to provide better and more efficient changes in the models.

Among the different techniques proposed to assist the designer during the performance improvement phase, two categories of tools can be found. The first one deals with static estimation computed in the model, whereas the second one, called profiling, deals with dynamic information. Our contribution focuses on profiling category because of its ability to gather details from a real execution environment. Hence, the recovered information comes directly from the software execution rather than from an estimation computed from the input high-level models.

In this research report, we present an approach based on model traceability to automatically return details and performance measures obtained during the software execution directly in the designed models. The performance information is recovered from dedicated profiling tools returning important measures as the running time or memories access time. Having such information directly reported in the input models gives a first overview of performance issues to the model designer.

In addition to the profiling information, specific smart advices are proposed in order to assist, as well as possible, model designers to achieve better results. These smart advices are computed by using the measured performances and specification details of the execution hardware. They allow the designers to easily and quickly fine tune their models aiming performance improvements. Once the models modified according to the proposed approach, the software is then regenerated keeping coherence between the models and the code.

The research report is structured as follows: in section 2 we present the different formalisms and technologies used in the research report. In section 3, we discuss about the major works of the domain. In section 4 we present the MDE based compilation chain that is used in the research report as support for our approach integration. In section 5 we present our traceability mechanism which plays an important role in our approach before showing how the compilation chain, the traceability mechanism and the profiling information are fitted together in section 6. We then present our approach on an example in section 7 before concluding in section 8.

Background Review

GPU and OpenCL

OpenCL is a standard for parallel computing proposed by Apple and has been released by Khronos Group since the first specification. OpenCL consists of a language, API, libraries and a runtime system. As depicted in Figure 1, this standard is based on a platform model that divides a system into one host and one or several compute devices. The compute devices act as co-processors to the host. Compute devices are subdivided into multiple compute units (CUs), which are also subdivided into one or multiple processing elements (PEs). An OpenCL application is executed on the host (e.g., CPU), which sends instructions, defined in special functions called kernels, to the device (e.g., GPU). Thus, OpenCL does not mean programming only devices, but host and device.

In the context of programming, the OpenCL standard defines a data parallel and a task parallel programming model1 . In the data parallel model, the device runs multiple instances of the kernel in parallel on distinct data. Each instance is called a work-item (WI). While all work-items run the same kernel, they may perform different instructions at a time and occasionally change the instruction path i.e., Single Program, Multiple Data (SPMD). Work-items can be arranged in work-groups (WG). OpenCL defines indexing schemes by which a work-item can be uniquely identified through either a global ID, or a workgroup ID together with a local ID. The work-groups are assigned to CUs, where the work-items of each group are run in parallel on the PEs. Normally, multiple work-groups are assigned to the same CU, and multiple work-items are assigned to a PE. Conceptually, both are executed in sequence, but an implementation can use the excess parallelism for hiding memory latency (by switching between work-groups or work-items, respectively). Synchronization of work-items is possible within a work-group only, and takes the form of a barrier. OpenCL has many similarities with NVIDIA's GPU programming model 1 CUDA [START_REF] Kirk | Programming Massively Parallel Processors: A Hands-on Approach[END_REF], the most of the differences are in relation to terminology. For instance, in CUDA, work-items are called threads, and work-groups are called blocks.

OpenCL also defines a programming language for writing kernels. OpenCL is an extension of C. Kernels are executed within their own memory domain and may not directly access host main memory.

MDE and MARTE

Model-Driven Engineering (MDE) [START_REF] Lugato | Model-Driven Engineering for High Performance Computing Applications[END_REF] aims to raise the level of abstraction in program specification and increases automation in program development. MDE addresses to use models at different levels of abstraction for developing systems, thus raising the level of abstraction in program specification. An increase of automation in program development is reached by using model transformations. Higher-level models are transformed into lower-level models until the model can be made executable using either code generation or model interpretation.

The UML profile for MARTE [START_REF] Omg | Modeling and Analysis of Real-time and Embedded systems (MARTE)[END_REF] extends the possibilities for modeling applications, architectures and their relations. Moreover, MARTE allows extending the performance analysis and task scheduling based on target platform As these core concepts have generic definition, they can be applied to GPUs as well. Among others, the benefits of using this profile are:

1. to provide a common way of modeling both hardware and software aspects of systems in order to improve communication between developers 2. to enable interoperability between development tools used for specification, design, verification, code generation 3. to foster the construction of models that may be used to make quantitative predictions regarding features of systems taking into account both hardware and software characteristics.

Allocation Modeling (Alloc) from Foundations, Generic Resource Modeling (GRM) and Generic Component Model (GCM) from Design Model, and Repetitive Structure Modeling are packages that provide the main resources to model and to describe our entire application. In particular, RSM provides concepts helping to express the inherent parallelism of applications.

Related Work

The analysis of software performance is part of the Software Performance Engineering (SPE) [START_REF] Smith | Performance Solutions: A Practical Guide to Creating Responsive, Scalable Software[END_REF]. The SPE process uses multiple performance assessment tools depending on the state of the software and the amount of performance data available. SPE is a relatively mature approach and normally is associated to the prediction of the performance of software architectures during early design stages.

Several performance modeling approaches have been proposed in the literature, including simulation-based approaches and model-based approaches, particularly approaches based on UML. Some examples of works which have been developed in this research field are enumerated below.

1. Model-Driven SPE (MDSPE) is proposed in [START_REF] Traore | UML-based Performance Modeling of Distributed Software Systems[END_REF] and deals with building annotated UML models for performance, which can be used for the performance predictions of software systems. MDSPE consists in deriving the performance models from the UML specifications, annotated according to the OMG profile for Schedulability, Performance, and Time (SPT) [START_REF] Omg | UML Profile for Schedulability, Performance, and Time[END_REF]. It consists of Performance Annotation and Performance Analysis steps.

The first one deals with encapsulation of performance characteristics of the hardware infrastructure, as well as QoS requirements of specific functions.

The second one is implemented by a performance analyzer which computes the performance metrics, thereby predict the software performance.

2. A simulation-based software performance modeling approach for software architectures specified with UML is proposed in [START_REF] Balsamo | A simulation-based approach to software performance modeling[END_REF]. Similarly to MDSPE, this approach is also based on the OMG profile SPT [START_REF] Omg | UML Profile for Schedulability, Performance, and Time[END_REF], performance parameters are introduced in the specification model with an annotation. The performance results estimated by the execution of the simulation model are eventually inserted into the original UML diagrams as tagged values, so providing a feedback to the software designer. The proposed methodology has been implemented into a prototype tool called Software Architectures Performance Simulator.

3. The ArgoSPE approach, proposed in [START_REF] Gómez-Martínez | ArgoSPE: Model-based Software Performance Engineering[END_REF], is a tool for the performance evaluation of software systems in the first stages of the development process. From the designers viewpoint, ArgoSPE is driven by a set of "performance queries" that they can execute to get the quantitative analysis of the modeled system. For ArgoSPE, the performance query is a procedure whereby the UML model is analyzed to automatically obtain a predefined performance index. The steps carried out in this procedure are hidden to the designer. Each performance query is related to a UML diagram where it is interpreted, but it is computed in a petri network model automatically obtained by ArgoSPE.

4. An interesting approach aiming at model refactoring is depicted in [START_REF] Le | Un Flot de Conception pour Applications de Traitement du Signal Systématique Implémentées sur FPGA à Base d'Ingénierie Dirigée par les Modèles[END_REF]. This approach relies on optimization of parallel and sequential tasks on FPGA accelerators. In this case, before generating the VHDL code, the application at Register Transfer Level (RTL) is analyzed by an optimization system which exploits the allocation of FPGA resources. Then, the input model receives changes according to the optimization process results.

Further, there are several other research works that deal with SPE and UML but they are less co-related and we are not going into extended details. CB-SPE [START_REF] Bertolino | Towards Component-Based Software Performance Engineering[END_REF] reshapes UML performance profiles into component based principles. MDPE [START_REF] Fritzsche | Model transformation chains and model management for end-to-end performance decision support[END_REF] describes a model transformation chain that integrates multiparadigm decision support into multiple Process Modeling Tools. An extension [START_REF] Fritzsche | Application of Tracing Techniques in Model-Driven Performance Engineering[END_REF] added to this work uses traceability and simulation engines in order to provide feedback to model designers. And in [START_REF] Dorina | Applying the uml performance profile: Graph grammar-based derivation of lqn models from uml specifications[END_REF] is proposed a graph-grammar based method for transforming automatically a UML model annotated with performance information into a Layered Queueing Network (LQN) performance model.

As detailed in previous section, we base our work on the MARTE profile. It provides special concepts for performance analysis: Performance Analysis Modeling (PAM). This allows the model designer to define execution platform specification in the input models. However, as in UML SPT, the platform specification is modeled in the input model and assumes an infrastructure knowledge from the model designer. Moreover, the performance analysis is obtained from static estimations that may be far from performances measured at runtime.

In short, all these earlier works lack the profiling feedback and possible directions aiming better performances in a real execution environment. Besides, they do not take into account small differences in features of the target platform and their relation with application behavior. Our work does not require early annotations and relies on real execution environment aiming to make possible fine-tuning applications at design time.

From UML-MARTE to OpenCL

A new branch [START_REF] Rodrigues | An MDE Approach for Automatic Code Generation from MARTE to OpenCL[END_REF] of the Gaspard2 [START_REF] Gamatié | A Model Driven Design Framework for Massively Parallel Embedded Systems[END_REF] framework was proposed to generate an effective OpenCL code. At design time, Gaspard2 uses UML profile for MARTE to refine the UML concepts of the application, then using transformation chains it allows the model designer to generate code for a few target platforms. One of the main advantages of MARTE is that it clearly distinguishes the hardware components from the software components. This is done via stereotypes provided in part by the Detailed Resource Modeling (DRM) package, in particular the HwResource stereotype. For hybrid (CPU and Compute Device) conception this separation is of prime importance as it is usual to create those two parts of the system simultaneously, by different teams. Moreover, this separation provides a flexible way to independently change the software part or the hardware part in a system co-design environment. For instance, this allows testing the software on different kinds of hardware architecture, or to reuse an architecture (with a few or no changes) for different applications.

The next subsections present the conceptual models defined at design time for the Gaspard2 framework.

Application Modeling

The conception of the application model relies on three main characteristics: first, what are the tasks and the interconnections among them; second, what is the repetition number of a task and its hierarchy that will be instantiated either in time or space2 ; and third, how to express the dataflow. Aiming at generating GPU code, to clearly distinguish a host from a compute device, both defined in OpenCL platform model, a tagged-value description in HwResource stereotype whose value is either Host or Device.

The allocation of the tasks onto processors is important during application design. Indeed, once we have an allocation model, model-to-model transformations can identify OpenCL kernels from input models' tasks which are mapped to the GPU ressources. The tasks allocation comprehends, both spatial distribution and temporal scheduling aspects, in order to map certain operations onto available computing and communication resources and services. For the allocation modeling purpose, the Allocation Modeling package of the MARTE profile is used.

Although MARTE is suitable for modeling purposes, it lacks the means to express the operations that a task will implement. Gaspard2 bridges this gap by introducing additional concepts and semantics to fill this requirement for system co-design. Gaspard2 defines a notion of a Deployment specification level [START_REF] Gamatié | A Model Driven Design Framework for Massively Parallel Embedded Systems[END_REF] in order to generate compilable code from an application model. This level is related to the specification of a elementary component (EC): basic block having atomic functions. The deployment model allows the model designer to describe how the IPs (Intellectual Property), optimized and normally parametrized functions that depend of target technology, should be associated to ECs.

Under the perspective of data distribution, MARTE provides to the models special stereotypes based on Array-OL called tilers [START_REF] Boulet | Array-OL Revisited, Multidimensional Intensive Signal Processing Specification[END_REF]. These stereotypes allows us specifying which data are processed by each iteration of our repetitive task.

Transformations

In MDE, a model transformation chain could be associated to a compilation process which transforms source models into target models through multiple transformations [START_REF] Vanhoof | Breaking up the transformation chain[END_REF]. The source and the target models respectively conform to the source and the target metamodels. A model transformation chain relies on a transformation sequence where the output models of a transformation are used as input models for the next transformation. Such a decomposition makes easier the extension and the maintainability of a compilation process: new transformations extend the compilation process and each transformation can be modified independently from the others.

Figure 2 illustrates the OpenCL transformation chain of the Gaspard2 framework defined according to our model transformation engine. Each transformation is represented by a gear. For the UML-MARTE to OpenCL, the transformation chain is made of 9 transformation: 8 model-to-model transformations (gears numbered 1 to 8 in Figure 2) and one final model-to-text transformation (gear number 9 in Figure 2). The transformation engine runs transformations conform to the Query/View/Transformation standard (MOF QVT) [START_REF] Omg | M2M/Operational QVT Language[END_REF], proposed by the OMG and uses the EMF framework [START_REF]Eclipse Consortium[END_REF] to manage the models. We have chosen QVTO as QVT implementation for the model-to-model transformation in Gaspard2. The input model in the Figure 2 represents the whole model (application, architecture, deployment, and allocation). Then, we no longer use UML profile for MARTE. To make simpler transformations and to add further concepts, we use the MARTE metamodel whose elements come from stereotypes in the MARTE profile. Additional notions such as memory mapping are introduced by the transformation chain.

The other transformations take into account important aspects such as scheduling analysis. These transformations are more detailed in [START_REF] Rodrigues | An MDE Approach for Automatic Code Generation from MARTE to OpenCL[END_REF].

After the transformation execution number 8, a model with concepts closer to the target platform is produced. We call it hybrid model [START_REF] Rodrigues | An MDE Approach for Automatic Code Generation from MARTE to OpenCL[END_REF] because it contains all the artifacts useful to the generation of code on hybrid (or heterogeneous) architecture consisting of CPU and GPU. From this model, the code generation (model-to-text transformation number 9 in Figure 2) is a trivial step using Acceleo templates.

Traceability

In an MDE production chain, the model-to-model transformation execution uses elements from the input models to create elements in the output models. During the transformation execution, links between the elements of the input and output models can be gathered thanks to a traceability mechanism.

As we present in section 4, many transformations can be chained to produce a transformation chain. A trace model is produced for each model-to-model transformation. Thus, for a chain made of n transformations (including the final model-to-text transformation), n -1 model-to-model transformation traces are produced. In the case of UML to OpenCL transformation chain, 8 traces are produced. Using them, it is possible to recover what are the elements created in the (n -1)-th model from an element in the first model and vice versa. In this paper, we consider "ancestors" and "descendants". The ancestors of a model element X are the elements of the previous models in the transformation chain which lead to the creation of X. In the same way, the descendants of a model element Y are the elements of the next models in a transformation chain which are created from Y .

In the following subsections, we present our traceability mechanism which is based on two metamodels, the first one, named local trace, is used to keep the model-to-model transformation trace, whereas the second one, named global trace, is used to keep the sequence between the traces.

Local Trace

The local trace metamodel (presented in Figure 3) is designed around three main concepts: Link, ElementRef and RuleRef. A link binds two sets of elements: the srcElements and the destElements. The former set of elements leads to the creation of the latter set of elements. Each link may refer to a rule through the RuleRef concept when the trace is associated to a transformation. The other concepts of the metamodel are used to organize the trace models by providing containers. More details can be found in [START_REF] Aranega | Traceability Mechanism for Error Localization in Model Transformation[END_REF].

Global Trace

If the local trace refers to a single transformation, the global trace eases the navigation between the different models and local traces in a transformation chain. Figure 4 shows the global trace metamodel.

The Need of a Reduced Trace

In performances analysis contexts, the intermediary traces and models generated are useless. The only required links are those between elements from the input models and the elements from the last one. The trace reduction allows the programmer to directly retrieve these links, without superfluous navigation. This reduced trace enables one to keep a reasonable and manageable trace size in a transformation chain.

The reduced trace is built by gathering, for each element of the last model, the elements of the input model leading to its creation. More precisely, the global trace model and the various local trace models are navigated in the backward direction. The reduced trace establishes a bridge between elements from the input model and elements of the last model exactly as if the transformation chain would be assimilated to a single transformation. Figure 5 shows the reduced trace principles within an example.

The model m 0 is transformed into a model m 1 and the trace lt 1 is produced. The model m 1 is then directly consumed by a transformation that translated it in the model m 2 and produced the trace lt 2 . The two traces link the source and destination elements involved in the transformations. For example, the trace lt 1 expresses that the element A in the initial model m 0 enables to the creation of the element B' in the intermediary model m 1 . This trace also shows that the A' element in the intermediate model m 1 has been created from the A and C elements. Then, the A' element leads to the creation of the A" element in The trace reduction algorithm searches for ancestors elements in the initial model of a given element in the last model. For the A" element, it navigates from A" in m 1 to A' in m 1 . From A', it navigates to A and C in m 0 . Thus, the kept link puts A and C from m 0 in a direct relation with A". The same algorithm is performed for each element in the last model. The resulting reduced trace is labeled rt in Figure 5(b).

Integration Approach

The main goal in this work is to provide a high level profiling environment in a model design context. Performance execution feedbacks are directly provided in the input models. From this way, the model designers can easily understand the designed system behavior and identify what should be fine tuned. The main interest of this approach is to benefit from real data from a profiling tool instead of using performance statically computed from performance constraints designed in the input models.

Our approach is sketched in Figure 6. The profiling life-cycle presented follows a classic structure usually manually performed:

1. the software is generated from the high-level models (step 1 and cf. section 4) and the trace models are produced 2. the software is executed, producing profiling logs (steps 2 to 4)

3. the produced logs are analyzed and returned in the input models (steps 5 to 7).

High Level Abstraction

2.

3. 4.

5.

7. Currently, in works available through the literature, only the first part of the process is automatic (step 1). The second part (steps 2 to 4) producing the logs highly depends on the used tools. The third part where logs are analyzed and connected to the input elements that should be modified remains a manual and complex process. In this paper, we focus on this step of the process (steps 5 to 7 in Figure 6) by automating it.

6.

Profiling Logs production Software Execution

Profiling and Advices Model Production

In order to automate this analysis and the performances feedback, our process uses two main artifacts: an expert system (reported as Domain Specific Profiling Analysis Transformation Library in Figure 6) and the model-to-model traceability (Trace Model ). The expert system is used during the analysis step, whereas the traceability is used for the performance feedback.

In a first time, we present how the traceability is managed in the compilation chain and the required modifications on the model compilation chain. Then, we present the expert system creating the profiling advices and, we show how these advices are reported into input models.

Managing The Whole Chain Traceability and Avoiding Model-to-Text Traceability

In order to keep the links between the input models and the software execution, trace models are produced all along the compilation chain, except for the modelto-text transformation. The translation from model to text implies keeping information on text blocks and words [START_REF] Olsen | Scenarios of Traceability in Model to Text Transformations[END_REF]. The granularity for this kind of trace made its management and maintainability difficult. In our case, the code has to be studied only in term of the abstract concepts from the models, and not in terms of blocks and words. Thus, in this paper, the model-to-text traceability has been avoided.

To bypass the model-to-text trace, the code generation deals with unique identifiers (UIDs) associated to each elements in the last model. The profiling logs produced by the software execution refers to the UID of the analyzed element. Thus, the Profiling Logs can be rebound to the model world.

Concretely, in order to generate the UIDs, we use the EMF feature called Universal Unique IDentifier (UUID) and, consequently, we modify the compilation chain. A new transformation adding the UID was inserted as last step of the model-to-model transformation chain, just before the code generation.

From Execution to Smart Advices

Once the software code is generated, the software is executed. During the execution, profiling logs are produced by third party tools.

Profiling Logs Parsing

According to the used Software Development Kit (SDK) and profiling tools, these profiling logs are generated with a dedicated format. This format is parsed using a shell-script that builds a profiling model that conforms to the metamodel presented in Figure 7.

The metamodel root: ProfilingModel gathers the different entries that can be found in the profiling logs. Each profiling entry from the logs is represented by a LogEntry gathering the hardware model (e.g. Tesla T10 or G80) with the archiModel attribute. Each LogEntry contains several Parameter elements owning a kind and a data representing: the information type (e.g., occupancy, time or memory consumption), and its value. In order to keep the link between the profiling information and the transformation chain, each LogEntry keeps the UID from the logs with the UID attribute. In addition, a timeStamp attribute is added to the LogEntry in order to keep the logs sequence. This metamodel

LogEntry entries

Figure 7: Profiling metamodel is generic enough to produce models that can gather information that can be found in the profiling logs.

The Expert System

In-depth knowledge of the target platform is really important to identify which elements should be modified. Model designers do not always have such a knowledge. Thus, more than profiling results, we propose to provide smart advices to model designers. To reach this aim, we integrate an expert system that uses input data from two sources: profiling logs and device features database. The first one gives us factual data about execution. The second one gives us behavior features of the target platform. By combining both sources, it is possible to deduce what to do to attain some optimization level. For instance, assuming the device supports 32MB in shared memory allocation per group of work-items and the application allocates at runtime 48MB. The expert system is able to indicate that it is necessary to decrease the memory allocation after analyzing profiling log results and device constraints. In this case, the expert system provides a hint where the problem occurs. In order to analyze the many properties of the results, an extensible library (cf. Figure 6) is proposed in this paper.

The device features database gathers a set of devices from a specific vendor. It is represented as a model that conforms to the metamodel of Figure 8 in order to be properly handled by either transformation languages or other tools based on the EMF framework. In the context of the UML-MARTE to OpenCL transformation chain, the target platform is the GPU.

The model root is represented by DeviceFeratures. It gathers the many vendors' GPU models (e.g., Tesla T10) represented by the GPU_Models concept. These GPU models are associated to a group of GPU devices (represented by the GPU_Device concept) having the same allocation granularity (AG attribute) and compute capability (CC attribute). Their values are specified according to two enumerations: AllocationGranularity and ComputeCapability, respectively. In the first enumeration, each literal represents the compute capability version of the GPU (e.g., the literal cc10 represents the 1.0 compute capability ver-

Backtracking Advices in the Input Models

The advice as well as the computed value obtained during the software execution must be reported in the input model. Thus, the model designer can directly access the advice reported on the element requiring the modification. For the information feedback, the reduced trace produced during the transformation chain execution is used.

The UID contained in the computed advice refers to elements in the last model before the code generation. This UID comes from the Profiling Logs and it is retained even after transformations. Once the element referred by the UID is found, the reduced trace is backward navigated in order to recover the input elements producing the profiling information. Two cases can occur. The retrieved elements are reduced to one or several. Indeed, a simple element in the last model can be produced from either one or many elements in the input models.

Reporting the advice on all retrieved elements can create confusion. To solve this issue, the expert system can be configured to specify some element types of the input metamodel for each libraries. From this way, only the input elements of the specified types are kept. Finally, the computed advice is connected to these elements in the input models.

In the UML-MARTE to OpenCL transformation chain, we decide to use the Comment concept from UML. Indeed, this concept element has the ability to gather an information in a string format. Moreover, Comment can be linked to any kind of UML element what places it as a perfect candidate for carrying the advice computed by the expert system. As the advice representation is quite dependent from the input metamodel and the input metamodel capabilities, it could be be provided using an other concept.

Example and Benchmarks

In order to illustrate the practical application of the approach proposed in this paper, we describe a case study. This case study is a complete example which presents an application design, code generation and the profiling feedback.

In this example the goal is to offer information and compute an advice about how improving the processors' occupancy. This will help the application designers to identify input elements parameters which they can modify aiming better results.

Vector Product Application

The example presented in this section is a vector product. For pedagogical reasons, we chose this simple operation that does not require further knowledge in more complex applications such as signal processing or numerical analysis to be understood. Nevertheless, it gathers all the relevant concepts to illustrate our approach. Moreover, we have also tested our approach on large scale examples like the classic downscaler algorithm [START_REF] Rodrigues | Programming Massively Parallel Architectures using MARTE: a Case Study[END_REF]. The vector product is an algebraic operation that takes two equal-length(N ) sequences of numbers and return another sequence obtained by multiplying corresponding entries. A sequential code sample in C language for this operation is showed in the listing 1.

Listing 1: Code Snippet for the Application

f o r ( u i n t i =0; i <N; i ++) c [ i ] = a [ i ] * b [ i ] ;
We have created the UML-MARTE model (see Figure 9) for this application using the Papyrus [START_REF] Cea | Papyrus -Open Source Tool for Graphical UML2 Modeling[END_REF] modeling tool. Elementary tasks TE_genarray1, TE_genarray2, and TE_printarray are responsible for generating and printing vectors. As these tasks comprehend the application interface (data input and output), they are run by the CPU. The application's vectors are arrays of 16,000,000 elements. We have chosen this large number to take advantage of the massively parallel processors provided by GPUs. The composed component ForDevices instantiated in the program consists of a repetitive task ep:TE_elemprod. In our application, this kind of task is composed by operations on single elements. Repetitive tasks are potentially parallel and are allocated onto GPU. The repetition shape of the task in this case is {16,1000000}, i.e. the task operation runs 16 millions times on one element of each vector whose size equals 16 millions. This shape has two dimensions: 16 and 1,000,000. The total of work-items is calculated by multiplying these two dimensions. The first one becomes the number of workitems and the second one the number of groups. The definition of this shape is a decision of the designers and usually they take into account the Intellectual Property (IP) interface associated to the elementary task and its external tilers (see subsection 4.1). Moreover, considering that, in compute capability 1.x devices, memory transfers and instruction dispatch occur at the Half-Warp(16 work-items) granularity, it is reasonable to define groups composed by 16 workitems at a first try.

Figure 10 presents the allocation process for the repetitive task, i.e. it defines which devices will manage a task. For instance, the ep: TE_elemprod task (also visible in Figure 9) will be run by the GPU (gpu: GPU instance).

RR n°7720

Similarly, the memory mapping process is also defined for the communication ports. According to Figure 10, the communication ports will be managed by the GPU memory (gpumem: GPUMEM ). Thanks to the task allocation process, the model compiler identifies OpenCL kernels. The memory allocation step is also important because it creates host and device variables and organizes the data transfers.

Once the application is designed with all necessary well configured elements, we generate all source code files necessary to the target compiler. In addition, trace models are generated for each model-to-model transformation thanks to the traceability mechanism.

Listing 2 shows the code only for the kernel. This is a generated code composed of two functions: the IP function, represented on lines 1-4, and the kernel function (lines 6 to 60). The UID value (see section 6) is identified from the last generated model in the UML-MARTE to OpenCL transformation chain and is concatenated to the kernel name. From line 6 we identify, concatenated to kernel name, the UID _uCQs6obGEeCiXMyak_whYg . This UID is the link between the code and the model elements whenever they have to be referenced. The rest of the code consists of private variable declarations (line 12), a limit control to avoid overlapping data bounds (lines [START_REF] Lugato | Model-Driven Engineering for High Performance Computing Applications[END_REF][START_REF] Rodrigues | An MDE Approach for Automatic Code Generation from MARTE to OpenCL[END_REF][START_REF] Rodrigues | Programming Massively Parallel Architectures using MARTE: a Case Study[END_REF][START_REF] Olsen | Scenarios of Traceability in Model to Text Transformations[END_REF], two input tilers to gather the elements from global memory (lines 18-43), the IP call (line 45); and an output tiler writing the result into global memory (lines 47 to 56).

Profiling Feedback

We used the following configuration as platform for our tests:

• CPU AMD Opteron 8-core @2.4GHz and 64GB RAM;

• GPU NVidia S1070 4 devices Tesla T10 (4GB RAM each) -Compute Capability 1.3;

• Linux, GCC 4.1.2, OpenCL 1.0.

Among all the measures coming from the profiler, the kernel occupancy factor has an important impact on performance. Usually the aim at executing a kernel is to keep the multiprocessors and, consequently, the device as busy as possible.

The work-items instructions are executed sequentially in OpenCL, and, as a result, executing other warps when one warp is paused or stalled is the only way to hide latencies and keep the hardware busy. Some metric related to the number of active warps on a multiprocessor is therefore important in determining how effectively the hardware is kept busy. This metric is called occupancy. The occupancy is the ratio of the number of active warps per multiprocessor (WPM) to the maximum number of possible active warps. Another way to view occupancy is the percentage of the hardwareâĂŹs ability to process warps that are actively in use. Hence, higher occupancy does not always equate to higher performance, there is a point above where additional occupancy does not improve performance. However, low occupancy always interferes with the ability to hide memory latency, resulting in performance degradation.

The important features to compute the occupancy and that vary on the different compute capability are:

• the number of registers available;

• the maximum number of simultaneous work-items resident on each multiprocessor;

• and the register allocation granularity.

The number of work-items resident on a multiprocessor relies on index space as known as N-Dimensional Range (NDRange). The MARTE to OpenCL chain obtains the information from the of the task which will become a kernel. Hence, changes in the dimensions of shape affect the occupancy. From the point of view of the proposed approach, occupancy is a specialized module that can be included to the expert system. For other analysis other specialized module can be added to attain specific goals. For this example, we analyze the occupancy of the multiprocessors. Occupancy is function of constant parameters (features) from device and some measures directly obtained from the profiler.

The process of calculating occupancy is implemented in a QVT transformation. This transformation takes two input models (according to Figure 6): the Device Features Database and the Profiling Logs. In this example the first one conforms to a metamodel based on NVidia GPUs (cf. Figure 8). Although this metamodel was designed according to vendor's features, it can be modified or extended to comply with other vendor device models. For instance, from the model presented in Figure 11 we see that the GPU Tesla T10 has compute capability equals 1.3 and is its warps contain 32 threads (or work-items in OpenCL terminology).

Benchmark

The profiling environment creates a log file in CSV format having some dynamic measured data (as seen in Figure 12). The file header contains data about the target platform. We deal with a Tesla T10 GPU in this case. The rest of the file consists in description of fields and log entries. The description of fields indicates in which order they will appear in a log entry. For instance, in Figure 12, a log entry begins with the timestamp field. The second field that can be retrieved in an entry is gpustarttimestamp, then method and the 13-th field that can be found in the log is the occupancy field. For our example, log entries about memory copies are not important (log entry with the method field sets to memcpyHtoDasync). The following entries in the log correspond to kernel calls. A shell-script parser takes this text file as input and converts it to XMI format that conforms to the profiling metamodel depicted in Figure 7. The model (Figure 13) created from the CSV log file gathers exactly th same information. Except the timestamp field and the UID contained in the method field that becomes attributes of the LogEntry, all the other fields (e.g. gputime, cputime or ndrangesizex ) are transformed into Parameter with the value of the log entry. Figure 12 (highlighted elements) and Figure 13 present the occupancy parameter with value 0.250 for the kernel call with timestamp equals 1283955.000. # OPENCL_PROFILE_LOG_VERSION 2.0 # OPENCL_DEVICE 0 Tesla T10 Processor # OPENCL_PROFILE_CSV 1 # TIMESTAMPFACTOR fffff6f3dd57cd20 timestamp,gpustarttimestamp,method,gputime,cputime,ndrangesizeX,ndranges izeY,workgroupsizeX,workgroupsizeY,workgroupsizeZ,stapmemperworkgroup,re gperworkitem,occupancy,streamid,local_load,local_store,gld_request,gst_r equest,memtransfersize,memtransferdir,memtransferhostmemtype 698239.000,1220f847c305ce40,memcpyHtoDasync,40347.039,41886.000,,,,,,,,, 1,,,,,64000000,1,0 1241546.000,1220f847e367f960,memcpyHtoDasync,40539.457,41379.00 0,,,,,,,,,1,,,,, Although our methodology does not impose a rigid workflow, our approach relies on two major activities: first we run the code exactly as it is generated from the original input model, then the application designer analyzes the runtime behavior based on profiling feedback annotated on the input model; second, the designer, taking into account the provided information and hints, modifies the model aiming to obtain better results. Once the model is modified, the code is again generated and then executed in order to verify the result of theses changes.

For this example the first running gives the results seen in Table 1. The application launches 1 million groups of 16 work-items onto the device. However, a hardware limit imposes a maximum of 65535 groups by kernel. Thus, for the whole execution, 15 kernels are launched with the maximum of 65535 groups and 1 kernel is launched with 16975 groups. Summarizing, the last line in table shows that this configuration gives 16 kernels calls and only 25% in the multiprocessor occupancy. Moreover, this configuration take 2.55% of the GPU time. The other part of the time comprehends data transfers and idle states. The launch grid (NDRange) has a two-dimensional size (i.e., how many groups and how they are organized). Each group has a three-dimensional size (represented by [16 1 1] on third column). However, only the first dimension is used in this example. Our goal is to increase the occupancy and decrease the relative GPU time. By using our approach results are combined with GPU features and this returns a smart advice as comment in the input UML-MARTE model (Figure 14). Besides the performance parameters available directly on the comment, a hint points out a possible change in the model to improve the generated code. Additionally, the advice provides an image reference of a chart (as seen in Figure 15) for all predicted occupancy according to these results. In this case it is suggested to change the task shape from {16, 1000000} to {128, 125000}. A simple analysis seeks the first block size giving 100% on occupancy as seen in Figure 15. For instance, the expert system automatically highlights the first (block size=128) and second (block size=256) maximum values in the chart. 2 presents the profiling results for the code generated from the modified input model. For this case, we have two kernel calls, 100% on occupancy and a reduction to 1.07% on the GPU time. As expected, the modified model achieves better performance than the original one. Figure 16, obtained from a visual profiler provided within NVidia tools, shows us that, without modifications, the whole execution of the kernel is about 146% slower.

Calls

Calls

For each operation, the first bar is related to the time measured from the optimized models, whereas the second bar is related to the time measured from the initial models. The transfer times presented in Figure 16 correspond to the following operations:

• memcpyDtoHasync is called once in both executions. This transfers the result vector from device to host. • memcpyHtoDasync is called twice in both executions. This transfers the two input vectors from host to device.

As we have changed only the task shape, transfer times do not have any expressive alteration. In this paper we address performance improvements as part of the life cycle of the application design and execution. We provide a high level profiling environment for OpenCL in the context of the Gaspard2 framework. This environment allows the model designers to efficiently modify their models to achieve better performances. The profiling environment is based on two main artifacts: an expert system and a traceability mechanism.

The expert system proposed here uses data from a feature database dedicated to the runtime platform and profiling logs. The aim is to compute a smart advice explaining how the model should be modified in order to achieve better performances. From the point of view of the application designers, they do not necessarily need to know complex details about the runtime platform. Moreover, no performance specification is given in advance. The expert system summarizes the profiling logs and minimizes the tasks of the model designer by analyzing the gathered profiling data.

Specially for GPU applications, better performances rely on speed-up, memory use and processor occupancy. In order to provide this feedback, this paper proposed to retain coherence between code generation and traceability. Thus, the expert system uses the traceability to return a UML Comment consisting of a computed smart advice and profiling logs on the specifics input models elements that involve the analyzed performance issue.

Although our case study is focused on applications GPU, our approach can be adapted to other environments with code generation and profiling tools. Indeed, the library that is part of the expert system can be extended aiming to analyze other issues or other devices. Moreover, the traceability mechanism that we provide can fit to any transformation chain. Thus, the library of the expert system is the only artifact that requires additions in order to deal with other languages or other performance issues. For instance, memory bottleneck footprints in applications can be explicitly annotated onto links between ports. This helps developers to identify critical points in their applications.

As future direction for our approach, we aim a semi-automatic modification of the input models using the advices returned in the input model. Hence, input models could be incrementally modified until the performances are considered acceptable by the model designer.

KFigure 1 :

 1 Figure 1: OpenCL Platform and Memory Model

1 #

 1

Figure 2 :

 2 Figure 2: OpenCL Transformation Chain[START_REF] Rodrigues | An MDE Approach for Automatic Code Generation from MARTE to OpenCL[END_REF]

Figure 3 :

 3 Figure 3: Local Trace Metamodel

Figure 4 :

 4 Figure 4: Global Trace Metamodel The global trace gathers references towards local trace and models used in a transformations chain while keeping the order induced by the chain. The local traces are represented by the TraceModel concept which is directly associated by the localTrace reference to a local trace root (the LocalTrace element from the local trace metamodel). Each TraceModel is linked to the models LocalModel used by the transformation.

Figure 5 :

 5 Figure 5: Trace Reduction Principle

Figure 6 :

 6 Figure 6: Approach Overview

Figure 8 :

 8 Figure 8: GPU Device Features metamodel

Figure 9 :

 9 Figure 9: Vector Product Application Model

Figure 10 :

 10 Figure 10: Task and Memory Allocations onto GPU

Listing 2 :

 2 Generated Kernel1 void e l e m p r o d ( c o n s t f l o a t * a , c o n s t f l o a t * b , f l o a t * c s t __global f l o a t * v2_ep_KRNPAR, 9 __global f l o a t * vout_ep_KRNPAR , 10 c o n s t __global f l o a t * v1_ep_KRNPAR) 11 { 12 f l o a t v1_ep [ 1 ] ; f l o a t v2_ep [ 1 ] ; f l o a t vout_ep [ 1 ] ; 13 // g e t i n d e x i n t o g l o b a l d a t a a r r a y 14 i n t iGID = g e t _ g l o b a l _ i d ( 0 ) + 15 g e t _ g l o b a l _ s i z e ( 0 ) * g e t _ g l o b a l _ i d ( 1 ) + 16 g e t _ g l o b a l _ s i z e ( 0 ) * g e t _ g l o b a l _ s i z e ( 1 ) * g e t _ g l o b a l _ i d ( 2 ) ; 17 i f ( iGID < iNumElements ) // bound c

Figure 11 :

 11 Figure 11: GPU Device Features Database Model

Figure 12 :

 12 Figure 12: Sample profiling results in CSV format

Figure 13 :

 13 Figure 13: Profiling Results Model

Figure 14 :

 14 Figure 14: Annotated Model

Figure 15 :

 15 Figure 15: Occupancy by Varying Block Size

Figure 16 :

 16 Figure 16: Comparison Summary Plot from Visual Profiler

000,1220f847e5e6a2c0,ep_KRN__uCQs6obGEeCiXMyak_whYg,1238.752,147 0.000,65535,1,16,1,1,32,11,0.250,1,0,0,4370,2185 1285577

  64000000,1,0 1283955..000,1220f847e5fee540,ep_KRN__uCQs6obGEeCiXMyak_whYg,1237.120,142 8.000,65535,1,16,1,1,32,11,0.250,1,0,0,4368,2184 1287138.000,1220f847e616bd40,ep_KRN__uCQs6obGEeCiXMyak_whYg,1237.600,143 7.000,65535,1,16,1,1,32,11,0.250,1,0,0,4370,2185 ...

Table 1 :

 1 Profiling results for the non-optimized code

	#	NDRange WGSize Occup. GPUTime
	15	[65535 1] [16 1 1]	25%
	1	[16975 1] [16 1 1]	25%
	16	[1000000 1] [16 1 1]	25%	2.55%

Table 2 :

 2 Profiling results for the new code Table

		# NDRange WGSize Occup. GPUTime
	1	[65535 1] [128 1 1]	100%
	1	[59465 1] [128 1 1]	100%
	2	[125000 1] [128 1 1]	100%	1.07%

runtime results point out 25% on multiprocessor occupancy. If you want to achieve better results, try to change the task shape from {16,1000000} to {128,125000}. Moreover, your kernel takes 20 registers which is a high value, maybe your IPs can be optimized regarding the variable denition. Occupancy Chart: CHART.PNG

	Gaspard2 Proling and Traceability Framework
	Internal Kernel Launches: 16
	GPU Time: 2.55%
	Grid (x,y): 1000000,1 ; Block Size (x,y,z): 16,1,1
	Registers per WorkItem: 11
	Occupancy: 25%
	Hint: Your

RR n°7720

In this context, model is not associated with MDE.RR n°7720

This relies on scheduling for clustered processors that involves spatial concerns (where to schedule) as well as temporal concerns (when to schedule).RR n°7720

A warp is a GPU related concept that indicates the number of work-items in a work-group ready to hardware scheduling. It is also known as wavefront.RR n°7720