[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Multicore Visualizer on 576 cores
|
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
> On Behalf Of Xavier Raynaud
> Sent: Thursday, June 26, 2014 9:15 AM
> To: CDT General developers list.
> Subject: [cdt-dev] Multicore Visualizer on 576 cores
>
> Hi Marc,
>
> As promized on twitter, please find herafter a screenshot of the multicore
> visualizer running on 576 cores.
> The MPPA TURBOCARD2 is not yet on my hands: I've worked instead on 2
> MPPA boards connected together - Yes, it's smaller: it's half the size.
Nice work!
> Lessons learned:
> (1) When gdb connects to this platform, he ask each core/thread individually
> for his state. It's a bit slow...
Are you talking about GDB itself, or of CDT? I'm wondering if you are describing
a delay when GDB connects to the target and another delay when CDT requests
information from GDB, or if there is one single delay from CDT to GDB?
> (2) When visualizer connects, he does the same things: so we have to wait
> twice longer.
If the visualizer uses the DSF services, the caching mechanism should kick in
and there should be no need to go back to GDB for the information that was
already fetched.
> Our gdb is able to return the state of the whole system with a single "info
> thread" command.
> I was able to use this feature to populate the multicore visualizer view faster
> (much faster).
>
> However, I do not know how to use the feature to populate the standard
> debug view. Any hints ?
The debug view gets its information using the DSF services, mostly the IProcesses
service. Overriding that one to use an enhanced 'info threads' is how you would
improve this.
I'd be curious to see your 'gdb traces' to better understand what you mean
by the inefficiencies described above. I'm not sure if that is allowed for your system.
Marc
