Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user.catalan > #6855 > unrolled thread

Mesurar rendiment d'una aplicació

Back to article view | Back to linux.debian.user.catalan

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Mesurar rendiment d'una aplicació Leopold Palomo-Avellaneda <leo@alaxarxa.net> - 2021-06-01 19:30 +0200
    Re: Mesurar rendiment d'una aplicació Àlex <alex@probeta.net> - 2021-06-01 23:10 +0200
      Re: Mesurar rendiment d'una aplicació Leopold Palomo-Avellaneda <leo@alaxarxa.net> - 2021-06-02 08:20 +0200
        Re: Mesurar rendiment d'una aplicació Josep Lladonosa <jlladono@gmail.com> - 2021-06-02 09:30 +0200
          Re: Mesurar rendiment d'una aplicació Leopold Palomo-Avellaneda <leo@alaxarxa.net> - 2021-06-02 20:30 +0200
            Re: Mesurar rendiment d'una aplicació Josep Lladonosa <jlladono@gmail.com> - 2021-06-02 21:50 +0200
        Re: Mesurar rendiment d'una aplicació Xavi Drudis Ferran <xdrudis@tinet.cat> - 2021-06-02 10:40 +0200
          Re: Mesurar rendiment d'una aplicació Leopold Palomo-Avellaneda <leo@alaxarxa.net> - 2021-06-02 20:50 +0200
        Re: Mesurar rendiment d'una aplicació Ernest Adrogué <nr9@posteo.de> - 2021-06-02 22:40 +0200
    Re: Mesurar rendiment d'una aplicació Àlex <alex@probeta.net> - 2021-06-01 23:10 +0200
    Re: Mesurar rendiment d'una aplicació Narcis Garcia <debianlists@actiu.net> - 2021-06-02 10:30 +0200
      Re: Mesurar rendiment d'una aplicació Leopold Palomo-Avellaneda <leo@alaxarxa.net> - 2021-06-02 20:30 +0200
        Re: Mesurar rendiment d'una aplicació Narcis Garcia <debianlists@actiu.net> - 2021-06-02 21:00 +0200
          Re: Mesurar rendiment d'una aplicació Leopold Palomo-Avellaneda <leo@alaxarxa.net> - 2021-06-02 21:10 +0200
    Re: Mesurar rendiment d'una aplicació Àlex <alex@probeta.net> - 2021-06-02 10:40 +0200
      Re: Mesurar rendiment d'una aplicació Leopold Palomo-Avellaneda <leo@alaxarxa.net> - 2021-06-02 20:30 +0200
        Re: Mesurar rendiment d'una aplicació Xavi Drudis Ferran <xdrudis@tinet.cat> - 2021-06-02 21:30 +0200

#6855 — Mesurar rendiment d'una aplicació

Bones,

he enviat aquest missatge a la llista de caliu però ha tingut poc
èxit... Us explico, probablement és un correu fora de tema, però
m'agradaria preguntar aquí perquè potser alguns de vosaltres em podrien
guiar.

Estic treballant amb alguns científics per avaluar alguns programes que
calculen una solució per a un problema. Bàsicament fan una instància de
ILOG CPLEX i obtenen el temps utilitzat per calcular la solució o fan
servir alguna heurística.

Utilitzem un servidor per fer els càlculs, i hem trobat (òbviament)
variacions significatives que depenen de la càrrega de la màquina. El
què voler obtenir és un tipus de mesura independent de la càrrega del
servidor.

Un enfocament ha estat utilitzar el temps de CPU. En el nostre cas, el
nombre total dels segons de CPU que el procés utilitza directament (en
mode d'usuari). No estem parlant del temps real transcorregut (wall
clock) que òbviament és directament està afectat per la càrrega de la
màquina.

No obstant això, hem realitzat diverses proves i hem descobert que té
una variació al voltant del 10% (depenent de la càrrega). També hem
avaluat el temps de CPU en mode kernel i també com hi ha un canvi de
context perquè l'aplicació no s'executa. Però, sincerament no hem
obtingut una idea clara del que està passant.

Una altra qüestió que hem trobat és com pot afectar el nombre de nuclis.
o CPUs físiques al servidor.

Algú de vosaltres ha trobat aquests problemes i els ha resolt?


Salutacions,

Leopold

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [next] | [standalone]

#6856

Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
el temps total (wall time). A tu t'interessa el cpu time:

https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9

[toc] | [prev] | [next] | [standalone]

#6858

El 1/6/21 a les 23:00, Àlex ha escrit:
> Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
> el temps total (wall time). A tu t'interessa el cpu time:
> 
> https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9
> 
> 
Genial!!!

Però és una passada perquè el CPU time hauria de ser més o menys constant i no 
ho és. Nosaltres hem trobat variacions de fins al un 10%.

Leo

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#6859

[Multipart message — attachments visible in raw view] — view raw

El dc., 2 de juny 2021, 8:14, Leopold Palomo-Avellaneda <leo@alaxarxa.net>
va escriure:

> El 1/6/21 a les 23:00, Àlex ha escrit:
> > Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
> > el temps total (wall time). A tu t'interessa el cpu time:
> >
> >
> https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9
> >
> >
> Genial!!!
>
> Però és una passada perquè el CPU time hauria de ser més o menys constant
> i no
> ho és. Nosaltres hem trobat variacions de fins al un 10%.
>

Hola, Leo,

Has aportat una pregunta molt interessant. Si més no m'hi has fet rumiar
una bona estona.

Podria ser que la causa de les variacions sigui la temperatura?

Els nuclis dels processadors redueixen la freqüència dels nuclis quan la
temperatura baixa.

https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/

SALUT!



> Leo
>
> --
> --
> Linux User 152692     GPG: 05F4A7A949A2D9AA
> Catalonia
> -------------------------------------
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>
>

[toc] | [prev] | [next] | [standalone]

#6876

El 2/6/21 a les 9:27, Josep Lladonosa ha escrit:
[...]

> Hola, Leo,
> 
> Has aportat una pregunta molt interessant. Si més no m'hi has fet rumiar
> una bona estona.
> 
> Podria ser que la causa de les variacions sigui la temperatura?

No, està en un CPD, i té condicions òptimes.

> Els nuclis dels processadors redueixen la freqüència dels nuclis quan la
> temperatura baixa.
> 
> https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/
> <https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/>

Sí, però no. Té aire condicionat 24/7/365


Leo

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#6881

[Multipart message — attachments visible in raw view] — view raw

On Wed, 2 Jun 2021 at 20:27, Leopold Palomo-Avellaneda <leo@alaxarxa.net>
wrote:

> El 2/6/21 a les 9:27, Josep Lladonosa ha escrit:
> [...]
>
> > Hola, Leo,
> >
> > Has aportat una pregunta molt interessant. Si més no m'hi has fet rumiar
> > una bona estona.
> >
> > Podria ser que la causa de les variacions sigui la temperatura?
>
> No, està en un CPD, i té condicions òptimes.
>
> > Els nuclis dels processadors redueixen la freqüència dels nuclis quan la
> > temperatura baixa.
> >
> >
> https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/
> > <
> https://www.pugetsystems.com/labs/articles/Impact-of-Temperature-on-Intel-CPU-Performance-606/
> >
>
> Sí, però no. Té aire condicionat 24/7/365
>

M'estàs parlant de la sala on es troba el processador.

Jo parlava de les temperatures dels nuclis. Hi influeix la capacitat de
dissipadors i ventiladors per emportar-se l'escalfor dels processadors.
Pots tenir la sala amb aire condicionat i els processadors treballant
tranquil·lament a 60/70/80 graus centígrads. Aquestes variacions poden fer
fluctuar aquests càlculs de temps.

SALUT!
Josep


>
>
> Leo
>
> --
> --
> Linux User 152692     GPG: 05F4A7A949A2D9AA
> Catalonia
> -------------------------------------
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?
>


-- 
--
Salutacions...Josep
--

[toc] | [prev] | [next] | [standalone]

#6868

El Wed, Jun 02, 2021 at 08:13:46AM +0200, Leopold Palomo-Avellaneda deia:
> El 1/6/21 a les 23:00, Àlex ha escrit:
> > Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
> > el temps total (wall time). A tu t'interessa el cpu time:
> > 
> > https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9
> > 
> > 
> Genial!!!
> 
> Però és una passada perquè el CPU time hauria de ser més o menys constant i
> no ho és. Nosaltres hem trobat variacions de fins al un 10%.
> 
> Leo

Jo no hi entenc però és que no veig perquè la CPU hauria de ser
constant.  Si agafes un model de processador com el que feiem a primer
de carrera a Computadors potser sí.  Però amb les complicacions que
tenen les CPUs actuals ja és molt si aconsegueixen que els resultats
siguin deterministes. Que el temps sigui determinista en condicions
diferents és demanar molt.

Algú ha parlat de temperatura, i sí, els processadors poden baixar la
freqüència de rellotge si s'escalfen. També hi ha les caches (L1,L2,L3
al processador, TLBs, buffers de disc a RAM... alguns canvis de
velocitat causats per aquests te'ls deuen comptar com temps de cpu
d'usuari). Si tens pocs processos la probabilitat que les dades encara
estiguin a alguna cache després d'un parell de canvis de context
puja. Amb les mitigacions dels atacs de canals laterals a CPU
(Spectre & cia.?) potser baixi aquest efecte, però no crec que l'eliminin.

Quan l'ordinador té diferents processadors i cada processador
diferents nuclis, també pots tenir més rendiment si tots els
processos/fils de la teva aplicació acaben a nuclis del mateix
processador i comparteixen alguna cache o tenen rutes més curtes per
comunicar-se. Si al sistema hi ha molts processos potser el linux no
aconsegueix distribuir els teus tan òptimament.  Fulleja per aquí per
una idea del merder que representa
https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/

Els perifèrics també poden reaccionar diferent segons la càrrega.
Imagina't que tens processos que no toquen un disc i el disc s'arriba
a parar per estalviar energia quan aquests processos els toca una
estona llarga de CPU. Llavors quan el necessita el procés que medeixes
s'ha de tornar a accelerar (si és dels que giren, en qualsevol cas també
incorporen caches). Això hauria de ser temps de S.O. meś que d'usuari,
però no śe si es pot comptar del tot bé si fa que el procés que medeixes
surti de la CPU abans d'hora i perdi continuitat de cache o el que sigui...

Després separar temps de cpu d'usuari i de S.O. està bé, però no sé si
avui en dia hi pot haver temps de supervisors que estiguin per sobre
del S.O.  i no es vegin en cap compte (gestors de màquines virtuals,
system management, UEFI, etc.). Dubto que això influeixi molt, o
diferent segons càrrega, però qui sap.

No em facis molt de cas, parlo per parlar, no vull dir que aquests
efectes siguin significatius, vull dir que hi ha moltes coses
interconnectades.  El programador té un model simplificat d'una
màquina de von Neumann i prou (o quasi), però el S.O. i maquinari són
bastant més complicats, i això fa que el rendiment tingui tot de
peripècies.


Has mirat perf ?
https://perf.wiki.kernel.org/index.php/Tutorial

[toc] | [prev] | [next] | [standalone]

#6877

Bones,

trobava a faltar els teus correus!!!!

El 2/6/21 a les 10:25, Xavi Drudis Ferran ha escrit:
> El Wed, Jun 02, 2021 at 08:13:46AM +0200, Leopold Palomo-Avellaneda deia:
>> El 1/6/21 a les 23:00, Àlex ha escrit:
>>> Aquí hi ha diferents de codi per mesurar temps d'us de cpu (cpu time) i
>>> el temps total (wall time). A tu t'interessa el cpu time:
>>>
>>> https://levelup.gitconnected.com/8-ways-to-measure-execution-time-in-c-c-48634458d0f9
>>>
>>>
>> Genial!!!
>>
>> Però és una passada perquè el CPU time hauria de ser més o menys constant i
>> no ho és. Nosaltres hem trobat variacions de fins al un 10%.
>>
>> Leo
> 
> Jo no hi entenc però és que no veig perquè la CPU hauria de ser
> constant.  Si agafes un model de processador com el que feiem a primer
> de carrera a Computadors potser sí.  Però amb les complicacions que
> tenen les CPUs actuals ja és molt si aconsegueixen que els resultats
> siguin deterministes. Que el temps sigui determinista en condicions
> diferents és demanar molt.

Estem totalment d'acord.

> Algú ha parlat de temperatura, i sí, els processadors poden baixar la
[...]

no és temperatura.

> 
> Quan l'ordinador té diferents processadors i cada processador
> diferents nuclis, també pots tenir més rendiment si tots els
> processos/fils de la teva aplicació acaben a nuclis del mateix
> processador i comparteixen alguna cache o tenen rutes més curtes per
> comunicar-se. Si al sistema hi ha molts processos potser el linux no
> aconsegueix distribuir els teus tan òptimament.  Fulleja per aquí per
> una idea del merder que representa
> https://blog.acolyer.org/2016/04/26/the-linux-scheduler-a-decade-of-wasted-cores/

Brutal!!!! He de mirar-ho amb calma.

[...]

> 
> Has mirat perf ?
> https://perf.wiki.kernel.org/index.php/Tutorial

No, ara ho estic mirant.

Moltes gràcies.

Leo



-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#6882

Hola,

2021-06- 2, 08:13 (+0200); Leopold Palomo-Avellaneda escriu:
> Però és una passada perquè el CPU time hauria de ser més o menys constant i
> no ho és. Nosaltres hem trobat variacions de fins al un 10%.

Però un 10% quant és en termes absoluts?  No és el mateix 30 segons que
500 milisegons.

A les llistes de computació científica, la gent sempre reporta
estadístiques sobre el temps d'execució, mai un únic temps d'execució.
O sigui el que fan és executar el programa o funció repetidament moltes
vegades i calculen la mitjana.  De fet tenen eines d'anàlisi de
rendiment que ho fan automàticament.

Salutacions.

[toc] | [prev] | [next] | [standalone]

#6857

Bones Leo,

no sé gaire del tema, però l'article a la Wikipèdia en anglès aporta
alguna referència, per fer recerca:

    https://en.wikipedia.org/wiki/CPU_time

Salutacions


    Àlex



El 1/6/21 a les 19:14, Leopold Palomo-Avellaneda ha escrit:
> Bones,
>
> he enviat aquest missatge a la llista de caliu però ha tingut poc
> èxit... Us explico, probablement és un correu fora de tema, però
> m'agradaria preguntar aquí perquè potser alguns de vosaltres em podrien
> guiar.
>
> Estic treballant amb alguns científics per avaluar alguns programes que
> calculen una solució per a un problema. Bàsicament fan una instància de
> ILOG CPLEX i obtenen el temps utilitzat per calcular la solució o fan
> servir alguna heurística.
>
> Utilitzem un servidor per fer els càlculs, i hem trobat (òbviament)
> variacions significatives que depenen de la càrrega de la màquina. El
> què voler obtenir és un tipus de mesura independent de la càrrega del
> servidor.
>
> Un enfocament ha estat utilitzar el temps de CPU. En el nostre cas, el
> nombre total dels segons de CPU que el procés utilitza directament (en
> mode d'usuari). No estem parlant del temps real transcorregut (wall
> clock) que òbviament és directament està afectat per la càrrega de la
> màquina.
>
> No obstant això, hem realitzat diverses proves i hem descobert que té
> una variació al voltant del 10% (depenent de la càrrega). També hem
> avaluat el temps de CPU en mode kernel i també com hi ha un canvi de
> context perquè l'aplicació no s'executa. Però, sincerament no hem
> obtingut una idea clara del que està passant.
>
> Una altra qüestió que hem trobat és com pot afectar el nombre de nuclis.
> o CPUs físiques al servidor.
>
> Algú de vosaltres ha trobat aquests problemes i els ha resolt?
>
>
> Salutacions,
>
> Leopold
>

-- 
La solidaritat és la tendresa dels pobles. Lluita contra l'apartheid:

  http://boycottdebconf20.org/
  http://twitter.com/hashtag/BoycottDebConf20
  http://wiki.debian.org/DebConf/21

  https://www.btselem.org/publications/fulltext/202101_this_is_apartheid
  https://www.elsaltodiario.com/ocupacion-israeli/apartheid-sanitario-israeli-metafora-kibbutz
  https://www.elsaltodiario.com/elsacapuntas/estudiar-bajo-apartheid-el-dia-a-dia-de-los-estudiantes-palestinos

[toc] | [prev] | [next] | [standalone]

#6862

Per a controlar tot allò que afecta a la CPU, crec que el millor és
virtualitzar. Fins i tot és possible separar la màquina virtual de l'ús
directe del maquinari real.



Narcis Garcia

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 1/6/21 a les 19:14, Leopold Palomo-Avellaneda ha escrit:
> Bones,
> 
> he enviat aquest missatge a la llista de caliu però ha tingut poc
> èxit... Us explico, probablement és un correu fora de tema, però
> m'agradaria preguntar aquí perquè potser alguns de vosaltres em podrien
> guiar.
> 
> Estic treballant amb alguns científics per avaluar alguns programes que
> calculen una solució per a un problema. Bàsicament fan una instància de
> ILOG CPLEX i obtenen el temps utilitzat per calcular la solució o fan
> servir alguna heurística.
> 
> Utilitzem un servidor per fer els càlculs, i hem trobat (òbviament)
> variacions significatives que depenen de la càrrega de la màquina. El
> què voler obtenir és un tipus de mesura independent de la càrrega del
> servidor.
> 
> Un enfocament ha estat utilitzar el temps de CPU. En el nostre cas, el
> nombre total dels segons de CPU que el procés utilitza directament (en
> mode d'usuari). No estem parlant del temps real transcorregut (wall
> clock) que òbviament és directament està afectat per la càrrega de la
> màquina.
> 
> No obstant això, hem realitzat diverses proves i hem descobert que té
> una variació al voltant del 10% (depenent de la càrrega). També hem
> avaluat el temps de CPU en mode kernel i també com hi ha un canvi de
> context perquè l'aplicació no s'executa. Però, sincerament no hem
> obtingut una idea clara del que està passant.
> 
> Una altra qüestió que hem trobat és com pot afectar el nombre de nuclis.
> o CPUs físiques al servidor.
> 
> Algú de vosaltres ha trobat aquests problemes i els ha resolt?
> 
> 
> Salutacions,
> 
> Leopold
> 

[toc] | [prev] | [next] | [standalone]

#6875

El 2/6/21 a les 10:19, Narcis Garcia ha escrit:
> Per a controlar tot allò que afecta a la CPU, crec que el millor és
> virtualitzar. Fins i tot és possible separar la màquina virtual de l'ús
> directe del maquinari real.
> 

no ho crec. Jo voldria poder fer servir tota la capacitat de la màquina,
no voldria una capa de virtualització.

Leo

-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#6878

__________
I'm using this dedicated address because personal addresses aren't
masked enough at this mail public archive. Public archive administrator
should fix this against automated addresses collectors.
El 2/6/21 a les 20:21, Leopold Palomo-Avellaneda ha escrit:
> El 2/6/21 a les 10:19, Narcis Garcia ha escrit:
>> Per a controlar tot allò que afecta a la CPU, crec que el millor és
>> virtualitzar. Fins i tot és possible separar la màquina virtual de l'ús
>> directe del maquinari real.
>>
> 
> no ho crec. Jo voldria poder fer servir tota la capacitat de la màquina,
> no voldria una capa de virtualització.
> 
> Leo
> 

El teu objectiu és executar ràpid o bé mesurar el cost d'un procés per a
planificar execucions futures?
És la única manera que veig de controlar una CPU.

Tota la resta és creuar dits i esperar que la primera, segona, tercera,
etc. execucions vagin igual en maquinari real.
És la diferència entre fer una mesura a l'aire lliure o en condicions de
laboratori.


Narcis Garcia

[toc] | [prev] | [next] | [standalone]

#6879

El 2/6/21 a les 20:53, Narcis Garcia ha escrit:
> __________
> I'm using this dedicated address because personal addresses aren't
> masked enough at this mail public archive. Public archive administrator
> should fix this against automated addresses collectors.
> El 2/6/21 a les 20:21, Leopold Palomo-Avellaneda ha escrit:
>> El 2/6/21 a les 10:19, Narcis Garcia ha escrit:
>>> Per a controlar tot allò que afecta a la CPU, crec que el millor és
>>> virtualitzar. Fins i tot és possible separar la màquina virtual de l'ús
>>> directe del maquinari real.
>>>
>>
>> no ho crec. Jo voldria poder fer servir tota la capacitat de la màquina,
>> no voldria una capa de virtualització.
>>
>> Leo
>>
> 
> El teu objectiu és executar ràpid o bé mesurar el cost d'un procés per a
> planificar execucions futures?
> És la única manera que veig de controlar una CPU.

el meu objectiu és mesurar un procés per poder comparar. Per exemple
donar-li a un algoritme un temps límit de forma que si el comparo amb un
altre tingui les mateixes condicions o quasi similars.

> Tota la resta és creuar dits i esperar que la primera, segona, tercera,
> etc. execucions vagin igual en maquinari real.
> És la diferència entre fer una mesura a l'aire lliure o en condicions de
> laboratori.

Sí ....


Leo


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#6866

Leo,

no puc deixar de rumiar en la teva pregunta. No conec el tema, però com
t'han dit, és molt interessant.

El servidor on s'executa l'aplicació, té una o més CPUs multinucli?

Està l'aplicació preparada per executar-se en paral.lel en vàries CPUs o
per emprar varis nuclis dins d'una CPU?

L'aplicació fa us de GPU de targetes gràfiques?

En quin llenguatge està programada l'aplicació?

Salut

[toc] | [prev] | [next] | [standalone]

#6874

El 2/6/21 a les 10:31, Àlex ha escrit:
> Leo,
> 
> no puc deixar de rumiar en la teva pregunta. No conec el tema, però com
> t'han dit, és molt interessant.

Uff, i tant.

> El servidor on s'executa l'aplicació, té una o més CPUs multinucli?

és un servidor Dell amb dues cpus i 20 cores cadascuna.

> Està l'aplicació preparada per executar-se en paral.lel en vàries CPUs o
> per emprar varis nuclis dins d'una CPU?

Les porves que hem fet executa una aplicació que fa servir una
biblioteca de codi tancat. Però tu llences l'aplicació i totes les cpu
és posen a treballar com a perturbades.

> L'aplicació fa us de GPU de targetes gràfiques?

No, només cpu. A més, el servidor té una gràfica molt simple.

> En quin llenguatge està programada l'aplicació?

El core de l'aplicació de IBM crec que està en C o C++. Té "bindings"
java, python i C++. També té un IDE que en el fons crida a aquest core.


Leo


-- 
--
Linux User 152692     GPG: 05F4A7A949A2D9AA
Catalonia
-------------------------------------
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

[toc] | [prev] | [next] | [standalone]

#6880

El Wed, Jun 02, 2021 at 08:24:30PM +0200, Leopold Palomo-Avellaneda deia:
> biblioteca de codi tancat. Però tu llences l'aplicació i totes les cpu
> és posen a treballar com a perturbades.
> 

Clar, pobretes. Si jo fos una CPU d'aquestes també m'escaquejaria com pogués
fins que arribés el torn de l'apicació lliure

;op

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.user.catalan

csiph-web