Manuel Selva

Lionel Morel

Kevin Marquet

Stephane Frenot

A Monitoring System for Runtime Adaptations of Streaming Applications

Streaming languages are adequate for expressing many applications quite naturally and have been proven to be a good approach for taking advantage of the intrinsic parallelism of modern CPU architectures. While numerous works focus on improving the throughput of streaming programs, we rather focus on satisfying quality-of-service requirements of streaming applications executed along-side non-streaming processes. We monitor synchronous dataflow (SDF) programs at runtime both at the application and system levels in order to identify violations of quality-of-service requirements. Our monitoring requires the programmer to provide the expected throughput of its application (e.g 25 frames per second for a video decoder), then takes full benefit from the compilation of the SDF graph to detect bottlenecks in this graph and identify causes among processor or memory overloading. It can then be used to perform dynamic adaptations of the applications in order to optimize the use of computing and memory resources.

I. INTRODUCTION

The traditional threading model exposes little parallelism and does not suit the programmer needs to program multiand many-core architectures. In order to address this issue, one mean is to use a streaming programming paradigm, the advantage being that different levels of parallelism are made explicit in the program.

This paradigm has been proven useful in a large number of domains including networking, video, sound, graphics, cryptographic tools, or digital signal processing. With the advent of mobile computing, such applications are increasingly useful and, consequently, a lot effort has been put in the past decade to maximize the throughput of dataflow applications. However, for a majority of these applications, maximizing the throughput is not what the end user wants. Rather, it is usually not useful to go far beyond a minimum throughput requirement. For instance, if a video decoder satisfies a throughput of 25 frames per second, the goal is reached. In some cases, it can even be counter-productive to run very fast as it can result in energy waste. In this paper, we propose solutions to maintain, at runtime, a throughput close to the requirements for these dataflow applications, while standard applications (i.e. non described in a dataflow way) start and stop dynamically.

In order to optimize the use of computing resources, two types of approaches are traditionally investigated depending on the nature of the programming model. First, lots of optimizations have been proposed to take advantage of the Synchronous Dataflow (SDF) model of computation [START_REF] Lee | Synchronous data flow[END_REF] (aka Static Dataflow). In SDF graphs, not only the communication channels -defining which actors communicate together -are explicit, but the communication rates -how many items are read and written each time an actor is executed -are known. This information can be used by the compiler to perform static optimizations. Typically, a balanced distribution of the actors on available processors or cores can be computed [START_REF] Gordon | Exploiting coarse-grained task, data, and pipeline parallelism in stream programs[END_REF]. However, this requires to compute average execution times, which is impossible in a context where other, non-dataflow, applications start and stop dynamically.

Second, in the case of dynamic dataflow models of computation [START_REF] Lee | Dataflow process networks[END_REF], actors consumption and production rates are not known statically. Runtime mechanisms need to be developed to maximize the application's throughput [START_REF] Min | Danbi: dynamic scheduling of irregular stream programs for many-core systems[END_REF].

In this paper, we combine SDF static optimizations with properties of dynamic runtimes. We propose to take advantage of information included in static dataflow graphs and to use it at runtime to maintain quality-of-service requirements expressed by the programmer. Our proposal is sketched in Figure 1. The contributions we make are:

• An extension of the StreamIt language [START_REF] Thies | Streamit: A language for streaming applications[END_REF] allowing a programmer to specify an expected throughput for its applications(s); • An extension of the StreamIt compiler able to propagate the expected throughput to each actor of the graph. This is possible only in SDF programs;

• An application monitor able to check at runtime whether the throughput of each streaming application (denoted StreamApp in Figure 1) is respected or not; • A system monitor able, in case of non-respect, to identify the origin of the bottleneck: CPU, memory latencies; • An adaptation mechanism able, with regards to previous observations, to change the placement of actors on the cores/processors, change the placement of FIFOs in memory, and adapt the batching; • A performance evaluation of the mechanisms described above. The rest of this paper is organized as follows. Section II provides the reader with necessary background concerning SDF languages, their compilation and runtime support. Section III presents extensions we propose to the StreamIt language, its compiler and runtime. Section IV presents our runtime monitoring that includes both application and system monitoring facilities. Section V presents experimental results to validate our proposal. Finally, Section VI gives an overview of related work while Section VII concludes and gives perspectives.

II. BACKGROUND A. SDF

We consider programs to follow the SDF model of computation [START_REF] Lee | Synchronous data flow[END_REF]. An SDF program is a graph of actors communicating only through FIFOs: an actor can pop data tokens from its input queues or push tokens to its output queues. But it can have no other side effect on its environment (e.g. no global variables). In contrast with more general Dataflow Process Networks [START_REF] Lee | Dataflow process networks[END_REF] or Kahn Process Networks [START_REF] Kahn | The semantics of a simple language for parallel programming[END_REF], the number of tokens read from input queues (resp. written to output queues) of SDF actors is fixed at compile-time. This information leads to static schedulability. Using the static consumption and production rates, a dataflow compiler first computes a repetition vector, denoted q in the remainder of this paper. This vector defines the number of times each actor must be executed so that the number of tokens in all the FIFOs of the application falls back to its initial state [START_REF] Lee | Synchronous data flow[END_REF]. From this repetition vector, the compiler computes a steady-state schedule or iteration that satisfies actors' data dependencies. This schedule consists of a sequence of components; each component act x indicating to execute actor act x times before the next component. The SDF example of Figure 2 would have the following repetition vector q and s1 and s2 as two valid steady-state schedules:

q = (1, 1, 1, 3, 4, 1) ; for actors (A, B, C, D, E, F ) s1 = A 1 B 1 C 1 D 3 E 4 F 1 , s2 = A 1 B 1 C 1 D 1 E 2 D 2 E 2 F 1
In the remainder of this paper, we use the following notations : q(act) denotes the entry corresponding to actor act in the repetition vector; outRate(act, out) denotes the number of tokens that actor act produces on each activation on output FIFO out; activ(comp) denotes the number of activation of a component comp in the steady-state schedule, i.e. activ(act x ) = x. We consider only consistent SDF graphs as defined by Lee [START_REF] Lee | Synchronous data flow[END_REF].

If several cores (or CPUs) are available, the compiler is likely to balance the execution of the components on different cores. In this case, at runtime, components synchronize either on FIFOs or on a barrier as described in Section II-C. Also, note that actors can be executed in parallel by exploiting the inherent pipeline parallelism provided by the dataflow model: in our example of Figure 2 once actor A has produced a first token, C can start working with this token while A starts working on producing a second token.

B. Multi and many-core target platforms

In this work we target multi-and many-core processors with shared memory. These architectures are today standard in markets ranging from mobile systems to servers. Alongside the programability problem mentionned in the introduction, the complexity of these architectures, in particular of their memory hierarchy introduces tremendous difficulties for the evaluation of programs performances. As the number of cores keeps increasing, hardware providers are more and more using Non Uniform Memory Access (NUMA) architectures to alleviate the memory wall. Figure 3 shows the global architecture of an Intel Xeon X5650 dual socket platform released in 2011, that we use in our experiments. On such NUMA hardware, improving the performance of programs is even more difficult. In the architecture of fig. 3, for a program that executes on core 1, accessing data stored in memory bank 2 is typically 25% slower than accessing data stored in memory bank 1. Additional care must thus be taken by the software to limit remote memory accesses [START_REF] Molka | Memory performance and cache coherency effects on an intel nehalem multiprocessor system[END_REF], [START_REF] Dashti | Traffic management: A holistic approach to memory placement on numa systems[END_REF] in particular in the case of memory-intensive programs.

C. Execution of SDF programs over thread-based APIs

We assume that the underlying operating system provides a threading programming model. In this context, an efficient way of executing SDF programs, as done in StreamIt [START_REF] Gordon | Exploiting coarse-grained task, data, and pipeline parallelism in stream programs[END_REF] consists of assigning one thread to each core and map actors to threads. As shown in Figure 4, the compiler initially balances actors among t threads where t is the number of cores of the targeted

A 1 D 3 E 4 B 1 C 1 F 1
Threads Time Fig. 4: Static load balancing with estimated execution times.

platform. Here we have t = 2 on the example for readability. The runtime engine pins each thread on a specific core. Each one has an associated list of pointers to the execution function of each actor. A thread iterates over this list to execute the actors and then synchronizes on a barrier. Once all threads have completed one steady-state iteration, the runtime layer can safely start the next one, without loosing any data. FIFOs are implemented as fixed size arrays shared by all the threads of the application.

III. LANGUAGE, COMPILER AND RUNTIME SUPPORT

This section describes how a global expected throughput can be added to a stream application, and how the compiler can compute an expected throughput for each actor. Finally, it describes our extension to the aforementioned runtime to include monitoring and adaptation capabilities.

A. Language support

In the remainder, we consider SDF applications to have exactly one output flow. This is not necessarily the case in real-life applications. For programs with multiple output flows, the expected throughputs expressed on different output flows need to be consistent with each other. Due to the static nature of SDF progams, this is easily verified at compile-time.

Our proposal applies to all SDF languages, provided that it is possible to specify an expected throughput. In our case, we extend the StreamIt language. The developer specifies a global expected throughput for his application. This throughput for an application app is noted τ G exp (app). It is a simple integer specifying for the output edge of the graph, the number of tokens that must be produced on this edge per second.

B. Throughput propagation

From the throughput given by the programmer, the compiler computes, for each actor, the rate at which this actor must output items. Such a rate is called local expected throughput. Figure 5 illustrates this on our toy example of Figure 2. In the remainder of this article the local expected throughput of an actor act on its output arc out is noted τ L exp (act, out). The propagation done by the compiler for an application app consists of computing the frequency at which all the actors have to be fired in order to satisfy the global throughput. For a given actor act, this required frequency is noted f r (act) and the local expected throughput is computed using equation 1, below. Equation 2 defines f r (sink), sink being the actor Fig. 5: τ G exp is given by the programmer; the compiler propagates it to compute τ L exp (act, out) for all channels and attaches the information to the application for the runtime. from which starts the output channel e on which τ G exp (app) is defined.

τ L exp (act, out) = f r (act) * outRate(act, out) (1)
f r (sink) = τ G exp (app) outRate(sink, e) (2)
From this, the required frequency of each actor act can be computed using the number of activation of act to the number of activation of sink in the repetition vector as shown by equation 3.

f r (act) = f r (sink) * q(act) q(sink) (3)
From the activation frequency required for one actor, the compiler easily computes the frequency required for one component comp of the steady-state schedule using equation 4.

f r (comp) = f r (act) * q(act) activ(comp) (4)
In the execution model we use, each thread executes several actors and synchronizes with others with a steady-state barrier. As a consequence, τ L exp (act, out) values can't be used as is by the runtime. Indeed, an actor being too slow will slow down the entire application, leading to the impossibility to identify the bottleneck actors by their throughput alone. Therefore, using the local expected throughput of each actor, we compute its expected execution time, noted κ exp (act) using equation 5. This expected execution time will be used at runtime to identify actors that are too slow.

κ exp (act) = outRate(act, out) τ L exp (act, out) (5)

C. Runtime Support

We extend the runtime of Section II-C so that it handles several streamit applications. The information obtained by the throughput propagation of Section III-B is attached to each application, and includes its global expected throughput and a local expected throughput for each actor.

Figure 6 shows an overview of our runtime. The streaming applications execute on top of a mainstream operating system (Linux in this instance) alongside non-dataflow applications. Streaming applications are compiled to n -1 threads where n is the number of cores of the hardware. Two components, detailed in the next section are part of the runtime. The Monitor running in a dedicated thread pinned on the first core keeps track of how much resources are allocated to dataflow applications and how these resources are used by the actors. We extend the StreamIt compiler in order to generate monitoring code that will be activated on demand by the runtime. The Adapter implements adaptation heuristics based on monitoring results. It is called on-demanded from the Monitor thread and also executes on the dedicated core. To support the Adapter, the runtime layer provides a way to suspend and resume dataflow applications either individually or globally. It also implements migration mechanisms. To migrate actors between cores, function pointers are moved between threads. To migrate FIFOs, we rely on mechanisms of the underlying operating system providing a way to migrate memory pages between memory banks.

IV. RUNTIME MONITORING

The runtime monitor is responsible for 1) determining if throughput constraints are satisfied or not; 2) identifying which actors in the graph are the bottlenecks and 3) distinguishing between CPU and memory contentions. This section describes conditions under which the runtime layer starts monitoring actors' activity and how it identifies bottleneck actors and impacted resources. Figure 7 gives an overview of the monitoring process for one dataflow application.

This monitoring process is carried out by a specific thread running on a dedicated core as shown on Figure 6 obs (app) as described in Section IV-A. When the throughput reaches the local monitoring threshold τ G exp (app) + δ the monitoring thread enters in stage 2 described in Section IV-B by activating local monitoring for a given duration called the local monitoring period. During this period, each dataflow threads records information about its actors execution times. At the end of the local monitoring period, depending on the existence of bottleneck actors or not, the monitoring thread either enters stage 3 where it performs memory monitoring as described in Section IV-C, or stage 4 where it performs CPU load monitoring as described in Section IV-D. Both stages have a monitoring period, and at the end of this period the monitoring thread invokes adaptation mechanisms described in Section IV-E.

A. Monitoring the global throughput

In order to check at runtime if the throughput expected for an application is obtained, monitoring code is generated in the sink actor. This code consists of a mere counter increment.

By checking periodically the value of this counter, the runtime layer computes the global observed throughput of the application noted τ G obs (app). If it is too low (this criterion is detailed later), some more precise monitoring is performed.

Overhead from this monitoring system comes from two places. Incrementing a counter each time data is written on the channel where τ G obs is expressed is negligible. The overhead of the simple arithmetic used to compute τ G obs on regular interval using the counter is also negligible since the monitoring thread is executing on a separate core.

B. Monitoring local execution times

The compiler generates some code that computes the observed execution time noted κ obs (act) for all the actors of the graph. This time represents the execution time of actors only. It excludes preemption time. We rely on timing system calls provided by the underlying operating system for these measurements. Timing measurements are performed before and after the loop executing each component. To compute the average κ obs (act), we divide the measured time by the number of times the actor act has been fired in the component. Measuring outside the loop allows to reduce the number of system calls and thus the overhead introduced by timing measurements. Section V evaluates the overhead of these system calls on our test platform.

As shown on Figure 7, the runtime activates the local monitoring only when τ G obs (app) is getting close to τ G exp (app) to identify eventual bottleneck actors. Deciding when the local monitoring should be triggered (i.e. the value of δ in Figure 7) is discussed in Section V.

At the end of the local monitoring period, the κ obs (act) for each actor is compared to its κ exp (act) to tag the bottleneck actors. When all actors respect their expected execution time, that means the dataflow threads are badly balanced and the Monitor must identify why. This is discussed in Section IV-D. Otherwise (there is at least one actor with κ obs (act) greater than κ exp (act)), the actors being too slow are known, but

A 1 D 3 E 4 B 1 C 1 F 1

Threads Time

Lost

(a) Result with measured real execution times (F is faster than estimated). the Monitor also needs to identify why. See Section IV-C for details on the latter.

C. Bottleneck actors

In the case where we have identified the bottleneck actors (bottom left branch of Figure 7), we must identify why these actors are too slow. On the homogeneous CPU architectures we target, we may only be able to speed up actors by reducing memory access times. As stated in Section II-C, communication is implemented over shared memory. As a consequence, many of the memory accesses performed by actors correspond to inter actors communications. Memory requests also include accesses to actors internal variables required during actor firing.

To identify potential memory bottlenecks, our runtime provides low-level memory monitoring based on hardware performance monitoring unit (PMU). This hardware, present on Intel, AMD and ARM processors, provides low-level information about the usage of hardware resources with a very low overhead. Using the PMU in counting mode, we identify if one or more memory controllers and one or more memory links are overloaded. If we find that one of the memory controllers used by a bottleneck actor is overloaded, we know that communication and local memory accesses time could be reduced by alleviating the load of the controller. Using the performance monitoring hardware in sampling mode along with the knowledge of the dataflow graph, the runtime is able to establish a memory profile for each actor of the graph. This memory profile can be used by a memory adaptation heuristic to alleviate memory controllers and memory links overload.

D. Dataflow threads imbalance

When the global throughput is too low and all actors respect their execution time (bottom right branch of Figure 7), we know that we are facing at best a core imbalance, at worst a globally overloaded system. Two different things may cause an imbalance. First, a wrong estimation of actors execution time used during compilation may lead to imbalance between cores, resulting in cores more loaded than others. The underloaded cores will thus loose time in the steady-state barrier as depicted on Figure 8a.

The second kind of situations leading to cores imbalance are scenarii where the dataflow applications share core(s) with other applications taking resources that the compiler could not have been aware of. This situation is depicted on Figure 8b. On the first core, dataflow actors are preempted resulting in a longer steady state. As consequence the two dataflow threads are imbalanced and available processor time is lost on the second core where the second dataflow thread is pinned.

In both wrong estimation and preemption cases we need to identify the cores which are overloaded and the ones which are under-loaded. For this purpose we again rely on the underlying operating system. On Linux, we read the /proc/stat virtual file to get this information at the start and at the end of the monitoring period.

E. Towards Runtime adaptation heuristics

Using runtime mechanisms allowing to migrate actors between threads pinned to cores, and to migrate FIFOs between memory nodes we are able to implement adaptations heuristics. For now, we only implemented a simple heuristic consisting of migrating actors from the most overloaded core to the one with the lowest load in the context of a single dataflow application running along with non-dataflow applications. act = nextHeaviestActor(ovldCore) 10: end while Algorithm 1 shows this runtime heuristic. It moves actors between the core with the highest CPU load to the one with the lowest CPU load using actors measured execution times to minimize the difference of work amount between theses two cores. The getLoad() function is the result of cpu load monitoring stage described in Section IV-D and the nextHeaviestActor(int core) function returns actors in decreasing execution time order (i.e. the actor with the largest κ obs value is returned first).

Algorithm 1 CPU load balancing

Designing more complex heuristics benefiting from our system-level monitoring is left to future work.

V. EXPERIMENTAL RESULTS

We now present the results of our dataflow framework under different scenarii illustrating the different kinds of bottleneck dataflow applications may face. We use StreamIt applications from [START_REF] Thies | An empirical characterization of stream programs and its implications for language and compiler design[END_REF]. The experiments were conducted on a workstation running Linux 3.11 on top of two Intel Westmere-EP processors. Details are shown on table I.

Hyperthreading is disabled in all the benchmarks resulting in a total of 12 cores visible by the software. StreamIt applications used in the experiment are compiled to 10 threads. We keep core 0 available for running all the system's processes and the benchmark scripts in order to minimize the operating system impact on the experimental results. As mentioned in Section IV, the monitoring thread is running on a dedicated core (core 1).

A. Scenario 1: Reaction to preemption by other applications

In this scenario, we run one StreamIt application with an attached throughput constraint along another non-dataflow application introduced in the system. For the applications used in this scenario, κ obs (act) values are smaller than κ exp (act) values for each actor, i.e. we are not facing bottleneck actors. In this scenario, we first run the application alone on the system and save the value of τ G obs (app) at an arbitrary frequency of 20 Hz. Because the monitoring thread is running on a dedicated core, this frequency does not impact streaming applications performances but only changes the time before the runtime may react. Then, we run a non-dataflow application, in this case a compute intensive C benchmark, on core 5 for 10 seconds along with the dataflow application and see how our runtime reacts. The value of the δ parameter introduced in Section IV-B is set to 0. The study of how to compute this value is left to future work. We experimentally evaluated the value of the load balancing monitoring periods described in Section IV to 10 microseconds: with this value we are able to correctly identify the overloaded core.

Figures 9 and10 show the evolution of τ G obs (app) in tokens per microsecond for two applications (f f t and f ilterbank) over time along with the τ G exp (app) values and the perturbation introduction. f f t and f ilterbank being micro benchmarks, it's difficult to define realistic τ G exp (app) values. As a consequence these values have been choosen arbitrarily. Repeating the scenario several times leads to very small throughput variations but clearly shows the same phases. On both plots, we clearly identify three different phases. First, the application is launched without any perturbation showing a stable state. Even if we isolated system processes on core 0, some work is still done by the kernel on other cores resulting in minor variations on the throughput. Then for we clearly see a throughput drop when perturbation is introduced. Finally, after balancing we see that the throughput is reaching back an acceptable value. For both applications, because the perturbation introduced is CPU intensive, all the actors of the graph are moved away from the perturbed core. For f ilterbank, it results in a new throughput slightly lower than the initial throughput obtained without any perturbation. This is explained by the fact that this application is compute intensive with few communication between actors and scales well with the number of core. After rebalancing, it executes on 9 cores whereas it was previously executed on 10 cores, which makes a difference in terms of computations for this application. For f f t, the new throughput is higher than the original one. This is also explained by the scaling property of the application. f f t steady-state time is small and this application has a lot of communication. The application is thus more efficient when mapped to 9 cores than to 10 cores.

B. Scenario 2: Identification of bottleneck actors

In this scenario, we highlight the effectiveness of bottleneck actors detection mechanisms. For this purpose we changed the f ilterbank application used in scenario 1 in order to increase the execution time for the actor called combine with artificial computing code. In this case, as soon as the application is started, τ G obs is smaller than τ G exp and the local monitoring is started. Table II Once combine is identified as a bottleneck actor we start memory monitoring as described in Section IV-C. In this fictive scenario, our memory monitoring subsystem does not detect any memory bottleneck. The monitored memory throughput on the two memory controllers of platform is below 1 gigabyte per second whereas the theoretical maximum throughput is 32 gigabytes per second. The runtime then concludes that combine execution time can't be reduced using memory adaptations and is only able to report the bottleneck.

On our benchmarking platform, using combination of Streamit benchmarks we were not able to saturate the memory system. As discussed in the conclusion, we plan to run our memory monitoring system with real world dataflow applications on platform where memory latency vary more and where we are able to overload memory controllers.

C. Runtime monitoring and adaptation overhead

We now evaluate the overhead of the proposed mechanisms.

a) τ G obs : As stated in Section IV-A the overhead induced by the global monitoring system is negligible because we only add a counter increment to the original application and because the monitoring thread is executing on a separate core.

b) κ obs : To evaluate the overhead of local execution time monitoring we first evaluated the cost of the system call clock_gettime(CLOCK_THREAD_CPUTIME_ID) that we use to monitor actors execution time excluding preemption. On our platform, the system call average execution time is 170 ns. The overhead on our application is thus in theory 2 * 170 multiplied by the number of components in the steady state chosen by the compiler (the system call is made at the beginning and at the end of the component's execution). Table III Surprisingly, for 3 of the 4 applications shown on this table, activating local monitoring increases throughput. This is explained by the very short length of the steady-state (the synchronization time is greater than the steady state time for f mradio and audiobeam and equal to the steady state time for f f t). These applications spend a lot of time synchronizing on the steady-state barrier. Adding time measurement thus affects the synchronization time positively. For the f ilterbank application, the steady state is longer and is about 10 times the synchronization time spent on the barrier. In this case, adding time measurement increase steady state time and has a negative impact on the throughput reaching almost 4%. c) Rebalancing: Because we have to suspend actors execution while doing the adaptation, applications are not able to output any tokens during rebalancing. As a consequence, we have to minimize the time required to provide a new mapping of the application. Our simple first rebalancing algorithm has a complexity of O(n) where n is the number of actors. In our two examples of scenario 1, the average rebalacing times over 20 runs are 489 and 474 microseconds for f f t and f ilterbank respectively. We consider this time acceptable if the adaptation heuristic is not invoked too often.

VI. RELATED WORKS

There is substantial work in the literature relating to the efficient execution of SDF programs. A large portion of it concentrates on static scheduling and mapping of dataflow programs on multi-core architectures, especially for the StreamIt language [START_REF] Gordon | Exploiting coarse-grained task, data, and pipeline parallelism in stream programs[END_REF], [START_REF] Gordon | Compiler techniques for scalable performance of stream programs on multicore architectures[END_REF]. Mostly, these works make the assumption that the application considered will run standalone on the target platform. They also use user-provided execution times for balancing actors. In this way they are dependent on the precision of the information provided by the programmer and cannot cope with variations in the availability of resources.

The work of [START_REF] Tan | A hybrid static/dynamic approach to scheduling stream programs[END_REF] proposes a runtime for StreamIt programs able to balance actors on the available cores in order to maximize throughput. To do so, it measures actors execution time to adapt the static placement by taking runtime conditions in considerations. Our proposal extends [START_REF] Tan | A hybrid static/dynamic approach to scheduling stream programs[END_REF] to identify individual bottleneck actors and also to establish whether the slowdown comes from CPU or memory contentions which will eventually permit more sophisticated adaptation heuristics.

A technique to identify bottleneck actors is proposed in [START_REF] Collins | Flexible filters: load balancing through backpressure for stream programs[END_REF]. However its adaptation possibilities are defined by particular patterns specified statically. [START_REF] Choi | Adaptive task duplication using on-line bottleneck detection for streaming applications[END_REF] extends this approach by allowing for dynamic splitting of actors. The main limitation of both approaches lie in the fact that programs need to be acyclic. This is rather unrealistic since streaming applications often have feedback loops. Our proposition is valid on any SDF program. Moreover, both papers limit their bottleneck identification to execution times of actors.

Other works [START_REF] Albers | Qos management of dynamic video tasks by task splitting and skipping[END_REF], [START_REF] Albers | Task complexity analysis and qos management for mapping dynamic video-processing tasks on a multi-core platform[END_REF] propose a runtime for dataflow programs that is able to adapt applications in order to maintain pre-defined quality-of-service levels, on a platform presenting varying execution conditions. Adaptation schemes are however application-specific, i.e. the application designer needs to specify which actor can be split and which can be skipped.

Compilation strategies taking minimum throughput requirements into account have also been proposed. Various propositions can be found in [START_REF] Bonfietti | An efficient and complete approach for throughput-maximal sdf allocation and scheduling on multi-core platforms[END_REF], [START_REF] Carpov | Throughput constrained parallelism reduction in cyclo-static dataflow applications[END_REF], [START_REF] Damavandpeyma | Parametric throughput analysis of scenario-aware dataflow graphs[END_REF], [START_REF] Ghamarian | Parametric throughput analysis of synchronous data flow graphs[END_REF], [START_REF] Poplavko | Predicting the throughput of multiprocessor applications under dynamic workload[END_REF], [START_REF] Stuijk | Multiprocessor resource allocation for throughput-constrained synchronous dataflow graphs[END_REF] or [START_REF] Stuijk | Scenario-aware dataflow: Modeling, analysis and implementation of dynamic applications[END_REF]. These and all static optimization decisions found in the literature are complementary to our runtime proposals.

To our knowledge, our proposal is the first to complement application-level monitoring facilities (throughput in terms of tokens per time unit) with system-level (especially memoryoriented) monitoring to distinguish between CPU and memory contentions for bottleneck detection of dataflow programs.

VII. CONCLUSION

We have investigated how the information contained in Synchronous Dataflow graphs can be used to maintain, at runtime, some quality-of-service requirements. We have proposed a two level runtime monitoring approach which is able to 1) identify individual actors responsible for slowing down a dataflow application; and 2) pinpoint reasons of the observed loss in performances, be they due to processor or memory congestion.

The approach has been integrated to the StreamIt compiler and runtime. It has been experimented on a 12 cores platform, using several of the StreamIt benchmark programs. For all, it has shown its capabilities to identify the impact of systemwide perturbations on the managed application and the actual contentions at the system level, with a very low overhead.

This lays the path for several important future works. First, we plan to experiment our monitoring approach over platforms for which memory latency vary more and for which the placement decisions will have a greater impact. This will be a strong complement to existing compilation strategies that already take the underlying memory hierarchy into account, eg [START_REF] Sermulins | Cache aware optimization of stream programs[END_REF], [START_REF] Moonen | Cache aware mapping of streaming applications on a multiprocessor systemon-chip[END_REF], [START_REF] Farhad | Orchestration by approximation: mapping stream programs onto multicore architectures[END_REF], [START_REF] Farhad | Profile-guided deployment of stream programs on multicores[END_REF], [START_REF] Agrawal | Cache-conscious scheduling of streaming applications[END_REF].

As shown in Section IV, our monitoring mechanisms have an impact on the performance of applications. One way to reduce it would be to integrate these mechanisms into the operating system's kernel in order to remove system calls overheads. It will also allow future adaptation heuristics to be implemented with information about non dataflow applications running concurently to our dataflow applications.

Finally, and more importantly, we plan to apply our approach to streaming languages that implement more general dataflow models. Indeed, SDF can not be used to model many real-life applications for which input and output rates of actors vary dynamically, as a function of input values or actors' internal state. In the near future, we will therefor investigate the inclusion of our monitoring in the runtime of the RVC-Cal language, benefiting from both the maturity of the associated tools and the existence of realistic case studies. In this case, static information can not be used and the runtime needs to learn expected throughput, e.g. during system warm-up. We will also confront our approach to various runtimes that exist for dynamic dataflow [START_REF] Lee | Dynamic scheduling of stream programs on embedded multi-core processors[END_REF], [START_REF] Min | Danbi: dynamic scheduling of irregular stream programs for many-core systems[END_REF], [START_REF] Sanchez | Dynamic fine-grain scheduling of pipeline parallelism[END_REF], [START_REF] Miranda | Erbium: A deterministic, concurrent intermediate representation to map dataflow tasks to scalable, persistent streaming processes[END_REF].

Fig. 1 :

 1 Fig. 1: Overview of the proposal

Fig. 2 :

 2 Fig. 2: Example SDF Graph.

Fig. 3 :

 3 Fig. 3: Commodity NUMA hardware

  Fig. 6: Runtime Overview

Fig. 7 :

 7 Fig. 7: Monitoring stages overview

Fig. 8 :

 8 Fig.8: Limitations of static scheduling on the SDF graph of Figure5executed with steady-state schedule s1 on a dual core.

1 : 5 :

 15 ovld, ovldCore, unld, unldCore = getLoad() 2: toMove = (ovld -unld) ÷ 2, moved = 0 3: act = nextHeaviestActor(ovldCore) 4: while moved < toMove and act != null do if moved + κ obs (act) ≤ toMove then

Fig. 10 :

 10 Fig. 9: Scenario 1 -fft

  . At application startup time, monitoring stage 1 is automatically

			1	Monitor τ G obs (app)
				τ G obs (app) < τ G exp (app) + δ
		2	Monitor κ obs (act), ∀act ∈ app
	3	Actors too slow Monitor memory	CPU imbalance Monitor cores load 4
			Adapt	Adapt

¬∃act, κobs(act) > κexp(act) ∃act, κobs(act) > κexp(act)

TABLE I :

 I System configuration

  shows the average execution times for 3 actors at the end of the local monitoring period. The local monitoring clearly identifies the modified combine actor as a bottleneck actor: κ obs is almost five times longer than κ exp .

	Actor	κexp(µs)	κ obs (µs)
	fir filter	780	12.231
	combine	780	3508.678
	down sample	97.500	16.078

TABLE II :

 II Actors execution times

  shows the average experimental overhead over 20 runs computed by monitoring τ G obs with and without local monitoring activated.

	App.	τ G obs (tk/µs) τ G obs with local mon(tk/µs) Slowdown(%)
	audiobeam	2.04	2.44	-19.80
	fft	14.85	16.24	-9.36
	filterbank	12.69	12.48	3.65
	fmradio	3.82	3.88	-1.52

TABLE III :

 III Local monitoring overhead


Alors que le dispositif Scellier ne cesse de se resserrer -diminution du taux de la réduction d'impôt, révision des plafonds de loyers à la baisse, mise sous condition du report des fractions de réduction d'impôt non imputésl'élargissement du bénéfice de ce régime par la loi de finances pour 2010 aux logements situés dans des communes classées en zone C a pu sembler surprenante, d'autant qu'un arrêté du 30 décembre 2008 avait à l'origine expressément exclu ces communes du bénéfice de ce dispositif afin d'éviter les dérives qu'avaient connus les régimes précédents.

Cette mesure répond cependant à une préoccupation qui n'est pas nouvelle, celle d'assouplir un dispositif de zonage national perçu comme trop rigide et par nature difficilement perfectible.

Les tentatives de révision du classement des différentes communes n'ont jusqu'à présent pas été jugées suffisantes, l'arrêté de zonage du 29 avril 2009 n'ayant modifié que partiellement la cartographie antérieure. Quant à la suppression pure et simple du zonage, cette solution n'est pas non plus envisageable dans le contexte économique et social actuel.

Le maintien d'un zonage susceptible d'être affiné ponctuellement en fonction des besoins de chaque territoire est donc apparu à cet égard comme une solution de compromis tout à fait acceptable.

Déjà présenté dans le cadre de la discussion sur la loi de finances pour 2009, puis écarté en raison de l'opposition du Sénat, cet amendement a été finalement adopté dans le cadre de la loi de finances pour 2010 après avoir subi quelques aménagements. L'agrément n'est effectivement plus accordé par le préfet du département mais par le ministre en charge du logement, ce dernier ayant été jugé plus détaché des éventuelles pressions locales et plus susceptible d'avoir une vision globale du territoire. Quant au champ d'application de ce dernier, il n'a plus pour effet de rendre éligible au dispositif Scellier le seul programme immobilier soumis à projet, mais bien l'ensemble des logements d'une même commune.

La procédure mise en place par les textes d'application près de 9 mois après le vote de la loi de finances semble pourtant laisser présager que l'octroi de ces agréments risque bien de rester fort limité.

-Le dépôt de la demande d'agrément

La demande doit tout d'abord émaner de l'intéressée, à savoir la commune classée en zone C en application de l'arrêté prévu au dernier alinéa des articles 2 terdecies B et 2 terdecies C de l'annexe III du Code général des impôts. Si cette dernière est membre d'un établissement public de coopération intercommunal (EPCI) à qui la compétence en matière d'urbanisme a été déléguée, c'est cet établissement qui devra formuler la demande d'agrément. Ce dernier doit alors préciser quelles sont la ou les communes concernées par la demande d'agrément.

A -Les éléments constitutifs du dossier

Le décret précise que le dossier de demande d'agrément doit comporter un certain nombre de pièces :

 La délibération du conseil municipal ou de l'organe délibérant de l'EPCI autorisant le maire ou le président de l'EPCI à présenter la demande ;  L'avis du maire ou du président de l'EPCI pétitionnaire accompagné de l'avis des maires des communes faisant l'objet de la demande présentée par ce dernier ;  La désignation de chaque commune sur laquelle porte la demande, avec mention de son numéro INSEE ;

 Le programme local de l'habitat pour les communes dans lesquelles ce document est exigé en application de l'article L. 302-1 ou de l'article L. 302-4-1 du code de la construction et de l'habitation.  Toutes justifications chiffrées et éléments utiles de nature à établir l'importance des besoins en logements non satisfaits, la consistance du parc locatif et des catégories de logements recherchés dans la ou les communes concernées.

Si les quatre premiers éléments du dossier pourront a priori être réunis sans difficulté, la constitution des justifications chiffrées et autres éléments utiles suppose que le demandeur établisse au préalable des indicateurs statistiques de besoins en logement selon une méthodologie précisément définie.

B -L'établissement des indicateurs statistiques de besoins en logement

Les besoins en logements adaptés à la population sont en effet appréciés au regard d'indicateurs statistiques dont la liste a été établie par l'article 1 de l'arrêté du 23 septembre 2010 :

1°

D -La condition relative aux dépassements de seuils

Pour justifier de la pertinence de la demande d'agrément, le décret précise que le dossier devra faire apparaître des dépassements de seuils pour au moins la moitié de ces indicateurs statistiques, soit 5 d'entre eux. L'article 3 de l'arrêté indique à cet effet, pour chaque indicateur, le seuil qu'il convient de prendre en considération pour évaluer le dépassement.

L'indicateur global des besoins en logements, qui correspond à la moyenne des notes sur 100 obtenues pour chacun des indicateurs, doit quant à lui être supérieur à 25 sur 100.

L'arrêté précise sur ce point que les indicateurs qui ne sont pas disponibles pour les services du ministre chargé du logement ne sont pas pris en compte dans l'élaboration de la moyenne (article 2 in fine). L'indisponibilité de ces indicateurs ne dispensera pas pour autant le pétitionnaire de l'obligation de faire état d'au moins 5 indicateurs disponibles dépassant les seuils fixés à l'article 3 de l'arrêté.

-L'instruction du dossier

A -L'examen du dossier par le ministre du logement

Le ministre chargé du logement procède en premier lieu à l'évaluation du dossier de demande d'agrément. Il vérifie à cet effet l'ensemble des éléments fournis par le demandeur et plus particulièrement la pertinence des indicateurs statistiques qui lui sont présentés, la présence de 5 indicateurs dépassant les seuils fixés à l'article 3 du décret et d'un indicateur global supérieur à 25 sur 100.

L'examen ne se limite cependant pas à l'examen des éléments du dossier puisque, pour l'instruction des demandes ayant satisfait aux conditions précitées, le ministre peut également tenir compte « de tous autres éléments utiles de nature à établir l'importance de besoins en logements adaptés à la population non satisfaits, notamment des éléments d'expertise sur la situation du marché immobilier local et des éléments d'expertise relatifs à la conjoncture économique récente du bassin d'emploi de la commune » (article 4 du décret).

B -La transmission du dossier au préfet

La demande est ensuite transmise au préfet, qui conserve ainsi un rôle dans la procédure d'agrément, conformément à ce qui avait été prévu lors des discussions parlementaires.

Le préfet soumet alors la demande au comité régional de l'habitat (CRH) mentionné à l'article L. 364-1 du code de la construction et de l'habitation. Le CRH a été institué par la loi n°2004-809 du 13 août 2004 relative aux libertés et responsabilités locales. Il est chargé de procéder aux concertations permettant de mieux répondre aux besoins en matière d'habitat et de favoriser la cohérence des politiques locales.

L'avis sera réputé émis en l'absence de réponse du comité dans les trois mois suivant la transmission de la demande.

-La décision relative à la demande d'agrément

La décision définitive revient au ministre en charge du logement, qui statue sur la demande de chaque commune. Ainsi, si la demande d'agrément porte sur plusieurs communes, elle donnera lieu à une décision distincte pour chacune de ces communes (article 6 du décret).

A -Le rejet de la demande

Le silence gardé par le ministre au terme d'un délai de cinq mois à compter de la date de l'avis de réception du dossier complet de la demande d'agrément vaut décision de rejet de l'ensemble de la demande.

Le ministre n'aura aucune justification à fournir à l'appui de ce rejet implicite. Il importe de souligner qu'il s'agit dans tous les cas d'une décision d'opportunité. Le pétitionnaire qui présente une demande remplissant l'intégralité des conditions posées par le décret n'aura donc aucun droit acquis au bénéfice de l'agrément.

B -La délivrance de l'agrément

Si le ministre chargé du logement décide de faire droit à la demande du pétitionnaire, l'arrêté délivrant l'agrément sera publié au Journal Officiel.

Il sera valable 3 ans à compter de son entrée en vigueur.

Le décret prend soin de préciser que l'agrément d'une commune a pour seul effet de rendre éligible au bénéfice du dispositif Scellier les logements situés dans la commune dont l'acte authentique d'acquisition est signé ou, s'agissant des logements que le contribuable fait construire, dont la demande de permis de construire est déposée postérieurement à l'entrée en vigueur de l'agrément (article 8 du décret). Rien ne sert donc d'anticiper sur l'éventuel octroi de l'agrément.

S'agissant enfin des plafonds de loyers mensuels à prendre en compte pour bénéficier de la réduction d'impôt au titre du dispositif Scellier, l'arrêté prévoit qu'il faut se référer à l'article 2 terdecies B de l'annexe III du CGI, dans ses dispositions applicables aux communes de zone C soit, pour les baux conclu en 2010, 9,05 euros par mètre carré en secteur libre et 7,24 euros en secteur intermédiaire. Ces plafonds seront fixés respectivement à 6,1 € et 4,9 € pour les baux conclus en 2011, soit une baisse de 35%. Les plafonds de ressources du locataire sont quant à eux fixés par l'article 2 terdecies C de l'annexe III, également dans ses dispositions applicables aux zones C, soit pour les baux conclu en 2010 un revenu fiscal de référence qui ne doit pas dépasser 29 964 € pour une personne seule et 40 274 € pour un couple.

En conclusion Comme l'avait annoncé le secrétaire d'Etat au Logement Benoist Apparu lors de la conférence de presse présentant l'économie de ce nouveau dispositif, les textes règlementaires d'application de l'article 83 de la loi de finances pour 2010 ont été conçus pour limiter autant que possible la délivrance de ces agréments, estimés environ à 5 à 10 par an (conférence de presse du 26 août 2010). La mise en place d'une telle procédure, on l'aura compris, vise à protéger les acquéreurs, tout autant que les recettes de l'Etat, des dérives ayant affecté les dispositifs précédents. Espérons cependant que son extrême rigueur ne privera pas totalement d'effet la mesure votée, cette fois de concert, par les deux chambres du parlement.

  83 de la loi de finances pour 2010 a étendu le bénéfice de la réduction d'impôt Scellier aux acquéreurs de logements situés dans des communes classées en zone C, sous condition d'obtention d'un agrément octroyé par le ministre chargé du logement, sur demande de la commune ou de l'établissement public de coopération intercommunale compétent. Le Décret n° 2010-1112 du 23 septembre 2010 publié au Journal officiel du 24 septembre 2010 est venu (enfin) préciser les modalités d'octroi de cet agrément, désormais codifié au X de l'article 199 septvicies du Code général des impôts. L'arrêté du 23 septembre 2010 publié au Journal officiel du 24 septembre 2010 complète par ailleurs les modalités d'instruction de ces demandes.

  3° Le prix moyen au mètre carré dans l'ancien des appartements, d'après la base notariale nationale, ou, à défaut, le prix moyen au mètre carré dans l'ancien des maisons d'après la même base ;Cet indicateur global correspond à une moyenne sur 100 établie en fonction des notes obtenues pour chacun des indicateurs. Sachant que tous les indicateurs ne sont pas exprimés en pourcentage (prix moyen au m2, nombre de transactions immobilières,…), l'arrêté propose d'attribuer à chaque indicateur une note définie linéairement entre deux valeurs correspondant à une note minimale de 0 et à une note maximale de 100. Les valeurs plancher et plafond à retenir pour chaque indicateur sont fixées à l'article 2 de l'arrêté. note maximale est donnée pour toute valeur supérieure à celle correspondant à la note maximale » (article 2 de l'arrêté). Ainsi, si le loyer moyen d'une commune atteint une valeur inférieure à 4,86 € au m2, elle obtiendra une note de 0. Si par contre la valeur du loyer vient à dépasser les 15 € au m2, elle obtiendra une note de 100.Cette règle s'inverse pour les indicateurs 2° et 8°, dans la mesure où, s'agissant du taux de mobilité dans le parc social et du taux de vacances des logements, plus le chiffre obtenu est bas, plus il traduit un besoin en important en terme de logements. La note minimale sera donc donnée, dans ce cas, pour toute valeur supérieure à celle correspondant à la note minimale.

	4° Le nombre de transactions immobilières d'après la base notariale nationale rapporté au Soit la représentation graphique suivante :
	nombre d'habitants d'après l'INSEE ;
	Prix du loyer en €/m2	en deçà	4,86	11,4	15 et au delà …
	5° Le prix moyen au mètre carré des appartements neufs d'après l'enquête de Note de la commune 0 0 64,37 100 …
	commercialisation des logements neufs réalisée par le ministère chargé des statistiques de
	la construction ;
	6° Le loyer moyen au mètre carré de la commune, ou, à défaut, de la commune centre de
	l'établissement public de coopération intercommunale ou de l'unité urbaine auquel la
	commune appartient d'après la base de données de référence « Clameur » ;
	Illustration : Calcul de la note obtenue pour l'indicateur 6
	 Soit une commune située en zone C qui affiche un loyer mensuel moyen de 11,4
	euros au m2. La note de l'indicateur 6 doit être définie linéairement entre la valeur de
	4,86 € (note égale à 0) et la valeur de 15 € par mois (note égale à 100).

La part des bénéficiaires des aides au logement ayant un taux d'effort supérieur à 39 % dans le parc locatif privé d'après la Caisse nationale d'allocations familiales ; 2° Le taux de mobilité dans le parc social d'après l'enquête sur le parc locatif social réalisée par le ministère chargé du logement ; 7° Le taux de variation de la population d'après l'INSEE ; 8° Le taux de vacance des logements d'après l'INSEE ; 9° Le nombre moyen de mises en chantier annuelles sur les trois dernières années d'après la base de données réalisée par le ministère chargé des statistiques de la construction ; 10° Un indicateur global des besoins en logement calculé selon les modalités définies à l'article 2.

C -Le calcul de l'indicateur global des besoins en logement

Si le demandeur parvient à renseigner l'ensemble de ces indicateurs et que ces derniers font effectivement apparaître des dépassements de seuils pour la majorité d'entre eux, il ne sera pourtant pas au bout de ses peines. Il devra reprendre son bâton de pèlerin afin de franchir la dernière étape de la constitution du dossier : l'établissement de l'indicateur global des besoins en logement. Dès lors, la note obtenue pour cette commune au titre de l'indicateur 6 sera égale à : 100 X (11,4 -4,86) / (15 -4,86) = 64,37  L'arrêté précise en outre que, sauf pour les indicateurs 2° et 8°, « la note minimale est donnée pour toute valeur inférieure à celle correspondant à la note minimale » et que « la


Leila Hamdad

Amine Abdaoui
email: abdaoui@lirmm.fr

Nabila Belattar

Mohamed Ala Alchikha
email: m_al_chikha@esi.dz

An Integrated and Easy to Use Spatial Data Mining Platform

Keywords: Spatial Data Mining, Geo-visualization, Classification, Clustering, Association Rules

Spatial Data Mining allows users to extract implicit but valuable knowledge from spatial related data. Two main approaches have been used in the literature. The first one applies simple Data Mining algorithms after a spatial pre-processing step. While the second one consists of developing specific algorithms that considers the spatial relations inside the mining process. In this work, we first present a study of existing Spatial Data Mining tools according to the implemented tasks and specific characteristics. Then, we illustrate a new open source Spatial Data Mining platform (EasySDM) that integrates both approaches (pre-processing and dynamic mining). It proposes a set of algorithms belonging to clustering, classification and association rule mining tasks. Moreover and more importantly, it allows geographic visualization of both the data and the results. Either via an internal map display or using any external Geographic Information System.

INTRODUCTION

Spatially related data is present in many fields such as epidemiology, environmental science, image analysis, etc. In fact, many problems are spatially dependent. The study of any characteristic of such data can not be done without taking into account their respective geographical positions. In its most common form, a spatial data is divided into two parts: a descriptive part that can be of any standard type (Integer, Boolean, etc.) and a geographic part describing the geometry and geo-spatial position of the data. Voluminous geographic data are being collected with modern acquisition techniques such as Global Positioning Systems (GPS), highresolution remote sensing, Geographic Information System (GIS), etc. Extracting unknown and unexpected information from these spatial data sets requires efficient methods that take into account the spatial dependencies [START_REF] Guo | Spatial data mining and geographic knowledge discovery-An introduction[END_REF]. Spatial data are characterized by their interdependence, which comes from the following assumption: "The more objects are close to each other, the higher is the correlation between them" [START_REF] Miller | Tobler's First Law and Spatial Analysis[END_REF]. Therefore, Spatial Data Mining (SDM) has emerged as an active area of research for extracting implicit and relevant knowledge from large spatial databases containing great, complex and interdependent data [START_REF] Anselin | GeoDa: An Introduction to Spatial Data Analysis[END_REF]. In general, SDM tasks are extensions of Data Mining (DM) ones by taking into account spatial relations. These tasks include clustering, classification, association rule mining and geovisualization.

In the literature, several software of SDM exist, which function according to two main approaches. The first approach, which is the most intuitive one, consists of using classical DM algorithms on preprocessed spatial data. The pre-processing consists of extracting smoothed data table from the matrix between neighbouring objects, or by representing the spatial relations as new features [START_REF] Ouattara | Fouille de données: vers une nouvelle approche intégrant de façon cohérente et transparente la composante spatiale[END_REF]Rinzivillo et al, 2008). This approach is simple but time consuming [START_REF] Guo | Regionalization with Dynamically Constrained Agglomerative Clustering and Partitioning (REDCAP)[END_REF]. The second approach consists of developing specific SDM techniques that dynamically takes into consideration spatial relationships inside the mining process. Therefore, the exploratory process of this approach is faster than the first one but more complicated to implement.

In this work, we first propose a study on existing SDM tools focusing on their proposed tasks and specific characteristics. To our knowledge, no similar study has been proposed before in order to compare SDM tools, in contrast to the huge work done to compare classical DM tools [START_REF] Goebel | A Survey of Data Mining and Knowledge Discovery Software Tools[END_REF]John F. Elder and Dean W. Abbott, 1998;[START_REF] Witten | Data Mining: Practical Machine Learning Tools and Techniques[END_REF]. Then, we present EasySDM, our new integrated, open source and easy to use SDM platform. It integrates algorithms from both pre-processing and dynamic SDM approaches. On the one hand, algorithms from the Weka DM tool [START_REF] Hall | The WEKA Data Mining Software: An Update[END_REF] have been used after a pre-processing step using the GDPM API [START_REF] Bogorny | Weka-gdpm: Integrating classical data mining toolkit to geographic information systems[END_REF]. On the other hand, a naïve regionalization algorithm and a simple spatial rules association extraction algorithm that can be directly applied on spatial data have been implemented. While existing SDM tools show a lack of visualisation especially for open source ones, EasySDM offers the possibility to visualize spatial data directly on an integrated geographical map before and after applying DM algorithms. Furthermore, a visualization is also possible via any external Geographic Information System (GIS). Due to its simplicity and visualization capabilities, we believe that EasySDM may be helpful, inter alia, in explaining SDM to students in the academic area. It has been produced under the GPL licence in order to allow researchers and programmers to access and improve the source code. The platform setup, source code and documentation are publically available on the internet1 .

The rest of the paper is organized as follow: First, a comparative study on existing SDM tools is presented in section 2. Then, EasySDM and its components are detailed in section 3. After that, we conduct some experiments using EasySDM in order to illustrate its functionalities and present them in section 4. Finally, section 5 concludes and gives our main perspectives.

COMPARATIVE STUDY OF SDM TOOLS

Many SDM tools have been proposed in the literature. [START_REF] Han | GeoMiner: A System Prototype for Spatial Data Mining[END_REF] proposed GeoMiner, the first knowledge extraction software from spatial databases, developed in 1997. It is an extension of the classical DM tool DBMiner (Jiawei [START_REF] Jiawei Han | DBMiner: A System for Mining Knowledge in Large Relational Databases[END_REF] developed by the same team in 1996. Similarly, [START_REF] Ouattara | Fouille de données: vers une nouvelle approche intégrant de façon cohérente et transparente la composante spatiale[END_REF] developed GeoKnime, an extension of the Knime software (www.knime.org) to spatial data. [START_REF] Appice | An Integrated Platform for Spatial Data Mining Within a GIS Environment[END_REF] proposed Ingens, an integrated platform for SDM within a GIS environment. [START_REF] Lazarevic | A software system for spatial data analysis and modeling[END_REF] developed SDAM, a software system for spatial data analysis and modelling that includes two tasks of SDM (clustering and classification). [START_REF] May | An Architecture for the SPIN! Spatial Data Mining Platform[END_REF]) developed the SPIN system, a spatial information system that implements many clustering, classification and association rule mining algorithms. [START_REF] Bogorny | Weka-gdpm: Integrating classical data mining toolkit to geographic information systems[END_REF] developed a spatial pre-processing API that can be added to the Weka software in order to treat spatial data. Finally, an interesting application of clustering, named CrimeStat, has been proposed in [START_REF] Levine | CrimeStat III: a spatial statistics program for the analysis of crime incident locations (version 3.0)[END_REF] in order to detect hot spots of crime incidents.

In this section, we compare these tools according to their general characteristics. Table 1 presents for each tool: the year of its latest release, whether the software and the source code are publically accessible or not, whether a documentation is available or not and, finally, the type of the proposed visualization (if any). 2 presents a comparison of these tools according to their technical characteristics. For each tool, it presents its architecture, the programming language, whether it functions with all operating systems, and the possible types of data input. Finally, Table 3 presents a functional comparison, which takes into consideration the used SDM approach, the types of the considered spatial relations, and the implemented SDM tasks. It is important to notice that GeoMiner and Ingens have been built on specific spatial query languages. When they were released, these two tools were not successful. Moreover, GeoKnime and SDAM are not publically accessible and do not seem to be massively used. Since we could not test these four tools, their characteristics have been extracted from the scientific papers describing them.

SYSTEM OVERVIEW

Architecture

As presented in the previous section, Weka-GDPM is accessible, open source and includes the main three SDM tasks using the pre-processing approach. However, it does not provide any geographical visualization of the results. Therefore, we decided to use and enrich Weka-GDPM with a geographic visualization. Figure 1 below presents the platform architecture. The visualization of the spatial data and the results can be performed within the platform or using any external GIS. The internal map display has been implemented using the MapWinGIS API. The external visualization can be done by any GIS to open the data and the results. In addition to the Weka algorithms that can be applied on preprocessed data, we implemented a naïve regionalization and a simple spatial rule association mining algorithms (spatial Apriori) that can be applied directly on spatial data without any preprocessing. The development was carried out on a Microsoft Visual Studio 2012 platform using the C# programming language. The jar files of Weka and GDPM have been converted to dll files accessible from the C# code using the IKVM tool (www.ikvm.net). The data sources can be either arff files (.arff), shape files (.shp) or a PostGis 2.0 database. The obtained results can be saved in .arff or .shp formats.

Graphical User Interface

The Graphical User Interface (GUI) is simple and intuitive, hence the name of EasySDM. As presented in Figure 2, the GUI is divided into three areas:

 Region A (red rectangle): Allows the user to interact with the platform by specifying the shape file and the .arff file, setting up the parameters, modifying the theme of or the attribute to be displayed on the map, lunching the algorithm, and saving the results.  Region B (green rectangle): Displays information about the run such as: the algorithm status, the success/fail of the algorithm, the execution time and error messages, etc.  Region C (blue rectangle): This area is dedicated to the map display and the legend. It allows to visualize on the map both the data and the results. For example the same colour is used for objects that are in the same cluster. .arff

.shp PostGis Spatial Apriori

Regional -ization GDPM Weka

MapWin Gis External GIS

Geographic pre-processing

The geographic pre-processing is performed using the GDPM API. This step consists of extracting spatial relations and including them as new features to the data. These features represent the spatial objects as we used the instance granularity level.

Each new feature will take as value, the existing spatial relation between the object represented by the new feature (columns) and the object represented by the corresponding instance (lines). If no spatial relation is found between the two objects, the corresponding cell takes the value 'no'. Two types of spatial pre-processing are available according to the types of the extracted spatial relationships:

Distance relationships

Three types of distance spatial relations have been considered: close, very close and far. The spatial relationship is chosen according to thresholds. Figure 3 presents the structure of the obtained arff file.

Topological relationships

Eight types of topological spatial relationships have been considered: equal, disjoint, touches, within, overlaps, crosses, contains and covers. Figure 4 presents the structure of the obtained arff file.

Once the geographical pre-processing step has been applied, the data can be used with classical DM algorithms. In this first version, the following representative algorithms have been integrated using the Weka software:  Clustering by partitioning: K-means, Farthest

First and Expectation Maximization.  Density based clustering: Cobweb and DBscan.  Classification: J48 and Naïve Bayes.

Dynamic SDM algorithms

Two naive SDM algorithms that can be applied directly on the spatial data have been implemented. The goal here is to illustrate the dynamic processing approach by simple examples.

Regionalization

While classical clustering methods do not guarantee that objects in the same cluster are contiguous, regionalization groups similar objects in contiguous regions. Figure 5 presents the difference between clustering and regionalization. Our implemented regionalization algorithm is divided into two steps. First, a classical clustering algorithm is applied (here we applied the FarthestFirst algorithm). Then, the obtained clusters are organized into contiguous regions. If non-contiguous objects exist in each cluster, they are separated in order to form a new cluster. This process is repeated until all regions become contiguous.

The algorithm is presented below:

Input: Dataset: D
Minimal number of regions: k.

Output:

The assignments of elements to different regions.

End

Licence

EasySDM is distributed under the GPL licence in order to guarantee free access to the platform, the source code and to any software build on it. Weka, GDPM and IKVM are already under the GPL licence. However, MapWinGis has been distributed under the MPL 1.1 licence, which is incompatible with GPL. Therefore, we contacted MapWinGis owners and they gave us authorization to use their API along with GPL licences we are using.

EXPERIMENTS

In order to test the functionalities of our new SDM platform, we conducted experiments using publically available spatial data on the GeoDa website (www.geodacenter.asu.edu/sdata). The main goal here is to illustrate the visualisation capabilities of EasySDM on a real benchmark.

Description of the benchmark

It contains Malaria incidence and population in Colombia. We selected information corresponding to the year 1998. The obtained benchmark contained 33 spatial objects (polygons) representing the 33 Colombia departments. These 33 departments were described only with 5 features: department name, department code, number of malaria incidences (MALARI98), total population (TP1998), rural population (RP1998) and urban population (UP1998). Geographical pre-processing added 33 new features to the data. Due to the nature of this benchmark (polygons) topological relations have been considered.

Clustering

We first conduct a clustering experiment using Kmeans (k=3) on the geographically pre-processed data. In this experiment, the department "San Andres" has been removed in order to be used later in the classification. As shown in Figure 6, three clusters have been created:  The red cluster contains many departments especially from the center. Therefore, they contains many common borders. The number of Malaria incidences may be very high.  The orange cluster contains departments from the North West of the country. The number of Malaria incidences is high as well as the population, which is more urban than rural.

 The yellow cluster groups departments which has less common borders, less population and less Malaria cases. The population is more rural than urban.

Classification

We used the 32 already classified departments to build a Naive Bayes classifier which was used to classify the left "San Andres" department (composed of two islands). As shown in Figure 7, "San Andres" has been affected to the yellow cluster since it has no Malaria incidence (0), a small population (69525) and no common border with any other department.

Association rules

Finally, we apply the naive variation of Apriori to this benchmark. The extracted rule is the following (support and confidence have been set to 0):

Intersects(Antioquia) => Disjoint(San Andres)
This rule has a value of 0.24 in terms of support and 1 in terms of confidence. The departments verifying this rule are presented in yellow in Figure 8. The obtained rule is obvious and may not be valuable for the user. Since the purpose of the platform is to explain SDM to novice users we did not remove obvious rules. This can be included in future versions.

Figure 2 :

 2 Figure 2: EasySDM Graphical User Interface and its three areas. Here, the K-means clustering algorithm has been applied (k=4).

Figure 1 :

 1 Figure 1: EasySDM architecture.

Figure 3 :

 3 Figure 3: Structure of the arff file after the extraction of distance relationships.

Figure 4 :

 4 Figure 4: Structure of the arff file after the extraction of topological relationships.

Figure 5 :

 5 Figure 5: Difference between clustering and regionalization.

Figure 7 :

 7 Figure 7: Classification of the "San Andres" department (the two islands) using a Naïve Bayes classifier. The number of Malaria incidences is indicated for each department.

Figure 6 :

 6 Figure 6: Clustering using K-means (k=3) on the first benchmark. The number of Malaria incidence (MALARI98) and the rural (RP 1998), urban (UP 1998) and total population (TP 1998) are presented for each department.

Figure 8 :

 8 Figure 8: The departments verifying the obtained rule by Spatial Apriori

Table 1 :

 1 General characteristics of existing SDM tools

	Tool name	Year of last	release	Tool public accessibility	Sources public	accessibility	Documentation	integrated map display	External map display
	Geo-Miner	1999 No 2010 Yes	No	Yes Yes Yes
	Table

Table 2 :

 2 Technical characteristics of SDM tools (Un: Unknown, Win: Windows)

	Tool name	System architecture	Programmin g language	Operating system	Data input types
	GeoMiner	Client/	Un	All	Database
		Server
	GeoKnime Desktop Java	All	Database
	Ingens	Client/	Java	All	Database
		Server
	SDAM	Desktop C++ Win Database
	SPIN	N-tier	Java	All	Database
	GDPM	Desktop Java	All	Database
	CrimeStat	Desktop C++	All	Files: dbf,
						shp and dat
	Table 3: SDM characteristics of SDM tools (Pre-pro: Pre-
	processing, D: Distance, T: Topological, R: Directional,
	Un: Unknown)
	Tool name SDM	Spatial		SDM tasks
		approach	relations
					Classification	Clustering	Association
	GeoMiner Dynamic D		Yes Yes Yes
	GeoKnime Dynamic D and T Yes Yes No
	Ingens	Dynamic D, T and	No No Yes
			R
	SDAM	Pre-pro	Un		Yes Yes Yes
	SPIN	Dynamic D and T Yes Yes Yes
	GDPM	Pre-pro	D and T Yes Yes Yes
	CrimeStat Pre-pro	D and T No No Yes

http://www.lirmm.fr/~abdaoui/EasySDM

CONCLUSION

In this work, we propose an open source and easy to use SDM platform named EasySDM. It integrates classical DM methods implemented in the Weka platform after a Geographical pre-processing step. Moreover, it contains two naïve algorithms that consider the spatial relations inside the mining process without any pre-processing. The main contribution concerns the integration of an internal geographic visualization of the spatial data before and after applying the algorithms. EasySDM can also be interfaced with any GIS to offer external visualization and to take advantage of GIS functionalities. Therefore, we believe that it can be used in the academic area. The main expected improvements of EasySDM consist of enriching it with existing algorithms from the literature.


H Orhan Akman

Yavuz Aykit

Ozge Ceren Amuk

Edoardo Malfatti

Norma B Romero

Maria Antonietta Maioli

Rachele Piras

Salvatore Dimauro

Gianni Marrosu

LATE-ONSET POLYUCOSAN BODY MYOPATHY IN FIVE PATIENTS WITH A HOMOZYGOUS MUTATION IN GYG1

Keywords: polyglucosan myopathy, glycogenin deficiency, glycogenosis, GYG1

Polyglucosan myopathies are due to GBE, PFK deficiencies and to mutations in RBCK1, and GYG-1.

GYG1-splice site mutation causes polyglucosan myopathy and typical MRI muscle lesions.

We have identified a single intronic GYG-1 mutation in all five Sardinian patients.

1. Introduction

The three main glycogen synthetic enzymes are glycogenin1 (GYG1), glycogen synthase (GYS1), and glycogen branching enzyme (GBE1).

The best known mutations in the gene (GBE1) encoding glycogen branching enzyme have been associated with variably severe clinical forms of glycogenosis type IV (GSD IV), all of which cause accumulation of a poorly branched and poorly spherical amylopectin-like glycogen (polyglucosan) [START_REF] Schochet | Type IV glycogenosis (amylopectinosis). Light and electron microescopic observations[END_REF]. A late-onset severe form of GSD IV, dubbed as adult polyglucosan body disease (APBD), is characterized by central leukodystrophy, peripheral neuropathy, neurogenic bladder, and inconsistently dementia [START_REF] Robitaille | A distinct form of adult polyglucosan body diseases with massive involvement of central and peripheral neuronal processes and astrocytes[END_REF][START_REF] Mochel | Adult polyglucosan body disease: Natural history and key MRI findings[END_REF].

Recently recognized pathogenic mutations in the gene (GYS1) have been associated with profound glycogen depletion in muscle (glycogenosis type 0), resulting in exercise intolerance, weakness, and myalgia with sudden cardiac death [START_REF] Sukigara | Muscle glycogen storage disease 0 presenting recurrent syncope with weakness and myalgia[END_REF][START_REF] Cameron | Identification of a novel mutation in GSY1 (muscle-specific glycogen synthase) resulting in sudden cardiac death, that is diagnosable from skin fibroblasts[END_REF]. Lack of glycogen substrate was suggested by abnormal ischemic or non-ischemic forearm exercise, a typical test indicating excessive normal muscle glycogen storage due to defects of glycogen breakdown (GSD V, McArdle disease; GSD VII, Tarui disease).

A most unusual glycogenosis type 0 was identified in a 27-year-old man who had exercise intolerance and slight weakness but also suffered from ventricular fibrillation from which he was saved by application of a defibrillator. His muscle biopsy showed severe lack of glycogen due to biallelic mutations in the gene (GYG1) encoding the crucial glycogen synthetic enzyme glycogenin present in skeletal and cardiac muscle [START_REF] Moslemi | Glycogenin-1 deficiency and inactivated priming of glycogen synthesis[END_REF].

4

An even most unusual observation linked homozygous and compound heterozygous mutations in the GYG1 gene in seven patients of various ethnic background presenting with late-onset weakness and polyglucosan accumulationrather than lack of glycogenin their muscle biopsies and no cardiopathy [START_REF] Malfatti | A new muscle glycogen storage disease associated with glycogenin-1 deficiency[END_REF]. It was further noted that the severe mutations resulted in depletion of glycogenin-1 or impairment of glycogenin-1 interaction with glycogen synthase, but the cause of polyglucosan accumulation remains difficult to understand. More recently, Colombo et al. [START_REF] Colombo | Longitudinal follow-up and muscle MRI pattern of two siblings with polyglucosan body myopathy due to glycogenin-1 mutation[END_REF] reported two sisters presenting adult onset limb girdle weakness associated with an intronic GYG1 variant previously encountered in 4/7 cases of the seminal paper [START_REF] Malfatti | A new muscle glycogen storage disease associated with glycogenin-1 deficiency[END_REF], and Luo et al. described a woman manifesting proximal limb weakness associated a homozygous missense variants [START_REF] Luo | Muscle pathology and whoe-body MRI in a polyglucosan myopathy associated with a novel glycogenin-1 mutation[END_REF] Here, we report on five Sardinian patients presenting late-onset polyglucosan body myopathy associated with a single GYG1 homozygous intronic mutation.

Materials and methods

Patients

Five adult patients with polyglucosan myopathy from four unrelated Sardinian families were included in this study. After informed consent, all five patients underwent open biopsy of the quadriceps muscle for histochemical studies.

Muscle pathology and biochemistry

Proximal muscle biopsies (quadriceps) were studied extensively with traditional 5 histochemical battery, including periodic acid-Schiff (PAS) stain before and after digestion with α-amylase (diastase). Detailed electron microscopy analysis was performed in four patients as described by Malfatti et al [START_REF] Malfatti | Skeletal muscle biopsy analysis in reducing body mopathy and other FHL1-related disorders[END_REF].

Biochemical analyses were performed in frozen muscle specimens in various laboratories, including values for the following enzymes: acid -glucosidase, glycogen branching enzyme, and all glycogenolytic and glycolytic enzymes.

Molecular genetic analysis

Genomic DNA was extracted from blood and frozen skeletal muscle by standard methods and Sanger sequencing was used for the GYG1 gene. Briefly, exon 2 was amplified by PCR using primers hGYG1-Ex2F 5'-CCA AAG GGC TAC AGC TTG AT and hGYG1-Ex2R 5'CTC TAC CCG GTG CTC AAT TC. Amplified exon 2 fragment was sequenced with forward or reverse primer.

Results

Clinical findings

Clinical data for all 5 patients are summarized in Table 1. Onset of their Serum CK values were invariably modestly increased. Electromyography (EMG) showed a mixed myopathic and neurogenic pattern in patient 2, but a clear myopathic pattern in patient 4. Muscle MRI studies were performed and a representative image of lower limbs in patient 5 shows fatty acid replacement of the major gluteus (Figure 1A) and of both vastus lateralis and adductor magnus muscles (Figure 1B). Biochemical analyses in frozen muscle biopsy from patient 1 found normal activities of the following enzymes: acid -glucosidase, glycogen branching, all glycogen breakdown and glycolytic enzymes (including phosphofructokinase).

Morphological and biochemical analysis

Molecular genetic analysis 7

The presence of abundant normal glycogen in addition to polyglucosan suggested us to sequence the gene (AGL) encoding glycogen debranching enzyme, which resulted normal.

Next we analyzed glycogenin, which has been shown to cause polyglucosan in muscle [START_REF] Malfatti | A new muscle glycogen storage disease associated with glycogenin-1 deficiency[END_REF]. A single homozygous pathogenic variant of GYG1 is identified in all five patients (Table1) and consists of an intronic (c,143+3G>C) change (Figure 4). This intronic change on a splice donor site has altered proper splicing according to the data reported in a previous paper [START_REF] Malfatti | A new muscle glycogen storage disease associated with glycogenin-1 deficiency[END_REF].

Discussion

Our findings in the five patients confirm that a common autosomal recessive intronic GYG1 mutation causes (or is associated with) late-onset polyglucosan myopathy as recently reported in ten unrelated patients with different ethnic backgrounds and harboring pathogenic GYG1 variants [START_REF] Malfatti | A new muscle glycogen storage disease associated with glycogenin-1 deficiency[END_REF][START_REF] Colombo | Longitudinal follow-up and muscle MRI pattern of two siblings with polyglucosan body myopathy due to glycogenin-1 mutation[END_REF][START_REF] Luo | Muscle pathology and whoe-body MRI in a polyglucosan myopathy associated with a novel glycogenin-1 mutation[END_REF] The clinical phenotype is homogenous, consisting in late-onset mildly progressive limb-girdle weakness. Patient 3 showed distal involvement, which contrasts with that reported in a previous paper [START_REF] Malfatti | A new muscle glycogen storage disease associated with glycogenin-1 deficiency[END_REF], where two patients (P2,P7) showed distal leg involvement, and one (P6) showed uniquely hands and fingers muscle weakness. Of note, a revealing symptom in P1 and P5 was exercise intolerance. P5 differed from the other patients also because she had a mildly myopathic muscle biopsy without inclusions, but MRI axial views of her pelvic and proximal thighs clearly showed fatty replacement of muscles as indicated in recently reported patients [START_REF] Colombo | Longitudinal follow-up and muscle MRI pattern of two siblings with polyglucosan body myopathy due to glycogenin-1 mutation[END_REF][START_REF] Luo | Muscle pathology and whoe-body MRI in a polyglucosan myopathy associated with a novel glycogenin-1 mutation[END_REF]. Exercise 8 intolerance is a relatively new clinical finding of GYG1-related polyglucosan body myopathy, reported also in a recent paper [START_REF] Luo | Muscle pathology and whoe-body MRI in a polyglucosan myopathy associated with a novel glycogenin-1 mutation[END_REF]. By contrast, the firstly described GYG1 patient with glycogenosis type 0 illustrated a different clinical phenotype, characterized by young-onset cardiomyopathy and exercise intolerance, without PAS-positive inclusions but profound glycogen depletion in his muscle biopsy and accumulation of abnormal glycogen in his heart. In further contrast to the patients with GYG1-related polyglucosan body myopathy, the patient with glycogenosis type 0 had more abundant residual glycogenin-1 [START_REF] Moslemi | Glycogenin-1 deficiency and inactivated priming of glycogen synthesis[END_REF].

Very interestingly, we have identified the same mutation in all the patients. This intronic variant affecting the splice donor site and blocking glycogenin-1 biosynthesis segregated with the disease.

Polyglucosan body myopathy is but one example of several polyglucosan storage diseases, some of which are well known, including fatal infantile GSD IV or adult polyglucosan body disease (APBD) [START_REF] Robitaille | A distinct form of adult polyglucosan body diseases with massive involvement of central and peripheral neuronal processes and astrocytes[END_REF][START_REF] Mochel | Splice mutation in the iron-sulfur cluster scaffold protein ISCU causes mtopathy with exercise intolerance[END_REF], some cases of GSD VII [START_REF] Malfatti | Juvenile-onset permanent weakness in muscle phophofructokinase deficiency[END_REF], teen ageonset myoclonus epilepsy (Lafora disease) [START_REF] Lohi | Genetic diagnosis in Lafora disease[END_REF], and a new form of polyglucosan myopathy with cardiomyopathy due to mutations in RBCK1 gene [START_REF] Nilsson | Polyglucosan body myopathy caused by defective ubiquitin ligase RBCK1[END_REF].

Several pathogenic mechanisms have been associated with polyglucosan accumulation. An obvious pathogenic mechanism was associated with the imbalanced ratio of the two glycogen synthetic enzymes, glycogen synthase (GYS) and glycogen branching (GBE), favoring the advantage of GYS over GBE activity. An obvious polyglucosan deposit in multiple tissues is due to loss of GBE activity due to the polymorphic phenotypes associated with GSD IV. However, a subtler GYS/GBE imbalance was identified by excessive activity of GYS-1, which caused less conspicuous polyglucosan deposit in skeletal muscle from patients with phosphofructokinase (PFK) deficiency (GSD VII, Tarui disease) [START_REF] Hays | Muscle phosphofructokinase deficiency: abnormal polysaccharide in a case of late-onset myopathy[END_REF]. This was due to accumulation in muscle of glucose-6-phosphate (G6P), an upstream substrate of PFK deficiency and a physiologic activator of GYS-1. This phenomenon was documented later by serendipitously generating transgenic mice with deficient acid maltase and with upregulation of GYS-1, resulting in abundant polyglucosan generation in skeletal muscle [START_REF] Raben | Surprises of genetic engineering: A possible model of polyglucosan body disease[END_REF]. A final discovery of a gain-of-function mutation in equine GYS-1 revealed the polyglucosan myopathy in some breeds of horses [START_REF] Mccue | Glycogen synthase (GYS1) mutation causes a novel skeletal muscle glycogenosis[END_REF].

Different pathogenic mechanisms were involved in two very similar disorders. APBD and Lafora disease, which both cause severe polyglucosan deposition mostly in central and peripheral nervous systems, but also in other tissues, including skeletal muscle. APBD is due to two common GBE1 founder mutations in Ashkenazi Jewish patients [START_REF] Akman | Deep intronic GBE1 mutation in manifestting heterozygous patients wit adult polygucosan body disease[END_REF], but the most common mutations due to Lafora disease affect two distinct genes, one (EPM2A) encoding the laforin protein, a glycogen phosphatase, the other (EPM2B) encoding the malin protein, a ubiquitin 3 ligase [START_REF] Lohi | Genetic diagnosis in Lafora disease[END_REF]. The pathogenesis of polyglucosan accumulation in Lafora disease is not completely clear but there is good evidence that mutation in the glucan phosphatase laforin leads to hyperphosphorylated glycogen, which, in turn, leads to polyglucosan formation. Mutations in malin, a ubiquitin ligase, may impede the normal removal of laforin and excess laforin also causes polyglucosan formation [START_REF] Depaoli-Roach | Genetic depletion of the malin E3 ubiquitin ligase in mice leads to Lafora bodies and accumulation of insoluble laforin[END_REF].

Interestingly, a new form of polyglucosan storage disease, either limited to muscle or involving heart and muscle, was defined genetically by mutations in another ubiquitin ligase gene, RBCK1, affecting ten patients from eight families [START_REF] Nilsson | Polyglucosan body myopathy caused by defective ubiquitin ligase RBCK1[END_REF]. The ten 10 patients were characterized by a juvenile-onset myopathy but eight of them had a rapidly progressive cardiomyopathy, which required cardiac transplantation in four.

Notably, some patients with mutations in the same gene had a different phenotype, with failure to thrive, chronic autoinflammation, and recurrent episodes of sepsis [START_REF] Boisson | Immunodeficiency, autoinflammation and amylopectinosis in humans with inherited HOIL-1 and LUBAC deficiency[END_REF]. They also accumulated polyglucosan in muscle, heart, and liver, but a careful genotypephenotype correlation analysis will be needed to clarify the different tissue involvement in these allelic disorders.

Yet another problem remains to be clarified to explain the distinct clinical presentations between two allelic disorders, both due to mutations in the GYG1 gene: (i) a juvenile glycogen-depleted myopathy and a severe cardiopathy; and (ii) a late-onset myopathy with polyglucosan storage in skeletal muscle but without cardiomyopathy.

The hypothesis suggested by Malfatti is based on the finding of different residual amounts of glycogenin-1 in the two conditions [START_REF] Malfatti | A new muscle glycogen storage disease associated with glycogenin-1 deficiency[END_REF]. Abundant residual presence of glycogenin-1 would explain the complete early loss of muscle glycogen and early accumulation of abnormal glycogen in the heart. However, mixed components of normal glycogen and abundant polyglucosan are present in muscle from patients with almost absent residual glycogenin-1, which is not mandatory as a primer for glycogen synthase, although alternative primers remain to be investigated. The histopathological comparisons of polyglucosan body myopathies with different etiologies could shed some light on the comprehension of mechanisms leading to polyglucosan formation and how they contribute to muscle weakness [START_REF] Hedberg-Oldfors | Polyglucosan storage mypathies[END_REF].

14

Legends to Table and Figures

  weakness started at age 40 to age 60. Their initial complaints included progressive muscles weakness affecting both girdles, causing waddling gait, difficulty in climbing stairs and lifting arms. Notably, two patients, P1 and P5, also had exercise intolerance or myalgia. All patients showed slow progression, with impaired walking, inability to climbing stairs and rising from the floor with positive Gowers sign. Their cardiac examinations revealed decreased global systolic function due to concomitant ischemic cardiomyopathy in patient 1 and only mild changes compatible 6 with their late ages in the other patients (slight left atrial dilation in patient 2, mild mitral and tricuspid valve insufficiency in patients 3, 4 and 5 revealed by echocardiography).

  Light and electron microscopic investigations of muscle revealed characteristic alterations. Thirty percent of the fibers harbored vacuoles in the central and subsarcolemmal areas, containing intense PAS-positive inclusions, often surrounded by a halo of less intense PAS-positive material: treatment of muscle fibers with extensive digestion by -amylase resulted in residual PAS-positive polyglucosan whereas the less intense PAS-positive normal glycogen disappeared (Figure 2 A, B). Electron microscopy revealed the typical polyglucosan structure, consisting of ovoid structure composed of partly filamentous material. A thin rim of normal glycogen particles and normal-looking mitochondria surrounded the polyglucosan bodies (Figure 3 A, B). Muscle biopsy from Patient 5 failed to show inclusions both in light and electron microscopy.

Figure 1 .

 1 Figure 1. Muscle MRI from Patient 5 shows fatty replacement at hip level (A), of notably

Figure 2 .

 2 Figure 2. Serial sections of vastus lateralis muscle stained strongly with PAS reaction

Figure 3 .

 3 Figure 3. Electron microscopy shows presence of subsarcolemmal abnormal glycogen

Figure 4 .

 4 Figure 4. Intronic mutation (c.143+3G>C) indicated by arrow causes aberrant splicing

Acknowledgements: This research has been funded by grants from the Keith B. Hayes Foundation and from the APBD Research Foundation