Fai funzionare lentamente un programma


102

C'è un modo per eseguire un programma C ++ più lentamente modificando i parametri del sistema operativo in Linux? In questo modo vorrei simulare cosa succederebbe se quel particolare programma dovesse funzionare su una macchina molto più lenta.

In altre parole, una macchina più veloce dovrebbe comportarsi come una macchina più lenta per quel particolare programma.


5
Potresti usare 'nice' per dargli una priorità davvero bassa - non una cosa definitiva, ma potrebbe aiutare!
John3136

7
eseguirlo all'interno di una vm con un altro programma che fa girare il processore.
thang

12
niceè un comando che abbassa la priorità di pianificazione. Varia antico, relativamente rozzo. È possibile esaminare le priorità di pianificazione, ma se la macchina non è impegnata in altre cose, il programma verrà comunque eseguito velocemente. Quindi, probabilmente non aiuterà a sufficienza.
Jonathan Leffler

9
Devi tenere presente che i computer hanno molti processi in esecuzione in qualsiasi momento, in quanto tale rendere la tua app più lenta non sarà particolarmente utile. Se vuoi vedere come si comporta la tua app su hardware scadente, dovresti ottenere detto hardware scadente o modificare temporaneamente le impostazioni del BIOS del tuo hardware per renderlo scadente. Alcuni BIOS ti permetteranno di disabilitare i core extra e di abbassare il clock della CPU.
Mike Trusov

23
Togli il pulsante "Turbo"!
SoftDev

Risposte:


145
  • Abbassare la priorità utilizzando nice(e / o renice). Puoi anche farlo a livello di nice()codice utilizzando la chiamata di sistema. Ciò non rallenterà la velocità di esecuzione di per sé, ma farà sì che lo scheduler di Linux allochi meno (e forse più brevi) intervalli di tempo di esecuzione, anticipi più spesso, ecc. Vedere Process Scheduling (Capitolo 10) di Comprendere il kernel Linux per maggiori dettagli sulla pianificazione .
  • Potresti voler aumentare la frequenza di interruzione del timer per caricare più carico sul kernel, che a sua volta rallenterà tutto. Ciò richiede una ricostruzione del kernel.
  • È possibile utilizzare il meccanismo di scalabilità della frequenza della CPU (richiede il modulo del kernel) e controllare (rallentare, accelerare) la CPU utilizzando il cpufreq-setcomando.
  • Un'altra possibilità è chiamare sched_yield(), che fornirà quantum ad altri processi, in parti critiche per le prestazioni del programma (richiede la modifica del codice).
  • È possibile collegare le funzioni comuni come malloc(), free(), clock_gettime()ecc utilizzando LD_PRELOAD , e fare alcune cose stupide come bruciare qualche milione di cicli di CPU con rep; hop;inserto barriere di memoria ecc Questo rallenterà il programma di sicuro. (Vedi questa risposta per un esempio di come fare alcune di queste cose).
  • Come menzionato da @Bill, puoi sempre eseguire Linux in un software di virtualizzazione che ti consente di limitare la quantità di risorse CPU allocate, memoria, ecc.
  • Se vuoi davvero che il tuo programma sia lento, eseguilo sotto Valgrind (potrebbe anche aiutarti a trovare alcuni problemi nella tua applicazione come perdite di memoria, riferimenti di memoria errati, ecc.).
  • Una certa lentezza può essere ottenuta ricompilando il tuo binario con ottimizzazioni disabilitate (cioè -O0e abilita asserzioni (cioè -DDEBUG).
  • Puoi sempre acquistare un vecchio PC o un netbook economico (come One Laptop Per Child , e non dimenticare di donarlo a un bambino una volta terminato il test) con una CPU lenta ed eseguire il tuo programma.

Spero che sia d'aiuto.


15
+1: vario insieme di suggerimenti, inclusi i requisiti di base per ciascuno
lxop

4
L'abilitazione dei simboli di debug ( -ggdb3) non rallenta l'esecuzione del binario. Semplicemente lo rende più grande.
caf

11
+1 esp., Per "... compra un vecchio PC o un netbook economico ... e non dimenticare di donarlo a un bambino una volta che hai finito di testare"
Kris

3
Potresti modificare la tua risposta per mostrare come simulare diversi tipi di "lento"? C'è una differenza tra I / O lento, CPU lenta, memoria lenta, thrash della memoria, ecc.
parasietje

3
+1 per Vlad. Probabilmente cpufreq è facile da fare, se hai una CPU e un kernel Linux con supporto. Questo dovrebbe avere granularità a livello di istruzione. Questa è probabilmente la migliore risposta generica senza acquistare nuovo hardware; non simula una rete, un disco, un video, ecc. più lenti che possono anche causare gare.
rumore senza arte

36

QEMU è un emulatore di CPU per Linux. Debian ha pacchetti per questo (immagino che la maggior parte delle distribuzioni lo faranno). Puoi eseguire un programma in un emulatore e la maggior parte di essi dovrebbe supportare il rallentamento delle cose. Ad esempio, Miroslav Novak ha patch per rallentare QEMU.

In alternativa, è possibile eseguire la compilazione incrociata su un'altra CPU-linux (arm-none-gnueabi-linux, ecc.) E quindi fare in modo che QEMU traduca quel codice da eseguire.

Il bel suggerimento è semplice e potrebbe funzionare se lo combini con un altro processo che consumerà cpu.

nice -19 test &
while [ 1 ] ; do sha1sum /boot/vmlinuz*; done;

Non hai detto se hai bisogno di grafica, file e / o I / O di rete? Sai qualcosa sulla classe di errore che stai cercando? È una condizione di competizione o il codice ha prestazioni scadenti presso il sito di un cliente?

Modifica: puoi anche utilizzare segnali come STOP e CONT per avviare e interrompere il programma. Anche un debugger può farlo. Il problema è che il codice funziona a piena velocità e poi viene interrotto. La maggior parte delle soluzioni con lo scheduler di Linux avrà questo problema. C'era una sorta di analizzatore di thread da Intel afair. Vedo le note di rilascio di Vtune . Questo è Vtune, ma ero abbastanza sicuro che ci fosse un altro strumento per analizzare le gare di thread. Vedere: Intel Thread Checker , che può verificare alcune condizioni di thread race. Ma non sappiamo se l'app è multi-thread?


1
e bochs è un emulatore di cpu più vecchio e più lento (solo x86).
osgx

22

Usa cpulimit:

Cpulimit è uno strumento che limita l'utilizzo della CPU di un processo (espresso in percentuale, non in tempo CPU). È utile per controllare i lavori batch, quando non vuoi che consumino troppi cicli della CPU. L'obiettivo è impedire l'esecuzione di un processo per più di un periodo di tempo specificato. Non cambia il valore piacevole o altre impostazioni di priorità di pianificazione, ma l'utilizzo reale della CPU . Inoltre, è in grado di adattarsi al carico complessivo del sistema , dinamicamente e rapidamente.

Il controllo della quantità di CPU utilizzata viene effettuato inviando segnali SIGSTOP e SIGCONT POSIX ai processi.

Tutti i processi figli e thread del processo specificato condivideranno la stessa percentuale di CPU.

È nei repository di Ubuntu. Appena

apt-get install cpulimit

Ecco alcuni esempi su come usarlo su un programma già in esecuzione:

Limita il processo 'bigloop' per nome eseguibile al 40% della CPU:

cpulimit --exe bigloop --limit 40
cpulimit --exe /usr/local/bin/bigloop --limit 40 

Limita un processo tramite PID al 55% della CPU:

cpulimit --pid 2960 --limit 55

Non ho ancora testato cpulimit, ma sembra la migliore risposta a domande simili su siti SE. C'è qualche differenza notevole tra un programma in esecuzione con limitazioni imposte da cpulimit e un programma in esecuzione su hardware più lento? Il mio obiettivo è testare un'app per assicurarmi che sia sufficientemente reattiva su macchine più lente (e per ottimizzare la grafica per le macchine più lente).
trusktr

@trusktr Dipende molto da ciò che il programma sta effettivamente facendo. All'improvviso con l'hardware più vecchio posso pensare alle velocità del disco e alla memoria disponibile (RAM) che influiscono anche sulle prestazioni, e dalla parte relativa alla grafica, anche alla GPU. Potrebbe esserci di più. Se la CPU è effettivamente il collo di bottiglia, probabilmente vale ancora la pena provare cpulimit. (Questa risposta ha 7 anni, e allora questi successi di performance non erano neanche lontanamente il top della mia mente)
Izkata

Interessante. Hai ragione, non ho considerato HDD o GPU. Suppongo che testare con hardware effettivamente più lento sia il modo migliore per farlo, ma al momento ho solo una potente workstation anche se mi piacerebbe pubblicare anche per telefoni di fascia bassa (app JS + WebGL).
trusktr

13
  1. Procurati un vecchio computer
  2. I pacchetti di hosting VPS tendono a funzionare lentamente, hanno molte interruzioni e latenze molto variabili. Più economico andrai, peggio sarà l'hardware. A differenza dell'hardware veramente vecchio, ci sono buone probabilità che contengano set di istruzioni (SSE4) che di solito non si trovano sul vecchio hardware. Tuttavia, se vuoi un sistema che cammina lentamente e si chiude spesso, un host VPS economico sarà l'inizio più rapido.

3

Se vuoi semplicemente simulare il tuo programma per analizzarne il comportamento su una macchina molto lenta, puoi provare a far funzionare l'intero programma come un threadaltro programma principale .

In questo modo puoi dare priorità allo stesso codice con priorità diverse in pochi thread contemporaneamente e raccogliere i dati della tua analisi. L'ho usato nello sviluppo di giochi per l'analisi dell'elaborazione dei frame.


2

Usa sleep o aspetta all'interno del codice. Non è il modo più brillante per farlo, ma accettabile in tutti i tipi di computer con velocità diverse.


2

Il modo più semplice possibile per farlo sarebbe avvolgere il codice eseguibile principale in un ciclo while con uno sleep alla fine.

Per esempio:

void main()
{
    while 1
    {
        // Logic
        // ...
        usleep(microseconds_to_sleep)
    }
}

Come diranno le persone, questo non è il modo più accurato, poiché il codice logico continuerà a funzionare a velocità normale ma con ritardi tra le esecuzioni. Inoltre, si presuppone che il codice logico sia qualcosa che viene eseguito in un ciclo.

Ma è sia semplice che configurabile.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.