Diferença ao rodar codigo Cygwin e VS

[Tiago Alves]

Pessoal,

estou com uma situação estranha aqui. O cenário é o seguinte.

Nós temos uma DLL aqui, compilada com o VS2010, essa DLL exporta uma função que processa recebe (char* A, char* B, float* resultado).

Esse projeto do VS gera a DLL e o .lib, como de costume.

Temos então uma aplicação de teste, que carrega dois arquivos binários e copia para A e B respectivamente.

Quando a aplicação de teste é compilada também no VS2010 e utilizo o .lib para ter acesso às funções da DLL, o resultado o float resultado recebe um valor de 621.359253. 

No entanto, quando eu compilo a mesma aplicação de teste no Cygwin, faço a linkagem com o .lib para ter acesso à DLL, eu tenho um float resultado de 640.776672.

Obs: Eu processei vários outros arquivos A e B na aplicação de teste, e o resultado foi idêntico tanto quanto eu compilo no VS como no Cygwin, no entanto, dois arquivos específicos estão dando essa diferença.

Alguém tem alguma explicação sobre isso? 

Obrigado

--
---------------------------------------------------
 Tiago Alves de Oliveira

[Gianni .]

Eu posso te dar milhares! :-)

 

Mas só conseguiria te dar uma que fosse *relevante* se tivesse um pouco mais de informações... tipo, a sua aplicação faz basicamente o que? Trabalha com floats, doubles, etc? você já tentou reproduzir com/sem otimizações? Qual dos dois resultados é o esperado? Imagino que isso é um bug em algum dos dois, certo? ...etc...

--
Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
 
 
 

[Tiago Alves]

Então Gianni,

mas se a DLL só foi compilada no VS, mesmo que a minha DLL faça várias operações com doubles e floats, isso não deveria interferir, certo? Visto que ela é carrega dinamicamente.

Eu utilizei sempre a DLL compilada no VS. Nunca a compilei no Cygwin. 

 Engenheiro de Biometria

 IEEE - Certified Biometric Professional
 

Blog: Biometria Brasil
 
 Cel:  (19) 8175-2513
-------------------------------------------------------

[Adriano dos Santos Fernandes]

On 14/05/2013 16:28, Tiago Alves wrote:
> Pessoal,
>

> estou com uma situa��o estranha aqui. O cen�rio � o seguinte.
>
> N�s temos uma DLL aqui, compilada com o VS2010, essa DLL exporta uma
> fun��o que processa recebe (char* A, char* B, float* resultado).

> Esse projeto do VS gera a DLL e o .lib, como de costume.
>

> Temos ent�o uma aplica��o de teste, que carrega dois arquivos bin�rios

> e copia para A e B respectivamente.

> Quando a aplica��o de teste � compilada tamb�m no VS2010 e utilizo o
> .lib para ter acesso �s fun��es da DLL, o resultado o float resultado

> recebe um valor de 621.359253.

> No entanto, quando eu compilo a mesma aplica��o de teste no Cygwin,
> fa�o a linkagem com o .lib para ter acesso � DLL, eu tenho um float
> resultado de 640.776672.
>
> Obs: Eu processei v�rios outros arquivos A e B na aplica��o de teste,
> e o resultado foi id�ntico tanto quanto eu compilo no VS como no
> Cygwin, no entanto, dois arquivos espec�ficos est�o dando essa diferen�a.
>
>
> Algu�m tem alguma explica��o sobre isso?
>
>
Voc� est� inicializando *resultado antes (caso fa�a) a leitura (ou soma,
incremento) desse ponteiro?


Adriano

[Tiago Alves]

*resultado está sendo inicializado, mas de qualquer forma ele é apenas saída. A função da DLL no final faz uma atribuição a ele.

Em 14 de maio de 2013 16:35, Adriano dos Santos Fernandes <adri...@gmail.com> escreveu:

On 14/05/2013 16:28, Tiago Alves wrote:
> Pessoal,
>

> estou com uma situação estranha aqui. O cenário é o seguinte.
>

> Nós temos uma DLL aqui, compilada com o VS2010, essa DLL exporta uma
> função que processa recebe (char* A, char* B, float* resultado).

> Esse projeto do VS gera a DLL e o .lib, como de costume.
>

> Temos então uma aplicação de teste, que carrega dois arquivos binários

> e copia para A e B respectivamente.

> Quando a aplicação de teste é compilada também no VS2010 e utilizo o
> .lib para ter acesso às funções da DLL, o resultado o float resultado

> recebe um valor de 621.359253.

> No entanto, quando eu compilo a mesma aplicação de teste no Cygwin,

> faço a linkagem com o .lib para ter acesso à DLL, eu tenho um float
> resultado de 640.776672.
>
> Obs: Eu processei vários outros arquivos A e B na aplicação de teste,
> e o resultado foi idêntico tanto quanto eu compilo no VS como no

> Cygwin, no entanto, dois arquivos específicos estão dando essa diferença.
>
>
> Alguém tem alguma explicação sobre isso?
>
>

Você está inicializando *resultado antes (caso faça) a leitura (ou soma,
incremento) desse ponteiro?


Adriano

--
Antes de enviar um e-mail para o grupo leia:
                     http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

--
---------------------------------------------------
 Tiago Alves de Oliveira

[Virgilio Fornazin]

poe cout dentro das rotinas da sua DLL e testa...

2013/5/14 Tiago Alves <tiago...@gmail.com>

[Adriano dos Santos Fernandes]

On 14/05/2013 16:36, Tiago Alves wrote:
> *resultado est� sendo inicializado, mas de qualquer forma ele � apenas
> sa�da. A fun��o da DLL no final faz uma atribui��o a ele.
>

E o que � A e B? S�o strings null-terminated, e caso sejam, voc� est�
verificando se nois dois casos elas est�o terminadas corretamente?

E se n�o forem, como voc� decide at� onde ler estes ponteiros?


Adriano

[Tiago Alves]

Adriano,

esses A e B são dados serializados de acordo com um padrão. Um byte específico desse arquivo indica o tamanho do todo, com isso, é possível saber até onde ler.

Em 14 de maio de 2013 16:38, Adriano dos Santos Fernandes <adri...@gmail.com> escreveu:

On 14/05/2013 16:36, Tiago Alves wrote:

> *resultado está sendo inicializado, mas de qualquer forma ele é apenas

> saída. A função da DLL no final faz uma atribuição a ele.
>

E o que é A e B? São strings null-terminated, e caso sejam, você está
verificando se nois dois casos elas estão terminadas corretamente?

E se não forem, como você decide até onde ler estes ponteiros?

Adriano

--
Antes de enviar um e-mail para o grupo leia:
                     http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

[André Tupinambá]

Realmente esse é estranho.

Tenta criar a DLL no MSVC usando run-time estático.

Meu chute é que você está usando alguma função (sin, cos, etc.) em loop que está direcionando para alguma função de dentro do cygwin e acumulando muito o erro.

[]'s

André

2013/5/14 Tiago Alves <tiago...@gmail.com>

[Adriano dos Santos Fernandes]

On 14/05/2013 16:43, Tiago Alves wrote:
> Adriano,
>

> esses A e B s�o dados serializados de acordo com um padr�o. Um byte
> espec�fico desse arquivo indica o tamanho do todo, com isso, �
> poss�vel saber at� onde ler.
>
Ok. Verifica tamb�m se o arquivo que d� problema tem uma seq��ncia \r\n
enquanto os outros n�o.

Se � a aplica��o cliente que carrega os arquivos, o c�digo com Cygwin
pode tratar isso de maneira diferente do Windows.

Mas como o outro colega falou, debugando a DLL e vendo onde ocorre a
primeira diferen�a seria a melhor maneira de descobrir o que est�
acontecendo.


Adriano

[Tiago Alves]

André,

você diz compilar com MT? Já estamos fazendo isso. 

Para mim, eu compilar uma aplicação cliente, em outro compilador não deveria influenciar em como a DLL executa suas tarefas. 

Adriano, vou verificar aqui se as entradas estão sendo idênticas.

Em 14 de maio de 2013 16:49, Adriano dos Santos Fernandes <adri...@gmail.com> escreveu:

On 14/05/2013 16:43, Tiago Alves wrote:
> Adriano,
>

> esses A e B são dados serializados de acordo com um padrão. Um byte

> específico desse arquivo indica o tamanho do todo, com isso, é
> possível saber até onde ler.
>

Ok. Verifica também se o arquivo que dá problema tem uma seqüência \r\n
enquanto os outros não.

Se é a aplicação cliente que carrega os arquivos, o código com Cygwin

pode tratar isso de maneira diferente do Windows.

Mas como o outro colega falou, debugando a DLL e vendo onde ocorre a

primeira diferença seria a melhor maneira de descobrir o que está
acontecendo.

Adriano

--
Antes de enviar um e-mail para o grupo leia:
                     http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

[Lourenço]

A versao dos compiladores sao compativeis? (ambos 64 bits, por exemplo)

[André Tupinambá]

Era o MT sim.

Teria alguma forma dos dados de entrada virem em ordem diferente em cada um dos casos? Para acumular erro de forma diferente?

[]'s

André

2013/5/14 Tiago Alves <tiago...@gmail.com>

André,

[Rodrigo Strauss]

Onde você está vendo o resultado? No debugger ou em algum log? Pode ser diferença de apresentação.

Rodrigo Strauss
http://www.1bit.com.br
@rodrigostrauss

2013/5/15 André Tupinambá <andr...@gmail.com>

[Tiago Alves]

Pessoal,

só melhorando uma informação aqui, que com certeza faz diferença. Quando eu disse que a aplicação compilada com VS dava um retorno de 621.359253, na verdade, esse valor é 0,621359253 e o compilado no Cygwin é 0,640776672.

Eu esqueci de comentar que multiplicamos por 1000 o valor retornado pela DLL.

Vou fazer o teste para verificar se as entradas estão idênticas agora e comento aqui.

Perguntaram aqui, qual seria o resultado esperado. Infelizmente é complicado dar essa resposta, pois os dois valores confirmam que os dados A e B são compatíveis. No entanto, para eu dizer qual é o resultado EXATO que deveria dar, só rodando o algoritmo na mão aqui, e como não é muito simples e envolve uma certa quantidade de cálculos, fica bem complicado fazer.

[Alex Queiroz]

Olá,

Há vários modos que influenciam a forma que as instruções de ponto
flutuante do processador trabalham. Há 4 modos de arredondamento, por
exemplo. O runtime do VS provavelmente configura essas flags de forma
diferente que o runtime do Cygwin.

--
-alex
http://unendli.ch/

[Tiago Alves]

Mas a aplicação cliente que é responsável por configurar o arrendondamento de uma DLL em separada? Acho que minha dúvida é principalmente essa, visto que a DLL só foi compilada no VS.

Se alguém confirmar que a aplicação cliente influencia nos tipos de dados de uma DLL que ela utiliza, então acho que fica esclarecido.

--
Antes de enviar um e-mail para o grupo leia:
                     http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira:  vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en

[Alex Queiroz]

Olá,

2013/5/15 Tiago Alves <tiago...@gmail.com>:

> Mas a aplicação cliente que é responsável por configurar o arrendondamento
> de uma DLL em separada? Acho que minha dúvida é principalmente essa, visto
> que a DLL só foi compilada no VS.
>

O código da DLL é irrelevante nessa hipótese, pois são as instruções
do processador que se comportam de forma diferente, dependendo do modo
de arredondamento. Essa flag da CPU pode ter sido configurada de uma
forma pelo runtime do Cygwin e de outra pelo runtime do VS. Para ter
certeza de que não é esse o caso, configure a FPU você mesmo antes de
chamar funções da DLL.

--
-alex
http://unendli.ch/

[P.]

Em quarta-feira, 15 de maio de 2013 09h30min52s UTC-3, Tiago Alves escreveu:

 

só melhorando uma informação aqui, que com certeza faz diferença. Quando eu disse que a aplicação compilada com VS dava um retorno de 621.359253, na verdade, esse valor é 0,621359253 e o compilado no Cygwin é 0,640776672.

Eu esqueci de comentar que multiplicamos por 1000 o valor retornado pela DLL.

De qualquer forma, está claro que a mantissa está diferente.

O foco desta análise está no número final, e a sensação de absurdo me parece correta: para a mesma entrada e a mesma DLL (e a mesma configuração no ambiente de ligação dinâmica, dependências etc.) a saída deve ser a mesma.

Agora, qual é a certeza de que a entrada é exatamente a mesma? A mantissa da entrada em ambas as compilações é idêntica na entrada da rotina?

--
 P.

[Tiago Alves]

P.,

nós temos o seguinte:

1) A DLL recebe A e B, e uma classe deserializa esses dados, gerando um vector<Ponto>, onde Ponto é uma struct que armazena short X, short Y e double Alfa. 

2) Após a deserialização, a função que realmente faz as contas, recebe esses dois vectors. Nós escrevemos em disco os conjuntos de valores X,Y e Alfa para os dois casos e eles são idênticos.

Ou seja, entradas idênticas e saídas diferentes da DLL. A única explicação que eu vejo, é alguma configuração de compilação da aplicação cliente, mas não sei se isso iria interferir na forma como a DLL atua nos valores.

Abs

--

Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
 
 
 

[Gianni .]

On Wednesday 15 May 2013 11:09:29 P. wrote:

> O foco desta análise está no número final, e a sensação de absurdo me parece

> correta: para a mesma entrada e a mesma DLL (e a mesma configuração no

> ambiente de ligação dinâmica, dependências etc.) a saída deve ser a mesma.

Não será só o caso dos dois resultados estarem entrelaçados? E só na hora que se imprime o resultado, é que ele resolve para um valor ou outro?

 

Tiago,

Você esta usando x86, x86-64 ou um computador quântico?

[Adriano dos Santos Fernandes]

On 15/05/2013 10:46, Alex Queiroz wrote:
> Ol�,
>
> 2013/5/15 Tiago Alves <tiago...@gmail.com>:
>> Mas a aplica��o cliente que � respons�vel por configurar o arrendondamento
>> de uma DLL em separada? Acho que minha d�vida � principalmente essa, visto
>> que a DLL s� foi compilada no VS.
>>
> O c�digo da DLL � irrelevante nessa hip�tese, pois s�o as instru��es

> do processador que se comportam de forma diferente, dependendo do modo
> de arredondamento. Essa flag da CPU pode ter sido configurada de uma
> forma pelo runtime do Cygwin e de outra pelo runtime do VS. Para ter

> certeza de que n�o � esse o caso, configure a FPU voc� mesmo antes de
> chamar fun��es da DLL.
>
>
Tiago, veja fun��es como _control87 e _controlfp.

http://msdn.microsoft.com/en-us/library/e9b52ceh(v=vs.71).aspx
<http://msdn.microsoft.com/en-us/library/e9b52ceh%28v=vs.71%29.aspx>


Adriano

[P.]

Em quarta-feira, 15 de maio de 2013 15h18min22s UTC-3, Tiago Alves escreveu:

 

nós temos o seguinte:

1) A DLL recebe A e B, e uma classe deserializa esses dados, gerando um vector<Ponto>, onde Ponto é uma struct que armazena short X, short Y e double Alfa. 

2) Após a deserialização, a função que realmente faz as contas, recebe esses dois vectors. Nós escrevemos em disco os conjuntos de valores X,Y e Alfa para os dois casos e eles são idênticos.

Outra perspectiva: a mantissa do valor está diferente na saída da função, ou a formatação do valor pela função de I/O no dispositivo de saída está diferente?

Não está claro pra mim que os valores estão sendo comparados em um debugger adequado, e printf tem diversas liberdades.

--
 P.

[Ivo Calado]

Gianni, faria diferença num caso como esses a arquitetura visto que o 754 é o mesmo?

2013/5/15 Gianni . <nasus....@gmail.com>

--

Antes de enviar um e-mail para o grupo leia:
http://www.ccppbrasil.org/wiki/Lista:AntesdePerguntar
--~--~---------~--~----~---------------------------------~----------~--~----~
[&] C & C++ Brasil - http://www.ccppbrasil.org/
Para sair dessa lista, envie um e-mail para ccppbrasil-...@googlegroups.com
Para mais opções, visite http://groups.google.com/group/ccppbrasil
--~--~---------~--~----~--~-~--~---~----~-----------------~--~----------~
Emprego & carreira: vag...@ccppbrasil.org
http://groups.google.com/group/dev-guys?hl=en
 
 
 

--
Ivo Calado

Quidquid latine dictum sit, altum viditur

Putt's Law:
       Technology is dominated by two types of people:
               Those who understand what they do not manage.
               Those who manage what they do not understand.

[Tiago Alves]

@Gianni:

SO: 64 bits

Aplicação: 32bits

@P.

Nós utilizamos printf, cout e fprintf para imprimir os resultados. Será que pode ser questão de I/O?

[P.]

Em quarta-feira, 15 de maio de 2013 15h55min02s UTC-3, Tiago Alves escreveu:

@Gianni:

SO: 64 bits

Aplicação: 32bits

@P.

Nós utilizamos printf, cout e fprintf para imprimir os resultados. Será que pode ser questão de I/O?

A minha primeira suspeita seria nas matérias de representação e armazenagem.
Eu, pessoalmente, não estou ciente de quais liberdades tem a implementação de ponto-flutuante do Visual Studio 2010 e do Cygwin, e onde essas liberdades podem variar.
Por isso desconfio que as mantissas nas idas e vindas aí podem ser simplesmente diferentes da sua expectativa.
Observe que nada disso significaria que existe um defeito no software em algum lugar.
Fato é que as implementações de ponto-flutuante têm várias liberdades, e que os algoritmos de ponto flutuante devem cuidar disso.

--
 P.