OpenCL: testes internos de implementação em MQL5 - página 63

[Sceptic Philozoff]

GKS: Se a AMD não tivesse comprado a ATI Readon há um par de anos atrás.

A ATI foi comprada há 6 anos, em 2006.

A única pena é que os concorrentes da Intel não tenham tecnologia semelhante à Hyper-threading, esperemos que a AMD a invente.

Bulldozer é uma espécie de implementação hardcore de hiper-treading: 8 undercore com FPUs obviamente escassas que também lutam por recursos.

Surpreendentemente, Bull saiu ligeiramente melhor do que Thuban x6 em média, mesmo em multithreading. Em tarefas inteiras bem parecidas, conta rapidamente (fica ligeiramente abaixo do i7), mas em tudo o resto perde para o i7 e acaba, em média, no mesmo nível do i5-2400. Em suma, um processador de servidor para o ambiente de trabalho. E é pouco provável que o Trinity conserte esta situação: os núcleos são bulldozados.

De acordo com ixbt,

Ganho de desempenho da CPU de até 29%, que é um crédito ao novo núcleo do processador convencionalmente chamado Piledriver

Por isso, estava enganado. Que aplicações seriam assim?

[Konstantin Grebenshikov]

Mathemat: Bulldozer é uma espécie de implementação de hiper-comercialização hardcore: 8 unidades de FPUs com FPUs obviamente escassas, que também lutam por recursos.

É ainda pior em termos de desempenho energético. Quanto mais energia é gasta para executar cada núcleo físico do que quando 4 núcleos físicos executam 8 fios independentes...

/ Corrigi o correio separando a citação da sua resposta. Para poder escrever a sua resposta fora da citação (se não puder), clique no botão HTML à esquerda, escreva algumas letras no final da citação e volte ao modo visual - Mathemat/

[Konstantin Grebenshikov]

Quero acreditar que, neste projecto...

[Konstantin Grebenshikov]

https://www.mql5.com/ru/articles/405 - depois de ler este artigo, fiquei interessado no tema da computação GPU, embora não seja um programador, mas neste artigo deparei-me com um linkhttp://www.ixbt.com/video3/rad.shtml, que por sua vez atraiu este artigo -http://www.ixbt.com/video3/rad2.shtml. Acho que este tema poderia zaiterezovat desenvolvedores deste projecto, porque descreve uma variante para aumentar a estratégia de optimização do desempenho da testosterona com operações complexas. Talvez ajude no desenvolvimento do projecto.

P.s Não li este artigo até ao fim.

Obrigado pela dica....

[Vladimir]

E o que pensam as pessoas aqui sobre o AMP C++ que a Microsoft implementou para o seu VS11:

http://msdn.microsoft.com/en-us/library/hh265136(v=vs.110).aspx

Anunciámos esta tecnologia na Cimeira de Desenvolvedores de Fusão AMD, em Junho de 2011. Ao mesmo tempo, anunciámos a nossa intenção de tornar a especificação aberta, e estamos a trabalhar com outros vendedores de compiladores para que possam apoiá-la nos seus compiladores (em qualquer plataforma).

Note-se que a EM quer que esta extensão linguística seja aberta. Experimentei-o no VS11 e devo dizer que é uma coisa fixe. Em vez de um pesado código CUDA SDK num .cu separado, apenas algumas linhas no mesmo .cpp:

Gostaria que a MQL5 tivesse uma característica semelhante. Nunca trabalhei com OpenCL mas também ouvi dizer que é difícil de programar lá.

[Sceptic Philozoff]

gpwr: Seria bom se a MQL5 tivesse as mesmas capacidades.

O OpenMP já foi questionado. Não o fazem.

[Sceptic Philozoff]

Pergunta aos programadores de terminais: existem planos para adicionar a capacidade de definir o tamanho do grupo de trabalho à API do OpenCL? Isso seria muito agradável. Provavelmente, em CLExecute(), como eu o entendo.

[Andrey Dik]

Mathemat:
Pergunta aos programadores de terminais: Existem planos para adicionar ao OpenCL API uma possibilidade de definir o tamanho do grupo de trabalho? Seria muito agradável. Provavelmente, na função CLExecute(), tal como eu a entendo.

CLExecute(cl_krn,work_dim,offset,work) - não é?

bool  CLExecute(
               int          kernel,                   // хендл на кернел OpenCL программы
               uint         work_dim,                 // размерность пространства задач 
               const uint&  global_work_offset[],     // начальное смещение в пространстве задач
               const uint&  global_work_size[]        // общее количество задач
               );

[Sceptic Philozoff]

joo: CLExecute(cl_krn,work_dim,offset,work) - não é?

Não, este é apenas o tamanho do espaço de trabalho global.

Mas a dimensão do grupo de trabalho local não se encontra em lado nenhum na implementação dos desenvolvedores de terminais. Bem, deveria.

No OpenCL API completo, existe a função clEnqueueNDRangeKernel( ) cujo análogo é CLExecute(). É o seu sexto argumento - const size_t*local_work_size que é necessário.

[Andrey Dik]

Estou a ver.