Design: NaN 비트가 완전히 결정적이지 않은 이유 문서화

주목해야 할 또 다른 사항은 NaN 비트가 실수로 관찰하기 어렵다는 것입니다.

그것들을 관찰하거나 최소한 부호 비트를 관찰할 수 없도록 하는 방법이 있습니까?

IMO NaN 비결정론은 소프트웨어가 이를 신경 쓰는 경우가 매우 드물기 때문에 그대로 두어야 합니다. 성능을 결정적으로 만들기 위해 희생하는 경우는 무엇입니까?

다음은 NaN 비트를 관찰할 수 있는 방법의 목록입니다.

• reinterpret 전환
• store 를 선형 메모리에 저장하고 다른 해석으로 비트를 로드합니다(또는 외부에서 비트를 관찰하도록 함).
• 가져온 함수의 call 에 인수를 전달하거나 내보낸 함수에서 값을 반환합니다.
• copysign 비 NaN에 대한 부호 비트

VM은 이들 각각 앞에 정규화 코드를 삽입할 수 있습니다. 그것이 위에서 논의한 "이스케이프 포인트에서 정규화" 아이디어입니다. store 는 핫 경로에서 매우 일반적이므로 여전히 상당히 비쌉니다.

@qwertie 저는 그것들에 대해 매우 관심을 갖고 여기에서 논의된 것처럼 사양에 포함되지 않더라도 완전히 결정적으로 만드는 방법이 있습니다.

@qwertie 이점에는 약간 더 큰 이식성(예: IEEE 754 totalOrder 함수를 현명하지 않게 사용하는 코드가 세상에 존재함), 약간 더 높은 재현성, 여러 노드에서 대칭 계산을 수행할 때 더 강한 불변성이 포함될 수 있습니다.

store 는 핫 경로에서 매우 일반적이므로 여전히 상당히 비쌉니다.

이 경우 항상 부호 값을 지정할 수 있습니까? 그래서 mem에 배치되면 1로 만드시겠습니까?

@wanderer 이것이 본질적으로 정규화가 수반되는 것입니다. 값이 NaN인지 확인하고, 그렇다면 약간의 수정을 적용합니다. 일반적으로 핫 경로의 추가 비교 및 ​​분기입니다.

또한 이 문제에서 언급한 옵션을 벤치마킹하지 않았습니다. 여기에 추가할 수 있는 모든 벤치마킹을 환영합니다.

나는 성능을 선호하는 현재 수준의 비결정론에 강하게 기댈 것입니다.
나는 실제로 was가 NaN의 가수 비트를 엄격하게 정의한다는 사실에 다소 놀랐습니다.
이것이 오늘날의 프로세서에 충분할 수 있지만 미래의 프로세서가 무엇인지 누가 알 수 있습니까?

wasm이 고급 언어에서 생성되는 경우 해당 번역기는 예를 들어 -ffast-math와 유사한 FP 의미 체계의 수준을 제어하는 ​​옵션을 제공할 수 있습니다. 그런 다음 번역가는 nan을 원하는 형식으로 강제 변환하는 데 필요한 추가 wasm 수정을 삽입할 수 있습니다. 그 목적을 위해 우리는 isNan 또는 normalizeNan 연산자를 제공할 수 있지만, 지금은 이것을 옹호하지 않습니다.

요컨대, 이것을 "수정"하는 것은 더 높은 수준의 도구인 IMO에 맡기는 것이 가장 좋습니다.

+1 @mbodart. 편집 : 오, 실제로 +1 물건이 있습니다. :). Btw, 나는 개인적으로 Wasm = 세계 지배라고 생각하며 따라서 미래의 프로세서는 그것을 적대시하지 않을 것입니다.

결정을 내리기 전에 이것의 성능 효과를 정량화하고 싶습니다. 나는 우리의 툴체인이 현재로서는 좋은 성능 측정을 하기에는 아직 미성숙하다고 생각합니다. 다른 말로 하자면, 나는 "천자국에 의한 죽음"을 피하고 싶습니다.

@jfbastien에 동의합니다. 의미론을 수정하기 전에 성능 효과를 먼저 수량화해야 합니다.

분명히 말씀드리자면, 저는 현재 여기에서 변화를 옹호하는 것이 아닙니다. 근거자료를 수집하고 있습니다. NaN 비트 비결정론이 튀어나와 설명을 원합니다. 그리고 내가 아는 한 아무도 이러한 비트를 비결정적으로 만드는 성능 효과를 정량화하지 않았습니다.

ARMv8은 두 피연산자가 모두 NaN인 경우 첫 번째 피연산자를 항상 전파하지는 않습니다. 규칙은 다음과 같습니다.

• 한 피연산자가 조용한 NaN이고 다른 피연산자가 신호 NaN이면 신호 NaN을 전파합니다.
• 그렇지 않으면 첫 번째 피연산자를 전파합니다.

사양을 읽는 동안 이것은 ARMv8의 Aarch32 및 Aarch64 모드 모두에 적용됩니다.

이 동작은 두 경우 모두에서 첫 번째 피연산자를 전파하는 SSE와 다릅니다.

두 아키텍처 모두 전파하기 전에 조용한 비트를 설정하여 sNaN을 qNaN으로 변환합니다.

@stoklund 좋은 자리! ARM이 첫 번째 NaN을 선택하는 것은 두 번째 NaN이 신호를 보내는 경우에 발생하지 않는다는 것을 놓쳤습니다. 이는 위의 다중 NaN 사례에 대해 내가 제시한 전략을 복잡하게 만들 수 있으므로 근거에서 이를 언급할 수 있습니다.

이제 위의 내용을 요약한 특정 텍스트를 제안하기 위해 #973을 만들었습니다.