Jump to content

Uso do cpu limitado a 30%?


Recommended Posts

Posted

Boas pessoal,

Imaginem o seguinte programa.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
int main()
{
   clock_t tempo;
   tempo=clock();
   unsigned long long int num3=18446744073709551615LLU,i;
   for (i=0;i<num3;i++){

   }
   tempo=clock() -tempo;
   printf("Tempo:%.2f",(float)tempo/1000);
   return 0;
}

Isto apenas é para exemplificar. Nao faz nada.

Se eu executar o programa vejo que ele so usa 30% do cpu. Porque? Eu uso windows 8.

Se eu quiser utilizar o total do cpu posso faze-lo?

Cumprimentos

Leandro Rodrigues

Posted

e' o recurso maximo que o windows permite a uma aplicacao single-thread. Se queres 100% tens que usar multi-thread

Por muito mais que que estude só aprendo uma coisa, que ainda tenho muita coisa para aprender.

A beleza de um código está em decompor problemas complexos em pequenos blocos simples.

"learn how to do it manually first, then use the wizzy tool to save time."

"Kill the baby, don't be afraid of starting all over again. Fail soon, learn fast."

Posted

Não sei como é com as versões primitivas do Windows, mas pelo menos com o XP a coisa funcionava à mesma assim. Se é uma aplicação single-thread, então o Windows vai colocá-la num core. Se quiseres utilizar mais cores, tens de "forçar" isso (como o fazer é algo que nunca estudei a fundo, pelo que não me pronuncio). E ainda tens de ter em atenção que há hyperthreading actualmente em muitas CPU's da Intel, pelo que um core pode executar duas threads simultâneamente (resumindo).

Knowledge is free!

Posted (edited)

Nao, se a aplicacao e' single thread, so' vai correr com um core. Isto significa que se tiveres um pentium 4, o programa pode correr a 100%.

fiz um exemplo para consumir o CPU todo em windows.

#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include<windows.h>

#define NUM_MAX_THREAD 4
typedef unsigned long long int U64;

void KillCoreCPU()
{
   U64 limite = 0xFFFFFFFFFFFFFFFF;
   U64 i=0;
   while(i++<limite);
}

HANDLE CreateSideThread(void* func)
{
   DWORD dwGenericThread;
   HANDLE hTh = CreateThread(NULL, 0, func, NULL, 0, &dwGenericThread);

   return hTh;
}

void CreateThreadAndKillCPU()
{
   HANDLE thrs[NUM_MAX_THREAD];
   int i;
   for(i = 0;i<NUM_MAX_THREAD;i++)
    thrs[i] = CreateSideThread(KillCoreCPU);

   WaitForMultipleObjects(NUM_MAX_THREAD,thrs,1,INFINITE);
}


int main()
{
   printf("%d",sizeof(U64));

   clock_t tempo;
   tempo=clock();
   CreateThreadAndKillCPU();

   tempo=clock() -tempo;
   printf("Tempo:%.2f",(float)tempo/1000);
   return 0;
}
Edited by pikax
  • Vote 2

Por muito mais que que estude só aprendo uma coisa, que ainda tenho muita coisa para aprender.

A beleza de um código está em decompor problemas complexos em pequenos blocos simples.

"learn how to do it manually first, then use the wizzy tool to save time."

"Kill the baby, don't be afraid of starting all over again. Fail soon, learn fast."

Posted

Nao, se a aplicacao e' single thread, so' vai correr com um core. Isto significa que se tiveres um pentium 4, o programa pode correr a 100%.

fiz um exemplo para consumir o CPU todo em windows.

Quando estiver em casa ja testo. So uma pergunta se eu tiver 4 cores, neste caso nao tenho Hyperthreading uma vez que e um AMD, só posso criar 4 threads? Porque? Eu no windows 8 vejo que existem milhares de threads a ser executadas...

Mais uma pergunta ao criar 4 threads cada uma vai para um core diferente?

Posted

Achava que a representação no Windows era a mesma que no Linux/Unix em que cada core representa 100% do CPU. Ou seja, um dual core permite uma taxa de utilização de 200% (ou 400% com HT). É possível que esteja enganado devido à minha baixa interacção com o SO.

Quando estiver em casa ja testo. So uma pergunta se eu tiver 4 cores, neste caso nao tenho Hyperthreading uma vez que e um AMD, só posso criar 4 threads? Porque? Eu no windows 8 vejo que existem milhares de threads a ser executadas...

Mais uma pergunta ao criar 4 threads cada uma vai para um core diferente?

Se tiveres mais threads (em execução) que o teu hardware permite tratar, o teu SO vai ter que trocar frequentemente a thread que está a ser executada. Isso quer dizer que vais perder performance.

“There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult.”

-- Tony Hoare

Posted

Isso não é 100% verdade. O SO corre várias threads de modo "permanente" (no mínimo uma por processo), pelo que context switching já é algo que acontece regularmente.

Mas o que queria realçar é que se o teu programa efectuar muitas operações de I/O (e.g. leitura de ficheiros) ou operações com arrays/matrizes de tamanho considerável, então vais ter muitos cache-misses porque a cache L1 (mais próxima do processador) não tem tamanho suficiente para guardar todos os dados do programa. Uma leitura da RAM (ou mesmo de uma cache mais afastada e maior como L3) demora centenas de ciclos e se só tiveres uma thread por core o que vai acontecer é que o SO vai trocar para outra thread (e.g. do sistema operativo) enquanto aguarda pelos resultados. Se for uma leitura do disco (que demora milhares de ciclos, mesmo que esteja no buffer do mesmo) então o resultado ainda é pior. Conclusão, decidir o número de threads é um problema que depende muito da aplicação em particular que estamos a escrever e não depende só do número de cores do CPU.

Posted

Mas o que queria realçar é que se o teu programa efectuar muitas operações de I/O (e.g. leitura de ficheiros) ou operações com arrays/matrizes de tamanho considerável, então vais ter muitos cache-misses porque a cache L1 (mais próxima do processador) não tem tamanho suficiente para guardar todos os dados do programa.

Quer dizer que quando executo um programa existem variaveis que sao guardadas na cache do cpu? Existe alguma maneira de saber se elas estao na cache ou na ram?

Posted

para qualquer coisa que e' processada pelo o CPU tem que ir para as caches antes

Por muito mais que que estude só aprendo uma coisa, que ainda tenho muita coisa para aprender.

A beleza de um código está em decompor problemas complexos em pequenos blocos simples.

"learn how to do it manually first, then use the wizzy tool to save time."

"Kill the baby, don't be afraid of starting all over again. Fail soon, learn fast."

Posted

O que o pikax disse, a memoria e' uma hierarquia e as coisas movimentam-se sempre de uns niveis para os outros. Da mesma maneira que para abrir um ficheiro tens que o copiar primeiro para a RAM (cabe ao programador fazer isso), para ler algo da RAM os dados sao copiados primeiro para a cache (cabe ao hardware fazer isso). Podes ver mais aqui: http://en.wikipedia.org/wiki/Memory_hierarchy . Um bom post sobre os efeitos de cache misses esta' aqui: http://igoro.com/archive/gallery-of-processor-cache-effects/

E' impossivel saberes se os dados vao estar na cache ou nao. Alias, esse e' um dos grandes problemas na construcao de compiladores porque faz com que o tempo de execucao de uma determinada instrucao nao seja previsivel e muitas optimizacoes ficam por fazer.. Mas ja nos estamos a afastar do tema inicial que era o uso de threads.

Posted

fiz um exemplo para consumir o CPU todo em windows.

Bem era para testar mais cedo no entanto surgiram imprevistos e nao consegui.

De qualquer das maneiras estive a ver agora o teu codigo e efetivamente ele "consome" todo o CPU. Vou estudar mais sobre esta materia pois parece-me bastante interessante

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site you accept our Terms of Use and Privacy Policy. We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.