Come assicurarsi che i NaN si propagino quando si utilizzano gli intrinseci SSE?

Ho letto recentemente questo circa NaN valori nelle operazioni aritmetiche SSE:Come assicurarsi che i NaN si propagino quando si utilizzano gli intrinseci SSE?

Il risultato di operazioni aritmetiche che agiscono su due non un numero (NAN) argomenti è indefinito. Pertanto, le operazioni in virgola mobile che utilizzano gli argomenti NAN non corrisponderanno al comportamento previsto delle istruzioni di assemblaggio corrispondenti.

Fonte: http://msdn.microsoft.com/en-us/library/x5c07e2a(v=vs.100).aspx

Questo significa che, per esempio, l'aggiunta di due __m128 valori potrebbero convertire un NaN ad un vero e proprio?

Se un calcolo si basa su un valore NaN, è necessario che il risultato finale sia NaN. C'è un modo per fare questo?

fonte

2013-03-22 Inverse

Penso che sia eccessivamente pedante. Le istruzioni SSE a virgola mobile dovrebbero seguire il comportamento in virgola mobile IEEE piuttosto rigorosamente a meno che non si faccia roba come denormali o qualcosa del genere. – Mysticial

@Mysticial: Non sta dicendo che le istruzioni SSE non forniranno i risultati previsti. Sta dicendo che il compilatore potrebbe non usare le istruzioni SSE per implementare intrinseche di tipo SSE. –

@EricPostpischil Vedo quello che stai dicendo. Ma finora non ho ancora visto accadere qualcosa del genere. Quindi non ne sono completamente convinto. – Mysticial

Mentre interpreto il testo, quello che sta dicendo è che il compilatore offre vari elementi intrinseci che corrispondono approssimativamente alle istruzioni SSE. In genere, ci si può aspettare che il compilatore utilizzi le istruzioni SSE per implementare gli intrinsechi. Tuttavia, questo non è severo. Gli intrinseci in realtà specificano le operazioni in un modello astratto di computazione; non specificano direttamente le istruzioni SSE. In questo modello astratto, il risultato di operare su due NaN (strano che non sembra consentire un NaN e un numero) non è definito. Pertanto, il risultato ottenuto, ad esempio, l'aggiunta di due NaN potrebbe non essere un NaN.

In particolare, le operazioni nel modello astratto sarebbero soggette a ottimizzazioni del compilatore e tali ottimizzazioni potrebbero risultare in operazioni diverse dalle istruzioni SSE (calcoli in fase di compilazione, istruzioni omesse se il compilatore può dedurre che i NaN sono presenti non è necessario eseguire effettivamente un add, eccetera).

Sembra che se si desidera garantire la semantica specificata per le istruzioni SSE, potrebbe essere necessario scrivere in linguaggio assembly piuttosto che utilizzare intrinseche nel compilatore di Microsoft.

Vorrei che i venditori smettessero di dare una scarsa attenzione alla semantica a virgola mobile. È difficile fare ingegneria in assenza di un comportamento ben specificato.

fonte

2013-03-22 00:31:22

C'è una possibilità relativamente benigna. Potrebbe sempre produrre un NaN, ma non necessariamente uno che si riferisce in modo coerente ai NaN di input.Se questo è il caso, sarebbe utile averlo documentato. –

Sembra che potrebbe essere un problema se due valori potrebbero essere dimostrati dal compilatore come 'NaN' e c'era un motivo convincente per il compilatore di trarne vantaggio, imho: il primo non sembra probabile e l'ultimo dei quali è difficile trovare un esempio di ... –

@PatriciaShanahan: Sembra probabile. Quale dei due input NaN un'istruzione ritorni spesso dipende dall'ordine degli operandi, e il compilatore potrebbe benissimo non conservare l'ordine dall'intrinseco alle istruzioni. Ciò porterebbe alla necessità di documentare che quale dei due NaN è restituito non è definito, e una gestione sciatta di ciò potrebbe portare alla documentazione che afferma che il risultato di operare su due NaN non è definito. Nondimeno, la documentazione dice quello che dice. –

Come assicurarsi che i NaN si propagino quando si utilizzano gli intrinseci SSE?

risposta

Problemi correlati