지명

P-high에 대해 허용됨, # 10183과 동일한 추론

나는 이것이 언어 수준에서 이전 버전과 호환되지 않는다고 생각하지 않습니다. 정상적으로 작동하던 코드의 작동이 중지되지는 않습니다. 지명.

P-high로 변경, # 10183과 동일한 추론

이 문제와 # 10185를 해결하기 위해 어떻게 제안합니까? 동작이 정의되는지 여부는 캐스팅되는 숫자의 동적 값에 따라 다르기 때문에 유일한 해결책은 동적 검사를 삽입하는 것 같습니다. 산술 오버플로에 대해 그렇게하고 싶지 않다는 데 동의하는 것 같습니다. 캐스트 오버플로에 대해 수행해도됩니까?

"안전한 변환"을 수행하는 LLVM에 내장 함수를 추가 할 수 있습니다. @zwarich 는 다른 아이디어가있을 수 있습니다.

AFAIK는 현재 유일한 솔루션은 타겟 별 내장 함수를 사용하는 것입니다. 적어도 내가 물어 본 사람에 따르면 JavaScriptCore 가하는 일입니다.

오, 그럼 충분히 쉽습니다.

ping @pnkfelix 가 새로운 오버플로 검사 항목으로 덮여 있습니까?

이러한 캐스트는 디버그 어설 션으로 rustc에 의해 확인되지 않습니다.

나는 이것을 처리하게되어 기쁘지만 구체적인 해결책이 필요합니다. 나는 개인적으로 매우 유사한 문제이기 때문에 오버플로 정수 산술과 함께 확인해야한다고 생각합니다. 나는 우리가 무엇을하는지 정말로 신경 쓰지 않는다.

이 문제는 현재 특정 상수 표현식에서 사용될 때 ICE를 유발합니다.

이것은 다음 포럼 게시물의 예

Undefs, 응? Undefs는 재미 있습니다. 그들은 번식하는 경향이 있습니다. 몇 분의 랭 글링 후 ..

#[inline(never)]
pub fn f(ary: &[u8; 5]) -> &[u8] {
    let idx = 1e100f64 as usize;
    &ary[idx..]
}

fn main() {
    println!("{}", f(&[1; 5])[0xdeadbeef]);
}

-O를 사용하여 내 시스템 (최신 야간)에서 segfaults.

안전한 녹의 메모리 안전성을 위반 한 I-unsound로 표시.

@bluss , 이것은 나를 위해 segfualt가 아니라 단언 오류를 제공합니다. 내가 추가 한 사람이기 때문에 태그 해제

한숨, 나는 -O, 다시 태그를 잊었다.

P-high에 대한 재 지명. 분명히 이것은 어느 시점에서 P-high 였지만 시간이 지남에 따라 낮아졌습니다. 이것은 정확성을 위해 매우 중요해 보입니다.

편집 : 분류 주석에 반응하지 않고 수동으로 레이블을 추가했습니다.

오버 플로우 (예 : 시프 팅)의 전례는 단지 어떤 행동에 안주하는 것 같습니다. Java는 범위 모듈로 결과를 생성하는 것 같습니다. 이는 불합리하지 않은 것 같습니다. 나는 우리가 그것을 처리하는 데 필요한 LLVM 코드의 종류를 잘 모르겠습니다.

https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls -5.1.3에 따르면 Java는 NaN 값이 0 및 무한대로 매핑되도록 보장합니다. 표현 가능한 최소 / 최대 정수로. 또한 변환을위한 Java 규칙은 단순히 래핑하는 것보다 더 복잡합니다. 포화 ( int 또는 long 로의 변환)와 래핑 (더 작은 정수 유형으로의 변환)의 조합 일 수 있습니다. , 필요한 경우). Java에서 전체 변환 알고리즘을 복제하는 것은 확실히 가능하지만 모든 캐스트에 대해 상당한 양의 작업이 필요합니다. 특히 LLVM에서 fpto[us]i 작업의 결과가 정의되지 않은 동작을 나타내지 않도록하려면 범위 검사가 필요합니다.

대안으로 float-> int 캐스트는 원래 값의 잘림이 대상 유형의 값 (또는 [iu]size ?)으로 표현 될 수있는 경우에만 유효하다고 보장하고 값이 충실하게 표현되지 않았을 때 패닉을 유발하는 디버그 빌드에 대한 주장이 있습니다.

Java 접근 방식의 주요 장점은 변환 기능이 전체적이라는 것입니다. 그러나 이는 예기치 않은 동작이 발생할 수 있다는 것을 의미합니다. 정의되지 않은 동작을 방지 할 수 있지만 캐스트가 실제로 의미가 있는지 확인하지 않도록 속이기 쉽습니다. (이것은 불행히도 다른 캐스트에도 해당됩니다 : worried :).

다른 접근 방식은 현재 산술 연산에 사용되는 접근 방식과 일치합니다. 릴리스의 간단하고 효율적인 구현, 디버그의 범위 검사에 의해 트리거되는 패닉. 안타깝게도 다른 as 캐스트와는 달리 이러한 변환이 확인되어 사용자에게는 놀라운 일이 될 수 있습니다 (아마도 여기서 산술 연산에 대한 비유가 도움이 될 수 있음). 이것은 또한 일부 코드를 손상시킬 수 있지만 AFAICT는 현재 정의되지 않은 동작에 의존하는 코드에서만 발생해야합니다 (즉, 정의되지 않은 동작 "정수를 반환하자, 당연히 어느 것이 든 상관하지 않습니다"를 패닉으로 대체합니다).

문제는 "정수를 반환하자, 당신은 분명히 어느 것을 신경 쓰지 않는다"가 아니라, 그것은 임의의 값이 아닌 비강 악마 값인 undef를 유발하고 LLVM은 undef가 발생하지 않는다고 가정 할 수 있다는 것입니다. 끔찍한 잘못된 작업을 수행하는 최적화를 가능하게합니다. 무작위 값이지만 결정적으로 undef가 아니라면 건전성 문제를 해결하기에 충분할 것입니다. 표현할 수없는 값이 어떻게 표현되는지 정의 할 필요가 없습니다. undef를 막기 만하면됩니다.

@ rust-lang / compiler 회의에서 논의되었습니다. 가장 일관된 조치는 다음과 같습니다.

1. 오버플로 확인이 활성화되면 잘못된 캐스트 및 패닉을 확인합니다.
2. 그렇지 않으면 폴백 동작이 필요합니다. 유효한 값에 대해 최소한의 (이상적으로는 0) 런타임 비용이 있어야하지만 LLVM undef가 아닌 한 정확한 동작은 그다지 중요하지 않습니다.

주요 문제는 옵션 2에 대한 구체적인 제안이 필요하다는 것입니다.

분류 : P- 중간

@nikomatsakis as 가) 현재 디버그 빌드에서 패닉 상태가됩니까? 그렇지 않은 경우 일관성과 예측 가능성을 위해 그대로 유지하는 것이 좋습니다. (나는 그것이 산술과 마찬가지로 _해야한다고 생각하지만, 그것은 별개의 과거의 논쟁입니다.)

그렇지 않으면 폴백 동작이 필요합니다. 유효한 값에 대해 최소한의 (이상적으로는 0) 런타임 비용이 있어야하지만 LLVM undef가 아닌 한 정확한 동작은 그다지 중요하지 않습니다.

구체적인 제안 : 숫자와 지수를 u64 로 추출하고 지수로 비트 시프트 숫자를 추출합니다.

fn f64_as_u64(f: f64) -> u64 {
    let (mantissa, exponent, _sign) = f.integer_decode();
    mantissa >> ((-exponent) & 63)
}

예, 비용이 0은 아니지만 다소 최적화 가능하며 ( integer_decode inline 표시하면 더 좋을 것입니다) 적어도 결정적입니다. float-> int 캐스트를 확장하는 미래의 MIR-pass는 아마도 float가이 무거운 변환을 캐스트하고 건너 뛸 수 있는지 여부를 분석 할 수 있습니다.

LLVM에는 변환 기능에 대한 플랫폼 내장 함수가 없습니까?

편집 : @zwarich 는 말했다 (오래 전) :

AFAIK는 현재 유일한 솔루션은 타겟 별 내장 함수를 사용하는 것입니다. 적어도 내가 물어 본 사람에 따르면 JavaScriptCore 가하는 일입니다.

왜 당황 하는가? AFAIK, @glaebhoerl 이 정확하고, as 는 자르기 / 확장해야하며, 피연산자를 확인하지 _ 않습니다.

2016 년 3 월 5 일 토요일 03:47:55 AM -0800, Gábor Lehel은 다음과 같이 썼습니다.

@nikomatsakis as 가) 현재 디버그 빌드에서 패닉 상태가됩니까? 그렇지 않은 경우 일관성과 예측 가능성을 위해 그대로 유지하는 것이 좋습니다. (나는 그것이 산술과 마찬가지로 _해야한다고 생각하지만, 그것은 별개의 과거의 논쟁입니다.)

진실. 설득력이 있습니다.

2016 년 3 월 9 일 수요일 02:31:05 AM -0800에 Eduard-Mihai Burtescu는 다음과 같이 썼습니다.

LLVM에는 변환 기능에 대한 플랫폼 내장 함수가 없습니까?

수정 :

AFAIK는 현재 유일한 솔루션은 타겟 별 내장 함수를 사용하는 것입니다. 적어도 내가 물어 본 사람에 따르면 JavaScriptCore 가하는 일입니다.

왜 당황 하는가? AFAIK, @glaebhoerl 이 정확하고, as 는 자르기 / 확장해야하며, 피연산자를 확인하지 _ 않습니다.

네, 전에 착각 한 것 같아요. as 는 "선택되지 않은 잘림"입니다.
더 좋든 나쁘 든, 일관성을 유지하는 것이 가장 좋습니다.
그 철학으로. 타겟 별 내장 함수를 사용하면 완벽하게
그래도 좋은 해결책?

@nikomatsakis : 동작이 아직 정의되지 않은 것 같습니다. 그것에 관한 계획에 대한 업데이트를 줄 수 있습니까?

훨씬 적은 숫자로이 문제를 만났습니다.

    let x: f64 = -1.0;
    x as u8

최적화에 따라 0, 16 등의 결과가 나오며, 255로 정의되기를 바랐으므로 x as i16 as u8 를 쓸 필요가 없습니다.

@gmorenz !0u8 해보 셨나요?

말이 안되는 상황에서 저는 네트워크를 통해 전송 된 데이터에 대한 변환에서 f64를 [-255, 255] 범위로 얻었습니다. 나는 그것이 멋지게 포장되기를 바랬다 ( <i32> as u8 포장하는 것과 똑같은 방식으로).

여기에 "kill undef" http://lists.llvm.org/pipermail/llvm-dev/2016-October/106182.html에 대한 최근 LLVM 제안이 있습니다. 이 문제.

그들은 undef를 포이즌으로 대체하고 있으며, 의미는 약간 다릅니다. int-> float 캐스트 정의 된 동작을 만들지는 않을 것입니다.

우리는 아마 포화 캐스트를 할 수있는 몇 가지 명시적인 방법을 제공해야합니까? 나는 지금 바로 그 정확한 행동을 원했습니다.

https://github.com/rust-lang/rust/issues/10184#issuecomment -139858153이 주어지면 I-crash로 표시되어야합니다.

오늘 #rust-beginners 에서 이것에 대한 질문이있었습니다. 누군가가 야생에서이 문제를 만났습니다.

@jimblandy , _Programming Rust_와 함께 쓰고있는 책은이 버그를 언급합니다.

여러 종류의 캐스트가 허용됩니다.

• 숫자는 기본 제공 숫자 유형에서 다른 유형으로 캐스트 될 수 있습니다.

  (...)

  그러나이 글을 쓰는 시점에서 큰 부동 소수점 값을 너무 작아서 나타낼 수없는 정수 유형으로 캐스팅하면 정의되지 않은 동작이 발생할 수 있습니다. 이것은 안전한 Rust에서도 충돌을 일으킬 수 있습니다. 컴파일러 github.com/rust-lang/rust/issues/10184 의 버그입니다.

이 장의 마감일은 5 월 19 일입니다. 마지막 단락을 삭제하고 싶지만, 적어도 여기에서 먼저 어떤 종류의 계획이 있어야한다고 생각합니다.

분명히 현재 JavaScriptCore는 x86 사용합니다 . 그들은 CVTTSD2SI 명령어를 사용하고 값이 범위를 벗어나면 털이 많은 C ++로 돌아갑니다. 현재 범위를 벗어난 값이 폭발하기 때문에 해당 명령어를 사용하면 (대체없이!) 현재 우리가 가진 것보다 개선 될 수 있지만 하나의 아키텍처에서만 가능합니다.

솔직히 저는 as 숫자 형 캐스트를 사용하지 않고 From 및 TryFrom 또는 conv crate와 같은 것을 사용해야한다고 생각합니다.

아마도 그럴 수도 있지만 그것은 나에게 직각 인 것 같습니다.

좋아요,이 모든 대화를 다시 읽었습니다. 이 작업이 당황해서는 안된다는 동의가 있다고 생각합니다 ( as 와의 일반적인 일관성을 위해). 행동이 어떻게되어야하는지에 대한 두 가지 주요 경쟁자가 있습니다.

• 일종의 정의 된 결과
  
  
  
  • 장점 : 이것은 지금까지 우리의 일반적인 철학과 최대한 일치 한다고 생각합니다.
  
  
  • 단점 :이 경우에 정의 된 특정 결과를 생성하는 진정한 이식 방법은없는 것 같습니다. 이것은 우리가 범위를 벗어난 값에 대해 일종의 폴백 (예를 들어 @ oli-obk가 제안한이 함수 , saturation 으로 폴백 , Java의 정의 또는 "털이 많은 C ++" 로 폴백으로 폴백하는 플랫폼 별 내장 함수를 사용함을 의미합니다 ) JSC는 .
  
  
  • 최악의 경우 "범위를 벗어난"경우에 대한 일부 if를 삽입 할 수 있습니다.
  
  
• 정의되지 않은 값 (정의되지 않은 동작 아님)
  
  
  
  • 장점 :이를 통해 각 플랫폼에서 사용할 수있는 플랫폼 별 내장 함수 만 사용할 수 있습니다.
  
  
  • 단점 : 휴대 성 위험입니다. 일반적으로 최소한 언어로 는 정의되지 않은 결과를 자주 사용하지 않은 것 같습니다 (여러 곳의 libs에서 수행한다고 확신합니다).
  
  

첫 번째 경우에 어떤 결과 가되어야 하는지에 대한 명확한 선례가 있는지 확실하지 않습니다.

그것을 작성한 후 결정 론적 결과를 유지하는 것이 선호됩니다. 나는 우리가 결정론에 대한 경계를 유지할 수있는 모든 곳이 승리라고 느낍니다. 그래도 결과가 뭔지 잘 모르겠습니다.

나는 그것을 이해할 수 있고 유용 해 보이기 때문에 채도를 좋아하지만, u64 as u32 이 잘리는 방식과는 어딘지 모순되는 것 같습니다. 그래서 아마도 잘림을 기반으로 한 어떤 종류의 결과가 의미가 있을 것 입니다.

내 코드는 0..2 ^ 64 범위의 항목에 대해 올바른 값을 제공하고 다른 모든 항목에 대해서는 결정적이지만 가짜 값을 제공합니다.

부동 소수점은 가수 ​​^ 지수로 표시됩니다. 예를 들어 1.0 는 (2 << 52) ^ -52 이고 비트 시프트와 지수는 이진법에서 동일하므로 시프트를 반전 할 수 있습니다 (따라서 지수와 오른쪽의 부정 시프트).

결정론의 경우 +1.

나는 인간에게 좋은 의미를 두 가지보고 , 컴파일러가 계산을 최적화 할 수 없을 때 범위 내에있는 값에 대해 더 빠른 의미를 선택해야한다고 생각합니다. (컴파일러가 값이 범위 내에 있음을 알게되면 두 옵션 모두 동일한 결과를 제공하므로 똑같이 최적화 할 수 있습니다.)

• 채도 (범위를 벗어난 값은 IntType::max_value() / min_value() )
• 모듈로 (범위를 벗어난 값은 먼저 bigint로 변환 한 다음 잘라내는 것처럼 처리됨)

아래 표는 두 옵션을 모두 지정하기위한 것입니다. T 는 모든 머신 정수 유형입니다. Tmin 및 Tmax는 T::min_value() 및 T::max_value() 입니다. RTZ (v)는 v의 수학적 값을 취하고 수학적 정수를 얻기 위해 0으로 반올림 함을 의미합니다.

v | v as T (채도) | v as T (모듈로)
---- | ---- | ----
범위 내 (Tmin <= v <= Tmax) | RTZ (v) | RTZ (v)
마이너스 제로 | 0 | 0
NaN | 0 | 0
무한대 | Tmax | 0
-무한 | Tmin | 0
v> Tmax | Tmax | T에 맞게 잘린 RTZ (v)
v <Tmin | Tmin | T에 맞게 잘린 RTZ (v)

ECMAScript 표준은 작업 ToInt32 , ToUint32, ToInt16, ToUint16, ToInt8, ToUint8을 지정하고 위의 "모듈로"옵션을 사용하는 내 의도는 모든 경우에 해당 작업을 일치시키는 것입니다.

ECMAScript는 또한 위의 두 경우와 일치하지 않는 ToInt8Clamp 를 지정합니다. "0으로 반올림"이 아닌 소수 값에 대해 "반올림에서 짝수"로 반올림합니다.

@ oli-obk의 제안은 범위 내에있는 값에 대해 계산하는 것이 더 빠른지 고려할 가치가있는 세 번째 방법입니다.

@ oli-obk 부호있는 정수 유형은 어떻습니까?

관련 https://github.com/rust-lang/rust/issues/41799

다른 제안을 혼합에 던지기 : Mark u128은 안전하지 않은 플로트에 캐스팅하고 사람들이이를 처리하는 방법을 명시 적으로 선택하도록합니다. u128은 현재 매우 드뭅니다.

@Manishearth 비슷한 의미의 정수 → 부동 소수점 → 정수를 원합니다. 둘 다 UB-ful이고 더 이상 float → integer를 안전하지 않게 만들 수 없으므로 integer → float를 안전하지 않게 만드는 것도 피해야합니다.

float → integer saturating의 경우 AFAICT가 더 빨라집니다 (결과적으로 and , test + jump float 비교 및 ​​점프, 모두 현대 아치에서 0.66 또는 0.5 2-3 사이클). 나는 개인적으로 범위 내 값이 가능한 한 빠른 한 우리가 결정한 정확한 행동에 대해 덜 신경을 쓸 수 없습니다.

오버플로처럼 행동하는 것이 말이되지 않습니까? 따라서 디버그 빌드에서 정의되지 않은 동작으로 캐스트를 수행하면 패닉이 발생합니다. 그런 다음 1.04E+17.saturating_cast::<u8>() , unsafe { 1.04E+17.unsafe_cast::<u8>() } 및 잠재적으로 다른 것과 같은 캐스팅 동작을 지정하는 메서드를 가질 수 있습니다.

오, 나는 문제가 u128에만 해당한다고 생각했고 두 가지 방법으로 안전하지 않게 만들 수 있습니다.

@cryze UB는 안전 코드의 릴리스 모드에서도 존재하지 않아야합니다. 오버플로 항목은 여전히 ​​정의 된 동작입니다.

즉, 디버그시 패닉이 발생하고출시되면 좋을 것입니다.

이것은 다음에 영향을 미칩니다.

• f32 -> u8, u16, u32, u64, u128, usize (모두 -1f32 as _ , u128을 제외한 모두 f32::MAX as _ )
• f32 -> i8, i16, i32, i64, i128, isize (모두 f32::MAX as _ )
• f64 -> 모든 정수 (모두 f64::MAX as _ )

f32::INFINITY as u128 도 UB입니다.

@CryZe

오버플로처럼 행동하는 것이 말이되지 않습니까? 따라서 디버그 빌드에서 정의되지 않은 동작으로 캐스트를 수행하면 패닉이 발생합니다.

이것은 내가 처음에 생각,하지만 난 것을 상기 된 것입니다 as (우리는 함께 확인 오버 플로우하지 않는 변환이 현재 당황하지 as 좋든 나쁘 든). 따라서 가장 유사한 것은 "정의 된 작업을 수행"하는 것입니다.

FWIW, "kill undef"는 실제로 메모리의 안전하지 않은 문제를 해결하는 방법을 제공하지만 결과는 비 결정적입니다. 주요 구성 요소 중 하나는 다음과 같습니다.

3) 전파를 중지하는 새 명령어 '% y = freeze % x'를 만듭니다.
독. 입력이 독이면 임의의 값을 반환하지만 고정되어 있습니다.
값. (오래된 undef와 같지만 각 사용은 동일한 값을 얻습니다), 그렇지 않으면
입력 값을 반환합니다.

오늘날 undefs가 메모리 안전성을 위반하는 데 사용될 수있는 이유는 사용 사이, 특히 경계 검사와 후속 포인터 산술 사이에서 마술처럼 값을 변경할 수 있기 때문입니다. rustc이 모든 위험한 캐스트 후에 동결을 추가했다면, 당신은 알 수 없지만 잘 작동하는 값을 얻게 될 것입니다. 성능 측면에서 freeze는 기본적으로 무료입니다. 물론 캐스트에 해당하는 기계 명령은 변동하는 값이 아닌 단일 값을 생성하기 때문입니다. 옵티마이 저가 어떤 이유로 캐스트 명령어를 복제하는 것처럼 느껴지더라도 범위를 벗어난 입력에 대한 결과는 일반적으로 주어진 아키텍처에서 결정적이기 때문에 그렇게하는 것이 안전해야합니다.

...하지만 궁금한 점이 있다면 아키텍처 전반에 걸쳐 결정적이지는 않습니다. x86은 모든 잘못된 입력에 대해 0x80000000을 반환합니다. ARM은 범위를 벗어난 입력에 대해 포화 상태이며 (이 의사 코드를 오른쪽으로 읽는 경우) NaN에 대해 0을 반환합니다. 따라서 목표가 결정적이고 플랫폼 독립적 인 결과 를 생성하는 것이라면 플랫폼의 fp-to-int 내장 함수를 사용하는 것만으로는 충분하지 않습니다. 적어도 ARM에서는 예외에 대한 상태 레지스터도 확인해야합니다. 이것은 그 자체로 약간의 오버 헤드를 가질 수 있으며, intrinsic을 아직 사용하지 않은 드문 경우에 자동 벡터화를 확실히 방지합니다. 또는 정규 비교 작업을 사용하여 범위 내 값을 명시 적으로 테스트 한 다음 정규 float-to-int를 사용할 수 있습니다. 옵티 마이저에서 훨씬 더 좋게 들립니다…

as 전환은 현재 당황하지 않습니다.

어떤 시점에서 우리는 + 을 패닉 (디버그 모드에서)으로 변경했습니다. 이전에 UB였던 케이스에서 as 패닉을 본다고해서 놀라지 않을 것입니다.

우리가 (우리가해야하는) 확인에 관심이 있다면, 우리는 as (유일한 옵션 인 유스 케이스가 있습니까?)를 사용하지 않거나 최소한 사용하지 말라고 조언하고 사람들을 다음과 같은 것으로 이동시켜야합니다. TryFrom 및 TryInto 대신 as 을 (를) 그대로두기로 결정했을 때 되돌릴 계획 이라고 말한 것입니다. 나는 논의중인 사례 가 추상 에서 as 가 어떤 검사도하지 않도록 이미 정의 된 사례 와 질적으로 다르지 않다고 생각합니다. 차이점은 실제로 이러한 경우에 대한 구현이 현재 불완전하고 UB가 있다는 것입니다. 당신이 의지 할 수없는 세계 as 검사를하고 (대부분의 유형을 위해, 그것은하지 않기 때문에), 당신은 당황하지에 의존 할 수없는 (때문에 어떤 종류의, 그것은 것), 그리고 그것은 일치하지, 그리고 우리는 여전히 나에게 그들 모두의 가장 나쁜 것 같다되지 않았다.

그래서이 시점에서 @jorendorff는 기본적으로 나에게 가장 좋은 계획 인 것처럼 보이는 것을 열거했다고 생각합니다.

• as 에는 결정 론적 동작이 있습니다.
• 얼마나 합리적인지, 얼마나 효율적인지의 조합에 따라 행동을 선택합니다.

그는 세 가지 가능성을 열거했습니다. 남은 작업은 이러한 가능성을 조사하거나 적어도 그중 하나 를 조사하는 것이라고 생각합니다. 즉, 실제로 구현하고 "느림"또는 "빠름"에 대한 느낌을 얻으십시오.

거기에 찌르려는 동기를 느끼는 사람이 있습니까? 누군가를 끌어 들이기 위해 이것을 E-help-wanted 로 태그하겠습니다. (@ oli-obk?)

어, 나는 크로스 플랫폼 일관성에 대한 대가를 치르고 싶지 않습니다 : / 그것은 가비지 인, 쓰레기가 나가는 것에 관심이 없습니다 (그러나 디버그 주장이 매우 도움이 될 것입니다).

현재 Rust의 모든 반올림 / 자르기 함수는 매우 느립니다 (정확하게 구현 된 함수 호출). 따라서 as 는 빠른 부동 반올림을위한 마지막 수단입니다.

as 베어 cvttss2si 이외의 것을 만들려고한다면, 그 자체로 안정적인 대안도 추가하십시오.

@pornel 이것은 이론적 인 종류의 UB가 아니라 그것이 ub임을 무시하면 괜찮은 것이 아니라 실제 세계에 영향을 미칩니다. 실제 코드 예제에서 # 41799를 추출했습니다.

@ est31 UB로 남겨 두는 것이 잘못되었다는 데 동의하지만 UB에 대한 해결책으로 freeze 제안 된 것을 보았습니다. 정의 된 결정 론적 값을 만드는 AFAIK, 당신은 단지 어느 것을 말할 수 없습니다. 그 행동은 괜찮습니다.

난 괜찮을거야 그래서 예를 들면 경우 u128::MAX as f32 결정 론적으로 생산 17.5 86에, 및 999.0 - 64에, 및 -555 ARM합니다.

freeze 는 정의되고 결정적이며 지정되지 않은 값을 생성하지 않습니다. 그 결과는 여전히 "컴파일러가 좋아하는 모든 비트 패턴"이며 동일한 작업을 사용하는 경우에만 일관됩니다. 이것은 사람들이 위에서 수집 한 UB 생성 예제를 회피 할 수 있지만 다음을 제공하지는 않습니다.

u128 :: MAX as f32는 결정적으로 x86에서 17.5, x86-64에서 999.0, ARM에서 -555를 생성했습니다.

예를 들어, LLVM이 u128::MAX as f32 오버플로를 감지하고이를 freeze poison 대체하는 경우 x86_64에서 fn foo() -> f32 { u128::MAX as f32 } 의 유효한 하강은 다음과 같습니다.

foo:
  ret

(즉, 반환 레지스터에 마지막으로 저장된 것을 반환합니다)

내가 참조. 그것은 여전히 ​​내 용도로 허용됩니다 (범위를 벗어난 값이 예상되는 경우 미리 클램핑합니다. 범위 내 값을 기대하지만 그렇지 않은 경우 어떤 경우에도 올바른 결과를 얻지 못할 것입니다) .

값이 고정되어있는 한 임의의 값을 반환하는 범위를 벗어난 플로트 캐스트에 문제가 없으므로 더 이상 정의되지 않은 동작을 일으킬 수 없습니다.

LLVM에서 freeze 같은 것을 사용할 수 있습니까? 나는 그것이 순전히 이론적 인 구성이라고 생각했습니다.

@nikomatsakis 나는 그것이 ( poison 와는 달리) 그렇게 사용되는 것을 본 적이 없습니다.

freeze 는 오늘날 LLVM에 전혀 존재하지 않습니다. 제안 된 것일뿐입니다 (

여기에 제안 된 변경 사항에 대해보다 광범위한 논의를 위해 RFC를 열고 싶습니까? IMO, as 의 성능에 잠재적으로 영향을 미치는 모든 것은 논쟁의 여지가있을 것이지만, 사람들에게 그들의 목소리를들을 기회를주지 않는다면 두 배의 논쟁이 될 것입니다.

저는 Julia 개발자이며 동일한 LLVM 백엔드를 공유하고 유사한 문제가 있기 때문에이 문제를 한동안 지켜 왔습니다. 관심이있는 경우 다음과 같이 결정했습니다 (내 컴퓨터의 단일 기능에 대한 대략적인 타이밍 포함).

• unsafe_trunc(Int64, x) 는 해당 LLVM 내장 fptosi (1.5ns)에 직접 매핑됩니다.
• trunc(Int64, x) 는 범위를 벗어난 값 (3ns)에 대한 예외를 발생시킵니다.
• convert(Int64, x) 는 범위를 벗어 났거나 정수가 아닌 값 (6ns)에 대해 예외를 발생시킵니다.

또한 정의되지 않은 동작을 좀 더 정의 하도록 메일 링리스트 에

@bstrie RFC는 괜찮지 만 데이터가 있으면 확실히 유용하다고 생각합니다! 그러나 @simonbyrne 의 의견은 그 점에서 매우 유용합니다.

나는 JS 의미론 ( @jorendorff 모듈로 언급)과 "포화"열로 보이는 자바 의미론 을 가지고 놀았다. 해당 링크가 만료되는 경우 JS 및 Java 입니다.

나는 또한 (?)가 맞다고 생각하는 Rust에서 포화 의 벤치 마크 수치 도 얻었습니다. 흥미롭게도 포화 구현이 내장 함수보다 2-3 배 느리다는 것을 알고 있습니다. @simonbyrne이 2 배 더 느리게 발견 한 것과

Rust에서 "mod"의미론을 구현하는 방법을 완전히 모르겠습니다 ...

하지만 저에게는 성능이 필요한 사람들을 위해 수많은 f32::as_u32_unchecked() 메서드가 필요하다는 것이 분명해 보입니다.

성능이 필요한 사람들을 위해 많은 f32::as_u32_unchecked() 메서드가 필요하다는 것이 분명해 보입니다.

그것은 안타까운 일입니다. 아니면 안전하지만 구현 정의 된 변형을 의미합니까?

구현 정의 빠른 기본값에 대한 옵션이 없습니까?

@eddyb 나는 우리가 가지고 거라고 생각했다 unsafe fn as_u32_unchecked(self) -> u32 에 f32 무엇에 직접 아날로그 인 및 as 오늘입니다.

필자가 작성한 Rust 구현이 최적이라고 주장하지는 않겠지 만,이 스레드를 읽을 때 대부분의 시간 동안이 스레드 결정론과 안전성이 속도보다 더 중요하다는 인상을 받았습니다. unsafe 탈출 해치는 울타리 반대편에있는 사람들을위한 것입니다.

그렇다면 저렴한 플랫폼 의존적 변형이 없습니까? 나는 빨리 무언가가 지정되지 않은 값을 제공 할 때 경계의 외부 안전합니다. 나는 일부 입력에 UB를 원하지 않으며 우리가 더 잘 할 수 있다면 일반적인 사용에는 너무 위험하다고 생각합니다.

내가 아는 한, 대부분의 플랫폼에서이 변환을 구현하는 표준 방법은 UB가 아닌 범위를 벗어난 입력에 대해 무언가 를 수행합니다. 그러나 LLVM은 UB를 통해 해당 옵션을 선택할 수있는 방법이없는 것 같습니다. LLVM 개발자가 범위를 벗어난 입력에 대해 "지정되지 않았지만 undef / poison "결과가 아닌 내장 함수를 도입하도록 설득 할 수 있다면이를 사용할 수 있습니다.

하지만이 스레드의 누군가가 설득력있는 RFC (llvm-dev 목록에 있음)를 작성하고 동의를 얻어 구현해야 할 것으로 예상합니다 (백엔드에서 우리가 신경 쓰는 백엔드에서 다른 목표). 아마도 llvm-dev가 기존 캐스트를 UB가 아닌 것으로 만들도록 설득하는 것보다 쉬울 것입니다 ( "C 및 C ++ 프로그램을 느리게 만들 것"과 같은 질문을 회피하기 때문입니다). 그러나 여전히 쉽지는 않습니다.

다음 중에서 선택하는 경우를 대비하여 :

채도 (범위를 벗어난 값은 IntType :: max_value () / min_value ()가 됨)
모듈로 (범위를 벗어난 값은 먼저 bigint로 변환 한 다음 잘라내는 것처럼 처리됨)

값이 커짐에 따라 부동 소수점의 절대 정밀도가 빠르게 떨어지기 때문에 IMO 전용 채도는 여기서 의미가 있습니다. 따라서 어느 시점에서 모듈로는 모두 0처럼 쓸모없는 것이 될 것입니다.

I는이 표시 E-needs-mentor 하고 그것을 태그 WG-compiler-middle 가 IMPL 기간이 추가로 조사 할 수있는 좋은 시간이 될 수도 보이기 때문에! 기록 계획에 대한 나의 기존

뿡 빵뀨

IIRC LLVM은 결국 freeze 구현할 계획입니다. 그러면 freeze 를 수행하여 UB를 처리 할 수 ​​있습니다.

내 결과 : https://gist.github.com/s3bk/4bdfbe2acca30fcf587006ebb4811744

_array 변형은 1024 개 값의 루프를 실행합니다.
_ 캐스트 : x as i32
_clip : x.min (MAX) .max (MIN) as i32
_panic : x가 범위를 벗어나면 패닉
_zero : 범위를 벗어난 경우 결과를 0으로 설정합니다.

test bench_array_cast       ... bench:       1,840 ns/iter (+/- 37)
test bench_array_cast_clip  ... bench:       2,657 ns/iter (+/- 13)
test bench_array_cast_panic ... bench:       2,397 ns/iter (+/- 20)
test bench_array_cast_zero  ... bench:       2,671 ns/iter (+/- 19)
test bench_cast             ... bench:           2 ns/iter (+/- 0)
test bench_cast_clip        ... bench:           2 ns/iter (+/- 0)
test bench_cast_panic       ... bench:           2 ns/iter (+/- 0)
test bench_cast_zero        ... bench:           2 ns/iter (+/- 0)

개별 작업에 대해 결과를 정수로 반올림 할 필요가 없습니다. 분명히이 2ns / iter 뒤에는 약간의 차이가있을 것입니다. 아니면 4 개 변형 모두에 대해 _ 정확히 _ 2ns와 같은가요?

@ sp-1234 부분적으로 최적화되었는지 궁금합니다.

@ sp-1234 측정하기 너무 빠릅니다. 비 배열 벤치 마크는 기본적으로 쓸모가 없습니다.
#[inline(never)] 를 통해 단일 값 함수를 함수로 강제하면 2ns 대 3ns가됩니다.

뿡 빵뀨
freeze 관련 예약이 있습니다. 내가 올바르게 이해한다면, 고정 된 undef 는 여전히 임의의 값을 포함 할 수 있으며 사용간에 변경되지 않습니다. 실제로 컴파일러는 아마도 레지스터 나 스택 슬롯을 재사용 할 것입니다.

그러나 이것은 이제 안전한 코드에서 초기화되지 않은 메모리를 읽을 수 있음을 의미합니다. 이로 인해 Heartbleed처럼 비밀 데이터가 유출 될 수 있습니다. Rust의 관점에서 이것이 진정 UB로 간주되는지는 논쟁의 여지가 있지만 분명히 바람직하지 않은 것 같습니다.

@ s3bk 의 벤치 마크를 로컬에서 실행했습니다. 스칼라 버전이 완전히 최적화되었는지 확인할 수 있으며 배열 변형에 대한 asm도 의심스럽게 잘 최적화 된 것처럼 보입니다. 예를 들어 루프가 벡터화되어 있지만 성능을 스칼라 코드로 추정하기가 어렵습니다.

안타깝게도 black_box 스팸은 도움이되지 않는 것 같습니다. asm이 유용한 작업을 수행하는 것을 보았지만 벤치 마크를 실행하면 여전히 스칼라 벤치 마크에 대해 0ns가 제공됩니다 (1ns를 표시하는 cast_zero 제외). @alexcrichton 이 벤치 마크에서 비교를 100 번 수행 한 것을 소스 코드 ).

test bench_cast             ... bench:          53 ns/iter (+/- 0)
test bench_cast_clip        ... bench:         164 ns/iter (+/- 1)
test bench_cast_panic       ... bench:         172 ns/iter (+/- 2)
test bench_cast_zero        ... bench:         100 ns/iter (+/- 0)

어레이 벤치 마크가 너무 많이 달라서 믿을 수 없습니다. 사실, 저는 어쨌든 test 벤치마킹 인프라에 회의적입니다. 특히 이전에 얻은 평탄한 0ns에 비해 위의 수치를 본 후에는 더욱 그렇습니다. 또한 black_box(x); 의 100 회 반복 (기준선으로)에도 34ns가 소요되므로 이러한 숫자를 안정적으로 해석하기가 더욱 어려워집니다.

주목할만한 두 가지 사항 :

• NaN을 구체적으로 처리하지 않음에도 불구하고 (0 대신 -inf를 반환합니까?), cast_clip 구현은 @alexcrichton 의 포화 캐스트보다 느리게 나타납니다 (그들의 실행과 저의 실행 시간은 as 타이밍이 거의 같습니다
• @ s3bk 의 배열 결과와 달리 cast_panic 가 다른 확인 된 캐스트보다 느립니다. 또한 어레이 벤치 마크에서 훨씬 더 느린 속도를 봅니다. 아마도 이러한 것들이 마이크로 아키텍처 세부 사항 및 / 또는 최적화 기 분위기에 크게 의존 할 수 있습니까?

기록을 위해, 나는 가벼운 부하의 i7-6700K에서 rustc 1.21.0-nightly (d692a91fa 2017-08-04), -C opt-level=3 로 측정했습니다.

결론적으로 지금까지는 신뢰할 수있는 데이터가없고 더 신뢰할 수있는 데이터를 얻는 것이 어렵다고 결론지었습니다. 또한 실제 응용 프로그램이이 작업에 벽시계 시간의 1 %도 소비하지 않는다는 것은 의심 스럽습니다. 따라서 저는 rustc 에서 -Z 플래그 뒤에 as 캐스트를 포화 상태 로 -Z 응용 프로그램.

편집 : 가능하다면 다양한 아키텍처 (예 : ARM 포함) 및 마이크로 아키텍처에서 이러한 벤치 마크를 실행하는 것이 좋습니다.

나는 녹에 익숙하지 않다는 것을 인정하지만 이 줄 은 미묘하게 틀렸다고 생각 std::i32::MAX (2 ^ 31-1)은 Float32로 정확하게 표현할 수 없으므로 std::i32::MAX as f32 는 가장 가까운 표현 가능한 값 (2 ^ 31)으로 반올림됩니다. 이 값이 x 인수로 사용되면 결과는 기술적으로 정의되지 않습니다. 엄격한 부등식으로 대체하면이 경우가 해결됩니다.

예, 우리는 이전에 Servo에서 정확히 그 문제가있었습니다. 최종 해결책은 f64로 캐스팅 한 다음 클램프하는 것이 었습니다.

다른 솔루션이 있지만 꽤 까다 롭고 rust는 이것을 잘 처리하기위한 좋은 API를 노출하지 않습니다.

0x7FFF_FF80i32를 상한으로 사용하고 -0x8000_0000i32를 사용하면 f64로 캐스팅하지 않고이 문제를 해결해야합니다.
편집 : 올바른 값을 사용하십시오.

나는 당신이 0x7fff_ff80 을 의미한다고 생각하지만 단순히 엄격한 부등식을 사용하면 아마도 코드의 의도가 더 명확해질 것입니다.

x < 0x8000_0000u32 as f32 ? 그것은 아마도 좋은 생각 일 것입니다.

나는 모든 제안 된 결정 론적 옵션을 생각합니다. 클램핑은 어쨌든 자주 수행한다고 생각하기 때문에 일반적으로 가장 유용합니다. 변환 유형이 실제로 포화 상태로 문서화되면 수동 클램핑이 필요하지 않습니다.

기계 명령으로 제대로 변환되지 않고 분기에 크게 의존하기 때문에 제안 된 구현에 대해 약간 걱정됩니다. 분기는 특정 데이터 패턴에 따라 성능이 달라집니다. 위에 주어진 테스트 사례에서 모든 것이 (비교적으로) 빠르게 보입니다. 왜냐하면 동일한 분기가 항상 취해지고 프로세서가 이전의 여러 루프 반복에서 좋은 분기 예측 데이터를 가지고 있기 때문입니다. 현실 세계는 아마 그렇게 보이지 않을 것입니다. 또한 분기는 코드를 벡터화하는 컴파일러의 기능을 손상시킵니다. 벡터화와 함께 작업을 테스트해서는 안된다는 @rkruppe 의 의견에 동의하지 않습니다. 벡터화는 고성능 코드에서 중요하며 일반적인 아키텍처에서 간단한 캐스트를 벡터화 할 수있는 것은 중요한 요구 사항입니다.

위에 주어진 이유 때문에, 포화 의미론과 @simonbyrne 수정을 사용하는 대체 분기 및 데이터 흐름 지향 버전을 가지고 u16 , i16 및 i32 용으로 구현했습니다. 모두 약간 다른 경우를 다루어야하므로 성능이 달라집니다.

결과 :

test i16_bench_array_cast       ... bench:          99 ns/iter (+/- 2)
test i16_bench_array_cast_clip  ... bench:         197 ns/iter (+/- 3)
test i16_bench_array_cast_clip2 ... bench:         113 ns/iter (+/- 3)
test i16_bench_cast             ... bench:          76 ns/iter (+/- 1)
test i16_bench_cast_clip        ... bench:         218 ns/iter (+/- 25)
test i16_bench_cast_clip2       ... bench:         148 ns/iter (+/- 4)
test i16_bench_rng_cast         ... bench:       1,181 ns/iter (+/- 17)
test i16_bench_rng_cast_clip    ... bench:       1,952 ns/iter (+/- 27)
test i16_bench_rng_cast_clip2   ... bench:       1,287 ns/iter (+/- 19)

test i32_bench_array_cast       ... bench:         114 ns/iter (+/- 1)
test i32_bench_array_cast_clip  ... bench:         200 ns/iter (+/- 3)
test i32_bench_array_cast_clip2 ... bench:         128 ns/iter (+/- 3)
test i32_bench_cast             ... bench:          74 ns/iter (+/- 1)
test i32_bench_cast_clip        ... bench:         168 ns/iter (+/- 3)
test i32_bench_cast_clip2       ... bench:         189 ns/iter (+/- 3)
test i32_bench_rng_cast         ... bench:       1,184 ns/iter (+/- 13)
test i32_bench_rng_cast_clip    ... bench:       2,398 ns/iter (+/- 41)
test i32_bench_rng_cast_clip2   ... bench:       1,349 ns/iter (+/- 19)

test u16_bench_array_cast       ... bench:          99 ns/iter (+/- 1)
test u16_bench_array_cast_clip  ... bench:         136 ns/iter (+/- 3)
test u16_bench_array_cast_clip2 ... bench:         105 ns/iter (+/- 3)
test u16_bench_cast             ... bench:          76 ns/iter (+/- 2)
test u16_bench_cast_clip        ... bench:         184 ns/iter (+/- 7)
test u16_bench_cast_clip2       ... bench:         110 ns/iter (+/- 0)
test u16_bench_rng_cast         ... bench:       1,178 ns/iter (+/- 22)
test u16_bench_rng_cast_clip    ... bench:       1,336 ns/iter (+/- 26)
test u16_bench_rng_cast_clip2   ... bench:       1,207 ns/iter (+/- 21)

테스트는 Intel Haswell i5-4570 CPU 및 Rust 1.22.0에서 야간에 실행되었습니다.
clip2 은 새로운 분기없는 구현입니다. 가능한 모든 2 ^ 32 f32 입력 값에 대해 clip 와 일치합니다.

rng 벤치 마크의 경우 다른 경우에 자주 발생하는 임의 입력 값이 사용됩니다. 이를 통해 분기 예측이 실패 할 경우 발생하는 _extreme_ 성능 비용 (정상 비용의 약 10 배 !!!)을 확인할 수 있습니다. 이것을 고려하는 것이 _ 매우 _ 중요하다고 생각합니다. 평균적인 실제 성능도 아니지만 여전히 가능한 경우이며 일부 응용 프로그램은이 문제를 해결합니다. 사람들은 f32 캐스트가 일관된 성능을 기대합니다.

x86에서의 어셈블리 비교 : https://godbolt.org/g/AhdF71
분기없는 버전은 minss / maxss 명령에 매우 잘 매핑됩니다.

불행히도 저는 Rust에서 godbolt가 ARM 어셈블리를 생성하도록 만들 수 없었지만 다음은 Clang과 메소드의 ARM 비교입니다. https://godbolt.org/g/s7ronw
코드를 테스트 할 수없고 ARM을 많이 알지 못하는 경우 : 코드 크기도 작아 보이며 LLVM은 대부분 유망 해 보이는 vmax / vmin을 생성합니다. 아마도 LLVM이 결국 대부분의 코드를 단일 명령어로 접도록 가르 칠 수 있을까요?

@ActuallyaDeviloper asm 및 벤치 마크 결과가 매우 좋아 보입니다! 또한, 귀하와 같은 분기없는 코드는 다른 솔루션의 중첩 조건부보다 rustc 에서 생성하기가 더 쉬울 것입니다 (레코드를 위해 lang 항목 함수를 호출하는 대신 인라인 IR을 생성한다고 가정합니다). 이 글을 써 주셔서 감사합니다.

u16_cast_clip2 에 대한 질문이 있습니다 : NaN을 처리하지 않는 것 같습니다?! NaN에 대한 의견이 있지만 함수가 NaN을 수정되지 않은 상태로 전달하고 f32 로 캐스트하려고 시도 할 것이라고 생각합니다 (그렇지 않더라도 0이 아닌 경계 값 중 하나를 생성합니다. ).

추신 : 명확하게 말하자면, 캐스트가 벡터화 될 수 있는지 여부가 중요하지 않다고 암시하려는 것이 아닙니다. 주변 코드가 벡터화 가능한지 여부는 분명히 중요합니다. 그러나 벡터화가 적용되지 않는 경우가 많고 제가 언급 한 벤치 마크에서 스칼라 성능에 대한 설명을하지 않았기 때문에 스칼라 성능 도 중요합니다. 흥미롭게도 *array* 벤치 마크의 asm을 확인하여 구현에 여전히 벡터화되어 있는지 확인 했습니까?

@rkruppe 맞습니다. 실수로 if 의 측면을 바꿔서 잊어 버렸습니다. f32 as u16 위쪽 0x8000을 잘라서 올바른 작업을 수행했기 때문에 테스트에서도이를 포착하지 못했습니다. 이번에는 분기를 다시 교체하고 모든 메서드를 if (y.is_nan()) { panic!("NaN"); } 테스트하여 문제를 해결했습니다.

이전 게시물을 업데이트했습니다. x86 코드는 전혀 변경되지 않았지만 불행히도 변경으로 인해 LLVM이 어떤 이유로 u16 ARM 케이스에서 vmax 를 생성하지 못합니다. 저는 이것이 해당 ARM 명령어의 NaN 처리에 대한 세부 정보와 관련이 있거나 LLVM 제한 일 수 있다고 가정합니다.

작동하는 이유를 위해 부호없는 값의 경우 하한값이 실제로 0이라는 점에 유의하십시오. 따라서 NaN과 하한을 동시에 잡을 수 있습니다.

배열 버전은 벡터화됩니다.
Godbolt : https://godbolt.org/g/HnmsSV

Re : the ARM asm , vmax 이 더 이상 사용되지 않는 이유 는 피연산자가 NaN이면 NaN을 반환하기 때문 이라고 vmovgt , 이전 vcmp 를 0으로 참조)을 사용합니다.

작동하는 이유를 위해 부호없는 값의 경우 하한값이 실제로 0이라는 점에 유의하십시오. 따라서 NaN과 하한을 동시에 잡을 수 있습니다.

오, 맞아. 좋은.

-Z 플래그 뒤에 rustc에서 캐스트로 포화를 구현하여 앞으로 나아갈 것을 제안합니다.

나는 이것을 구현했으며 # 41799를 수정하고 더 많은 테스트를 받으면 PR을 제출할 것입니다.

45134는 내가 놓친 코드 경로를 지적했습니다 (LLVM 상수 표현식의 생성 – 이것은 rustc의 자체 상수 평가와는 별개입니다). 이에 대한 수정 사항을 동일한 PR에 적용 할 것이지만 시간이 조금 더 걸립니다.

@rkruppe miri가 동일한 변경 사항을 적용하도록 @ oli-obk와 협력해야합니다.

풀 리퀘스트 : # 45205

45205가 병합되었으므로 이제 누구나 -Z saturating-float-casts 를 통해 RUSTFLAGS -Z saturating-float-casts 를 전달 하여 채도의 성능 영향을 측정 할 수 있습니다 (다음 밤부터 시작). [1] 이러한 측정은이 문제를 처리하는 방법을 결정하는 데 매우 유용합니다.

[1] 엄밀히 말해서 이것은 표준 라이브러리의 일반 라이브러리가 아닌 #[inline] 부분에 영향을주지 않으므로 100 % 정확하려면 Xargo로 로컬에서 표준을 빌드하는 것이 좋습니다. 그러나 이로 인해 영향을받는 코드가 많을 것이라고는 생각하지 않습니다 (예를 들어 다양한 변환 특성 impls는 #[inline] 입니다).

@rkruppe https://internals.rust-lang.org/t/help-us-benchmark-incremental-compilation/6153/ 과 같은 맥락에서 내부 / 사용자 페이지를 시작하여 데이터를 수집 할 것을 제안합니다. 이슈 트래커에서 임의의 댓글이 아닌 사람들을 여기에 연결)

@rkruppe 추적 문제를 만들어야합니다. 이 토론은 이미 두 가지 문제로 나뉩니다. 그 좋지 않다!

@Gankro 네, 동의 합니다만, 글을 올바로 쓸 시간을 찾기까지 며칠이

@ est31 흠. -Z 플래그가 두 캐스트 방향을 모두 다루지 만 (돌이켜 보면 실수 였을 수 있음) 동시에 두 스위치를 켤 것 같지 않은 것 같습니다. (예를 들어,이 문제는 채도의 성능에 달려 있으며 # 41799에서는 올바른 솔루션이 무엇인지에 대해 동의했습니다).
이 벤치 마크는 주로 또한 # 41799에 대한 수정의 영향을 측정하는 것이이 문제를 대상으로하는 조금 바보입니다,하지만 난 종류의 그것과 괜찮아 해요, 그래서 성능 회귀의 overreporting 가장 선두에서 그 캔. (그러나 누군가가 -Z 플래그를 둘로 분할하려는 동기가 있다면 계속 진행하십시오.)

플래그가 유용성보다 오래 지속되면 플래그를 제거하는 작업에 대한 추적 문제를 고려했지만 여기와 # 41799에서 발생하는 토론을 병합 할 필요가 없다고 생각합니다.

내부 게시물을 작성했습니다 : https://gist.github.com/Gankro/feab9fb0c42881984caf93c7ad494ebd

자유롭게 복사하거나 메모를 남겨서 게시 할 수 있습니다. ( const fn 동작에 대해 약간 혼란 스럽습니다)

한 가지 추가 정보는 float-> int 변환의 비용이 기본이 아니라 현재 구현에 따라 다르다는 것입니다. x86에서 cvtss2si cvttss2si 는 너무 낮음, 너무 높음 및 nan 경우 0x80000000을 반환하므로 cvtss2si cvttss2si -Zsaturating-float-casts 를 구현할 수 있습니다. cvttss2si 뒤에 0x80000000 케이스의 특수 코드가 나오므로 일반적인 경우 단일 비교 및 ​​예측 분기 일 수 있습니다. ARM에서 vcvt.s32.f32 에는 이미 -Zsaturating-float-casts 의미가 있습니다. LLVM은 현재 두 경우 모두 추가 검사를 최적화하지 않습니다.

@Gankro

정말 감사합니다! 요점에 대해 몇 가지 메모를 남겼습니다. 이것을 읽은 후, 나는 -Z 플래그에서 u128-> f32 캐스트를 분리하는 데 찔러보고 싶습니다. 두 개의 직교 기능을 덮는 깃발에 대한주의 산만 함을 없애기 위해서입니다.

(float-> int 문제 만 다루도록 -Z 플래그를 다시 초점을 맞추기 위해 # 45900을 제출했습니다.)

대량 벤치마킹을 요청하기 전에 @sunfishcode (적어도 x86의 경우)로 플랫폼 별 구현을 얻을 수 있다면 좋을 것입니다. 그리 어렵지 않을 것입니다.

문제는 내가 아는 한 LLVM이이 작업을 수행하는 방법을 제공하지 않는다는 것입니다.

토론을 반영하기 위해 초안을 업데이트했습니다 (기본적으로 u128-> f32에 대한 인라인 언급을 끝에 추가 섹션으로 추출).

@sunfishcode 확실합니까? 당신이 찾고있는 것이 llvm.x86.sse.cvttss2si 본질적이지 않습니까?

다음은이를 사용하는 플레이 그라운드 링크입니다.

https://play.rust-lang.org/?gist=33cf9e0871df2eb2475b845af4f1b574&version=nightly

릴리스 모드에서 float_to_int_with_intrinsic 및 float_to_int_with_as 모두 단일 명령어로 컴파일됩니다. (디버그 모드에서 float_to_int_with_intrinsic 는 몇 가지 명령을 낭비하여 0을 높음에 두지 만 나쁘지는 않습니다.)

일정한 폴딩을 올바르게 수행하는 것 같습니다. 예를 들면

float_to_int_with_intrinsic(42.0)

된다

movl    $42, %eax

하지만 범위를 벗어난 값은

float_to_int_with_intrinsic(42.0e33)

접히지 않습니다.

cvttss2si   .LCPI2_0(%rip), %eax

(이상적으로는 상수 0x80000000으로 접힐 것이지만 큰 문제는 아닙니다. 중요한 것은 undef를 생성하지 않는다는 것입니다.)

오, 멋지다. 작동 할 것 같습니다!

결국 우리가 cvttss2si 를) 구축 할 수있는 방법이 있다는 것을 아는 것은 멋진 일입니다. 그러나 벤치 마크를 요청하기 전에이를 사용하도록 구현을 변경하는 것이 분명히 더 낫다는 데 동의하지 않습니다.

대부분의 사람들은 x86에서 벤치마킹 할 것이므로 x86을 특수한 경우 일반 구현에 대한 데이터를 훨씬 적게 얻을 수 있으며 대부분의 다른 대상에서 여전히 사용됩니다. 물론 다른 아키텍처에 대해 추론하기는 이미 어렵지만 완전히 다른 구현으로 인해 완전히 불가능합니다.

둘째, "간단한"솔루션을 사용하여 지금 벤치 마크를 수집하고 실제 코드에 성능 회귀가 없음을 발견하면 (그리고 내가 예상하는 tbh), 시도하는 문제를 겪을 필요조차 없습니다. 이 코드 경로를 더욱 최적화하십시오.

마지막으로, cvttss2si 빌드하는 것이 지금 우리가 가지고있는 것보다 더 빠를 지조차 확신하지 못합니다 (ARM에서는 적절한 명령어를 사용하는 것이 분명히 더 낫습니다).

• 변환이 0x80000000을 반환하는지 확인하려면 비교가 필요하며,이 경우 int :: MIN 또는 int :: MAX를 반환해야하는지 여부를 알기 위해 입력 값의 다른 비교가 여전히 필요합니다. 그리고 그것이 부호있는 정수 유형이라면 NaN을 구별하기 위해 세 번째 비교를 피하는 방법을 알지 못합니다. 따라서 최악의 경우 :
  
  
  
  • 당신은 비교 / 선택의 수를 저장하지 않습니다
  
  
  • int 비교를 위해 float 비교를 거래하고 있는데, 이는 OoO 코어에 좋을 수 있습니다 (비교할
  
  
• 벡터화는 아마도 더 어렵거나 불가능해질 것입니다. 루프 벡터 라이저가이 내장 함수를 전혀 처리 할 것이라고는 생각하지 않습니다.
• (AFAIK)이 전략은 일부 정수 유형에만 적용된다는 점도 주목할 가치가 있습니다. 예를 들어 f32-> u8은 결과에 대한 추가 수정이 필요하므로이 전략은 분명히 수익성이 떨어집니다. 어떤 유형이이 영향을 받는지 잘 모르겠지만 (예 : f32-> u32에 대한 지침이 있는지 모르겠습니다), 이러한 유형 만 사용하는 응용 프로그램은 전혀 도움이되지 않습니다.
• 행복한 경로에서 하나의 비교만으로 분기 솔루션을 수행 할 수 있습니다 (이전 솔루션에서와 같이 2 ~ 3 개의 비교 및 ​​분기와 반대). 그러나 @ActuallyaDeviloper가 앞서 주장했듯이 분기는 바람직하지 않을 수 있습니다. 이제 성능은 훨씬 더 워크로드와 분기 예측에 따라 달라집니다.

벤치마킹 결과에 관계없이 많은 unsafe fn as_u32_unchecked(self) -> u32 와 친구들이 필요할 것이라고 가정하는 것이 안전합니까? 그들이 둔화를 관찰 결국 않은 경우 누군가가 어떤 다른 잠재적 의지 할 것이다?

@bstrie 그런 경우에는 구문을 as <type> [unchecked] 로 확장하고 unchecked 가 unsafe 에만 존재하도록 요구하는 것과 같은 작업을 수행하는 것이 더 합리적이라고 생각합니다 as <type> [unchecked] 컨텍스트.

내가보기에 _unchecked 의 포레스트가 as 캐스팅의 변형으로 작동하는 것은 직관적이고 사용 가능한 문서를 생성 할 때 사마귀 일 것입니다.

@ssokolow 구문 추가는 항상 최후의 수단이되어야합니다. 특히이 모든 것이 단 10 개의 순환 함수로 처리 될 수 있다면 더욱 그렇습니다. 심지어 갖는 일반적인 foo.as_unchecked::<u32>() 특히 우리가하지, 감소 증가되어야한다 이후 구문 변경 (그리고 수반 끝없는 bikeshed)하는 것이 바람직 할 것이다, 그 사물의 수 unsafe 잠금을 해제합니다.

포인트. 터보 피쉬는 옵션을 고려할 때 마음을 잃었고, 돌이켜 보면 오늘 저녁에도 모든 실린더를 정확히 발사하지 않았기 때문에 설계 결정에 대해 더 신중하게 언급해야했습니다.

즉, 대상 유형을 함수 이름으로 굽는 것은 잘못된 느낌입니다. 터보 피쉬가 더 나은 선택 지인 것 같습니다.

일반 메서드는 From / Into 및 unsafe fn 메서드를 포함하는 UncheckedFrom / UncheckedInto 트레이 트의 새로운 세트에 의해 지원 될 수 있습니다 unsafe fn TryFrom / TryInto 컬렉션.

@bstrie 코드가 느려진 사람들을위한 대안 중 하나는 기본 하드웨어 명령어에 액세스하기 위해 내장 함수 (예 : stdsimd를 통해)를 사용하는 것입니다. 나는 이것이 옵티 마이저에 대한 단점을 가지고 있다고 주장했다 – 자동 벡터화는 어려움을 겪을 가능성이 있으며 LLVM은 범위를 벗어난 입력에서 undef 를 반환하는 것을 악용 할 수 없지만 –없이 캐스트를 수행하는 방법을 제공합니다. 런타임에 추가 작업. 이것이 충분히 좋은지 결정할 수는 없지만 적어도 그럴 수도 있습니다.

x86 명령어 세트의 변환에 대한 몇 가지 참고 사항 :

SSE2는 실제로 제공하는 변환 작업이 상대적으로 제한적입니다. 당신은 :

• 32 비트 레지스터가있는 CVTTSS2SI 제품군 : 단일 부동 소수점을 i32
• 64 비트 레지스터가있는 CVTTSS2SI 제품군 : 단일 부동 소수점을 i64 로 변환 (x86-64 만 해당)
• CVTTPS2PI 제품군 : 두 개의 부동 소수점을 두 개의 i32s

이들 각각에는 f32 및 f64 변형이 있습니다 (절단하는 대신 반올림하는 변형도 있지만 여기서는 쓸모가 없습니다).

그러나 부호없는 정수에는 아무것도없고, 32보다 작은 크기에는 아무것도 없으며, 32 비트 x86을 사용하는 경우 64 비트에는 아무것도 없습니다. 이후의 명령어 세트 확장은 더 많은 기능을 추가하지만,이를 위해 컴파일하는 사람은 거의없는 것 같습니다.

결과적으로 기존 ( '안전하지 않은') 동작 :

• u32로 변환하기 위해 컴파일러는 i64로 변환하고 결과 정수를 자릅니다. (이것은 범위를 벗어난 값에 대해 이상한 동작을 생성하지만 UB이므로 누가 신경 써야합니다.)
• 16 비트 또는 8 비트로 변환하기 위해 컴파일러는 i64 또는 i32로 변환하고 결과 정수를 자릅니다.
• u64로 변환하기 위해 컴파일러는 명령의 모 라스를 생성합니다. f32에서 u64까지의 경우 GCC 및 LLVM은 다음을 생성합니다.

fn f32_to_u64(f: f32) -> u64 {
    const CUTOFF: f32 = 0x8000000000000000 as f32; // 2^63 exactly
    if !(f >= CUTOFF) { // less, or NaN
        // just use the signed conversion
        f as i64 as u64
    } else {
        0x8000000000000000u64 + ((f - CUTOFF) as i64 as u64)
    }
}

관련없는 재미있는 사실 : "잘라 내기보다 변환"코드 생성은 Super Mario 64에서 " 병렬 우주 "결함을 일으키는 원인입니다. 충돌 감지 코드는 먼저 MIPS 명령으로 f32 좌표를 i32로 변환 한 다음 i16으로 자릅니다. 따라서 i16에는 맞지만 i32 'wrap'에는 맞지 않는 좌표, 예를 들어 65536.0 좌표로 이동하면 0.0에 대한 충돌 감지를 얻을 수 있습니다.

어쨌든 결론 :

• "0x80000000 테스트 및 특수 처리기 있음"은 i32 및 i64 로의 변환에만 작동합니다.
• 그러나 u32, u / i16 및 u / i8 로의 변환의 경우 "잘린 / 부호 확장 출력이 원본과 다른지 테스트"는 동일합니다. (이는 원래 변환의 범위에 있지만 최종 유형의 범위를 벗어난 정수와 float가 NaN이거나 원래 변환의 범위를 벗어난 표시기 인 0x8000000000000000을 모두 가져옵니다.)
• 그러나 그 경우에 분기와 추가 코드의 비용은 아마도 과잉 일 것입니다. 가지를 피할 수 있으면 괜찮을 수 있습니다.

• @ActuallyaDeviloper 의 minss / maxss 기반 접근 방식은 그렇게 나쁘지 않습니다! 최소한의 형태,

minss %xmm2, %xmm1
maxss %xmm3, %xmm1
cvttss2si %rax, %xmm1

3 개의 명령어 (적당한 코드 크기와 처리량 / 대기 시간이 있음)이며 분기가 없습니다.

하나:

• 순수한 녹 버전은 NaN에 대한 추가 테스트가 필요합니다. 32 비트 이하로의 변환의 경우 64 비트 cvttss2si를 사용하고 결과를 자르면 내장 함수를 사용하여 피할 수 있습니다. 입력이 NaN이 아닌 경우 최소 / 최대는 정수가 잘림으로 변경되지 않도록합니다. 입력이 NaN이면 정수는 0x8000000000000000이며 0으로 자릅니다.
• 2147483647.0 및 -2148473648.0을 레지스터에로드하는 비용은 포함하지 않았습니다. 일반적으로 메모리에서 각각 한 mov입니다.
• f32의 경우 2147483647.0을 정확하게 표현할 수 없으므로 실제로 작동하지 않습니다. 다른 확인이 필요합니다. 그것은 상황을 훨씬 더 악화시킵니다. f64에서 u / i64 로의 경우에도 동일하지만 f64에서 u / i32에는이 문제가 없습니다.

두 가지 접근 방식 사이의 타협을 제안합니다.

• f32 / f64에서 u / i16 및 u / i8로, f64에서 u / i32로, 위와 같이 최소 / 최대 + 잘림으로 이동합니다. 예 :

    let f = if f > 32767.0 { 32767.0 } else { f };
    let f = if f < -32768.0 { -32768.0 } else { f };
    cvttss2si(f) as i16

(u / i16 및 u / i8의 경우 원래 변환은 i32로, f64에서 u / i32 로의 경우 i64로 변환해야합니다.)

• f32 / 64 ~ u32의 경우

    let r = cvttss2si64(f) as u32;
    if f >= 4294967296.0 { 4294967295 } else { r }

몇 가지 지침에 불과하고 분기가 없습니다.

    cvttss2si   %xmm0, %rcx
    ucomiss .LCPI0_0(%rip), %xmm0
    movl    $-1, %eax
    cmovbl  %ecx, %eax

• f32 / 64 ~ i64의 경우

    let r = cvttss2si64(f);
    if f >= 9223372036854775808. {
        9223372036854775807 
    } else if f != f {
        0
    } else {
        r
    }

이렇게하면 더 긴 (여전히 분기가없는) 시퀀스가 ​​생성됩니다.

    cvttss2si   %xmm0, %rax
    xorl    %ecx, %ecx
    ucomiss %xmm0, %xmm0
    cmovnpq %rax, %rcx
    ucomiss .LCPI0_0(%rip), %xmm0
    movabsq $9223372036854775807, %rax
    cmovbq  %rcx, %rax

…하지만 최소한 f 가 너무 작 으면 0x8000000000000000이 이미 정답 인 것처럼 순진한 접근 방식과 비교하여 하나의 비교를 저장합니다 (예 : i64 :: MIN).

• f32에서 i32까지의 경우 이전과 동일한 작업을 수행하는 것이 바람직한 지 또는 먼저 f64로 변환 한 다음 더 짧은 최소 / 최대 작업을 수행하는 것이 더 나은지 확실하지 않습니다.

• u64 은 (는) 생각하고 싶지 않은 엉망입니다. :피

벤치 마크 요청 : https://internals.rust-lang.org/t/help-us-benchmark-saturating-float-casts/6231

https://internals.rust-lang.org/t/help-us-benchmark-saturating-float-casts/6231/14에서 누군가 이미지 상자를 사용한 JPEG 인코딩에서 측정 가능하고 상당한 속도 저하를보고했습니다. 프로그램을 최소화하여 자체 포함되고 대부분 감속과 관련된 부분에 초점을 맞추 었습니다 : https://gist.github.com/rkruppe/4e7972a209f74654ebd872eb4bc57722 캐스트).

캐스트는 동일한 비율의 f32-> u8 ( rgb_to_ycbcr ) 및 f32-> i32 ( encode_rgb , "양자화"루프)입니다. 또한 입력이 모두 범위 내에있는 것처럼 보입니다. 즉, 포화가 실제로 시작되지는 않지만 f32-> u8의 경우 다항식의 최소 및 최대를 계산하고 반올림 오류를 설명하여 확인할 수 있습니다. 물어볼 것이 많습니다. f32-> i32 캐스트는 i32의 범위에 더 분명하지만 self.tables 의 요소가 0이 아니기 때문에 최적화 프로그램이 특히 원래 프로그램에서 표시하기가 쉽지 않습니다. tl; dr : 채도 검사가 남아 있습니다. 유일한 희망은 더 빨리 만드는 것입니다.

나는 또한 LLVM IR을 약간 찔렀다. 말 그대로 유일한 차이점은 포화 캐스트에서 비교와 선택입니다. 빠르게 살펴보면 asm에 해당 지침이 있고 물론 더 많은 실시간 값이 있음을 나타냅니다 (더 많은 유출로 이어짐).

@comex CVTTSS2SI를 사용 하면 f32-> u8 및 f32-> i32 캐스트가 눈에 띄게 빨라질 수 있다고 생각하십니까?

부 업데이트, rustc 1.28.0-nightly (952f344cd 2018-05-18) 현재 -Zsaturating-float-casts 플래그는 여전히 https://github.com/rust-lang/rust/issues/10184#issuecomment -345479698의 코드를 ~ 20으로 만듭니다. x86_64에서 % 느립니다. 이는 LLVM 6이 아무것도 변경하지 않았 음을 의미합니다.

| 플래그 | 타이밍 |
| ------- | ------- : |
| -Copt-level = 3 -Ctarget-cpu = native | 325,699ns / iter (+/- 7,607) |
| -Copt-level = 3 -Ctarget-cpu = native -Zsaturating-float-casts | 386,962ns / iter (+/- 11,601)
(19 % 느림) |
| -Copt-level = 3 | 331,521ns / iter (+/- 14,096) |
| -Copt-level = 3 -Zsaturating-float-casts | 413,572ns / iter (+/- 19,183)
(25 % 느림) |

@kennytm LLVM 6이 무언가를 바꿀 것으로 예상 했습니까? 이 사용 사례에 도움이 될 특정 개선 사항에 대해 논의하고 있습니까? 그렇다면 티켓 번호는 무엇입니까?

@insanitybit ... 아직 열려있는 것 같습니다 ...?

웰프, 내가 뭘 봤는지 전혀 몰라 감사!

@rkruppe 는 float to int 캐스트가 더 이상 LLVM에서 UB가 아닌지 확인하지 않았습니다.
(문서 변경)?

2018 년 7 월 20 일 오전 4:31에 "Colin" [email protected]이 작성했습니다.

웰프, 내가 뭘 봤는지 전혀 몰라

—
이 스레드를 구독했기 때문에이 메시지가 전송되었습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/10184#issuecomment-406462053 ,
또는 음소거
실
https://github.com/notifications/unsubscribe-auth/AApc0v3rJHhZMD7Kv7RC8xkGOiIhkGB1ks5uITMHgaJpZM4BJ45C
.

@nagisa 아마도 f32::from_bits(v: u32) -> f32 (및 유사하게 f64 )를 생각하고 계십니까? NaN의 정규화를 수행하는 데 사용되었지만 지금은 transmute 입니다.

이 문제는 약 as 전환으로 수치를 근사화하려고합니다.

@nagisa 당신은 https://github.com/rust-lang-nursery/nomicon/pull/65를 참조하십시오.

아, 그렇습니다.

2018 년 7 월 20 일 금요일 12:24 Robin Kruppe [email protected] 은 다음과 같이 썼습니다.

@nagisa https://github.com/nagisa 당신은 float- > float를 생각하고 있을지도 모릅니다.
캐스트, # 15536 https://github.com/rust-lang/rust/issues/15536 ​​참조 및
rust-lang-nursery / nomicon # 65
https://github.com/rust-lang-nursery/nomicon/pull/65

—
당신이 언급 되었기 때문에 이것을 받고 있습니다.
이 이메일에 직접 답장하고 GitHub에서 확인하세요.
https://github.com/rust-lang/rust/issues/10184#issuecomment-406542903 ,
또는 스레드 음소거
https://github.com/notifications/unsubscribe-auth/AApc0gA24Hz8ndnYhRXCyacd3HdUSZjYks5uIaHegaJpZM4BJ45C
.

LLVM 7 릴리스 노트에는 다음과 같은 내용이 언급되어 있습니다.

부동 소수점 형변환의 최적화가 향상되었습니다. 이로 인해 캐스트 오버플로의 정의되지 않은 동작에 의존하는 코드에 대해 놀라운 결과가 발생할 수 있습니다. 함수 속성 "strict-float-cast-overflow"= "false"를 지정하여 최적화를 비활성화 할 수 있습니다. 이 속성은 clang 옵션 -fno-strict-float-cast-overflow로 만들 수 있습니다. 코드 새니 타이 저를 사용하여 영향을받는 패턴을 감지 할 수 있습니다. 이 문제 만 감지하는 clang 옵션은 -fsanitize = float-cast-overflow입니다.

이 문제와 관련이 있습니까?

안전하지 않은 정의되지 않은 동작이 아니라면 LLVM이 오버플로 캐스트에 대해 무엇을하는지 신경 쓰지 않아야합니다. 결과는 불건전 한 동작을 유발하지 않는 한 쓰레기가 될 수 있습니다.

이 문제와 관련이 있습니까?

별로. UB는 변경되지 않았고, LLVM은이를 악용하는 데 훨씬 더 공격적이어서 실제로는 영향을 받기 쉽게 만들었지 만 건전성 문제는 변하지 않았습니다. 특히 새 속성은 UB를 제거하지 않거나 LLVM 7 이전에 존재했던 최적화에 영향을주지 않습니다.

@rkruppe 호기심에서, 이런 종류의 길가에 떨어 졌습니까? https://internals.rust-lang.org/t/help-us-benchmark-saturating-float-casts/6231/14 가 충분히 잘 진행되었고 구현에 버그가 너무 많지 않은 것 같습니다. 약간의 성능 회귀가 항상 예상되는 것처럼 보이지만 올바르게 컴파일하는 것은 가치있는 트레이드 오프처럼 보입니다.

이것은 결승선을 통과하기를 기다리고 있습니까? 아니면 다른 알려진 차단제가 있습니까?

대부분 나는 다른 일로 산만하거나 바쁘지만, RBG JPEG 인코딩의 x0.82 회귀는 "약간", 삼키기에는 다소 쓰라린 약처럼 보입니다 (다른 종류의 워크로드가 영향을받지 않는 것 같지만 안심입니다) . 기본적으로 채도를 켜는 것에 반대 할만큼 심각하지는 않지만, "포화보다 빠르지 만 (안전한) 쓰레기를 생성 할 수있는 변환 기능도 제공합니다."를 시도하기 전에 직접 밀어 붙이는 것이 주저 할만큼 충분히 심각하지 않습니다. "이전에 논의한 옵션입니다. 나는 그것을 얻지 못했고, 분명히 다른 누구도 가지고 있지 않으므로 이것은 길가에 떨어졌습니다.

@rkruppe 업데이트에 감사드립니다! 실제로 안전한 쓰레기 옵션의 구현이 있는지 궁금합니다. unsafe fn i32::unchecked_from_f32(...) 같은 것을 쉽게 제공 할 수 있다고 상상할 수 있지만, 이것이 안전한 기능이어야한다고 생각하시는 것 같습니다. 오늘날 LLVM으로 가능합니까?

아직 freeze 는 없지만 인라인 어셈블리를 사용하여 부동 소수점을 정수로 변환하는 대상 아키텍처의 명령에 액세스 할 수 있습니다 (예 : 포화 as 로 대체). 이로 인해 일부 최적화가 억제 될 수 있지만 일부 벤치 마크에서 대부분 회귀를 수정하는 것으로 충분할 수 있습니다.

이 문제에 관한 UB를 유지하는 unsafe 함수 (현재 as 와 같은 방식으로 코드 생성됨)는 또 다른 옵션이지만 훨씬 덜 매력적입니다. d 작업을 수행 할 수 있다면 안전한 기능을 선호합니다.

또한 안전한 포화 float-to-int 시퀀스 개선을 위한 상당한 여지가 있습니다. 오늘날 LLVM에는 특별히 이에 대한 것이 없지만 인라인 asm 솔루션이 테이블에 있다면 다음과 같은 작업을 수행하는 것이 어렵지 않습니다.

     cvttsd2si %xmm0, %eax   # x86's cvttsd2si returns 0x80000000 on overflow and invalid cases
     cmp $1, %eax            # a compact way to test whether %eax is equal to 0x80000000
     jno ok
     ...  # slow path: check for and handle overflow and invalid cases
ok:

이것은 rustc가 현재 하는 것보다 훨씬 빨라야합니다.

네, 분명히 말씀 드리고 싶었습니다. 감사합니다! 인라인 asm 솔루션은 다른 최적화를 너무 많이 방해하기 때문에 기본값으로 작동하지 않는다고 생각했지만 직접 시도하지는 않았습니다. 나는 개인적으로 우리가 몇 가지 합리적인 행동을 정의함으로써이 불건전 한 구멍을 막는 것을 선호합니다 (정확히 오늘의 캐스트와 같은). 필요한 경우 오늘날의 빠르고 건전하지 않은 구현을 안전하지 않은 함수로 항상 보존 할 수 있으며 무한 리소스가 주어진 시간 제한에서 기본값을 대폭 개선하거나 다른 특수 변환 함수를 추가 할 수도 있습니다 (예 : 경계를 벗어난 변환 UB가 아니라 쓰레기 비트 패턴)

다른 사람들이 그러한 전략에 반대할까요? 그동안이 문제를 해결할만큼 중요하지 않다고 생각합니까?

인라인 어셈블리는 특히 인라인 어셈블리가 메모리에 액세스하지 않거나 부작용이 없기 때문에 cvttsd2si (또는 유사한 명령)에 대해 허용되어야한다고 생각합니다. 따라서 사용하지 않는 경우 제거 할 수있는 불투명 한 블랙 박스 일뿐입니다. 주위 금지 최적화 매우, LLVM은 내부와 인라인 어셈블리의 결과 값에 대한없는 이유가 있습니다. 마지막 비트는 @sunfishcode 가 채도를 제안하는 코드 시퀀스에 대해 인라인 asm을 사용하는 것에 대해 회의적인 이유입니다. 채도에 대해 도입 된 검사는 중복되는 경우 오늘날 제거 될 수 있지만 인라인 asm 블록의 분기는 t 단순화.

다른 사람들이 그러한 전략에 반대할까요? 그동안이 문제를 해결할만큼 중요하지 않다고 생각합니까?

나는 지금 포화 상태를 바꾸고 나중에 대안을 추가하는 것을 반대하지 않습니다. 나는 합의를 이끌어 내고 코드가 느려진 사용자에게 정당화해야하는 사람이되고 싶지 않습니다 😅

LLVM에서 float를 int 캐스트로 포화시키기위한 내장 함수를 구현하기위한 작업을 시작했습니다. https://reviews.llvm.org/D54749

그것이 어디로 든 가면 포화 의미를 얻는 비교적 낮은 오버 헤드 방법을 제공합니다.

이 정의되지 않은 동작을 어떻게 재현합니까? 댓글에서 예제를 시도했지만 결과는 255 였는데, 나에게 괜찮아 보입니다.

println!("{}", 1.04E+17 as u8);

정의되지 않은 동작은 그런 식으로 안정적으로 관찰 할 수 없으며 때로는 예상 한대로 제공되지만 더 복잡한 상황에서는 고장이 발생합니다.

간단히 말해, 우리가 사용하는 코드 생성 엔진 (LLVM)은 이런 일이 발생하지 않는다고 가정 할 수 있으므로이 가정에 의존하면 잘못된 코드를 생성 할 수 있습니다.

@ AaronM04 재현 가능한 정의되지 않은 동작의 예가 오늘 reddit 에

fn main() {
    let a = 360.0f32;
    println!("{}", a as u8);

    let a = 360.0f32 as u8;
    println!("{}", a);

    println!("{}", 360.0f32 as u8);
}

( 놀이터 참조)

나는 마지막 코멘트가 이전 코멘트 와 관련하여 @ AaronM04를 위한 것이라고 가정한다.

"오, 그럼 충분히 쉽 네요."

• @pcwalton , 2014 년

죄송합니다. 저는 좋은 의도의 6 년 역사를 매우주의 깊게 읽었습니다. 하지만 진지하게, 10 년 중 6 년! 정치인 포럼 이었다면 여기에서 타오르는 파괴 행위를 예상했을 것입니다.

그렇다면 누구든지 간단한 말로 해답을 찾는 과정이 해법 자체보다 더 흥미로워지는 이유는 무엇입니까?

처음에 보였던 것보다 어렵고 LLVM 변경이 필요하기 때문입니다.

좋아,하지만 두 번째 주에이 LLVM을 만든 사람은 신이 아니었고, 같은 방향으로 나아가는 데이 근본적인 문제를 해결하는 데 15 년이 더 걸릴 수 있습니다.

정말, 나는 누군가를 해칠 관심이없고, 갑자기 도움을주기 위해 Rust 인프라를 처음 접했지만,이 사건에 대해 알게되었을 때 저는 놀랐습니다.

이 문제 추적기는이 문제를 해결하는 방법을 논의하기위한 것이며 명백한 것을 언급하면 ​​그 방향으로 진전이 없습니다. 따라서 문제 해결을 돕고 싶거나 기여할 새로운 정보가 있다면 그렇게하십시오. 그렇지 않으면 귀하의 의견이 마법처럼 수정 사항을 표시하지 않을 것입니다. :)

이것이 LLVM의 변경이 필요하다는 가정은 시기상조라고 생각합니다.

최소한의 성능 비용으로 언어로 할 수 있다고 생각합니다. 그것은 획기적인 변화일까요 * * 그렇습니다. 그러나 그것은 할 수 있고, 이루어져야합니다.

내 해결책은 unsafe 로 int 캐스트에 float를 정의한 다음 표준 lib에 몇 가지 도우미 함수를 제공하여 Result 유형에 바인딩 된 결과를 제공하는 것입니다.

그것은 섹시하지 않은 수정이며 주요 변경 사항이지만 궁극적으로 모든 개발자가 이미 기존 UB를 해결하기 위해 스스로 코딩해야하는 것입니다. 이것이 올바른 녹 방식입니다.

@RalfJung , 이해하게 해주셔서 감사합니다. 나는 생산적인 브레인 스토밍 과정에 누군가를 모욕하거나 경멸 적으로 개입 할 의도가 없었습니다. 녹에 새롭다는 것은 사실입니다. 내가 할 수있는 일이별로 없습니다. 그럼에도 불구하고 그것은 나와 녹슬 려하는 다른 사람들에게 도움이되며, 해결되지 않은 결함에 대해 더 많이 배우고 관련 결과를내는 데 도움이됩니다. 그러나 "내 쓸모없는 댓글"을 제거하는 것이 훨씬 쉬워 질 것이라는 점은 이미 기쁩니다.

스레드의 앞부분에서 언급했듯이 관련 팀이 오래 전에 동의했듯이 필요한 의미 체계를 지원하기 위해 llvm을 수정하여 느리지 만 확실히 올바른 방법으로 수정되고 있습니다.

이 토론에 더 이상 추가 할 수있는 것은 없습니다.

https://reviews.llvm.org/D54749

@nikic LLVM 측의 진행이 중단 된 것 같습니다. 가능하면 간단한 업데이트를 제공 할 수 있습니까? 감사.

saturating cast는 사용자가 soundess를 얻기 위해 사전 회귀를 사용하려는 경우 선택할 수있는 라이브러리 기능으로 구현할 수 있습니까? 컴파일러의 구현을 읽고 있지만 매우 미묘한 것 같습니다.

https://github.com/rust-lang/rust/blob/625451e376bb2e5283fc4741caa0a3e8a2ca4d54/src/librustc_codegen_ssa/mir/rvalue.rs#L774 -L901

우리는 -Z 플래그와 관계없이 채도를 위해 LLVM IR을 생성하는 내장 (현재 오픈 코딩 된 IR 또는 향후 llvm.fpto[su]i.sat 을 노출 할 수 있습니다. 그것은 전혀 어렵지 않습니다.

그러나 나는 그것이 최선의 행동 방침인지 걱정됩니다. (if?) 채도가 as 캐스트의 기본 의미가되면 이러한 API는 중복됩니다. 또한 일시적 일지라도 사용자가 건전성 또는 성능을 원하는지 스스로 선택해야한다고 말하는 것도 좋지 않은 것 같습니다.

동시에 현재 상황은 훨씬 더 나빠졌습니다. 라이브러리 API를 추가 할 생각이라면 기본적으로 채도를 활성화하고 NaN에 UB가 있고 범위를 벗어난 숫자가있는 unsafe 내장 함수를 제공하도록 점점 더 경고하고 있습니다. 일반 fpto[su]i ). 그것은 여전히 ​​기본적으로 동일한 선택을 제공 할 것이지만, 기본적으로 건전성을 제공 할 것이며, 새로운 API는 미래에 중복되지 않을 것입니다.

기본적으로 소리로 전환하면 좋은 소리가납니다. 나는 우리가 처음부터가 아니라 요청에 따라 게으른 내재를 제공 할 수 있다고 생각합니다. 또한 const eval은이 경우에도 채도를 수행합니까? (cc @RalfJung @eddyb @ oli-obk)

CONST 평가 우리가 이미 포화을하고 연령대에 그렇게있다가, 심지어 미리 전에 생각 (나는 분명히 그것을 변경 기억 된 llvm::Constant 기반 평가자).

트윗 담아 가기 문제의 코드에 대해 잘 알고 있으므로 기본값을 전환하는 데 앞장서시겠습니까?

뿡뿡

채도를 위해 LLVM IR을 생성하는 내장 함수를 노출 할 수 있습니다.

소스 및 대상 유형의 각 조합에 대해 10 개 또는 12 개의 개별 내장 함수가 필요할 수 있습니다.

센트릴

기본적으로 소리로 전환하면 좋은 소리가납니다. 나는 우리가 처음부터가 아니라 요청에 따라 게으른 내재를 제공 할 수 있다고 생각합니다.

다른 주석과 달리 "내재"는 as 가 포화 상태 일 때 더 적은 선행 회귀를 갖는 것을 의미한다고 가정합니다.

나는 이것이 알려진 중요한 회귀를 다루는 좋은 접근 방식이라고 생각하지 않습니다. 일부 사용자의 경우 성능 손실이 실제 문제가 될 수 있지만 알고리즘은 입력이 항상 범위 내에 있는지 확인합니다. 이 스레드에 가입하지 않은 경우 변경 사항이 Stable 채널에 도달했을 때만 영향을 받는다는 것을 알 수 있습니다. 이 시점에서 요청 즉시 안전하지 않은 API를 제공하더라도 6 ~ 12 주 동안 멈출 수 있습니다.

오히려 사용 중단 경고에 대해 이미 설정된 패턴을 따르고 싶습니다. 한동안 Stable에서 대안을 사용할 수있게 된 후에 만 ​​Nightly에서 전환하십시오.

소스 및 대상 유형의 각 조합에 대해 10 개 또는 12 개의 개별 내장 함수가 필요할 수 있습니다.

좋아, 날 잡았지만 그게 어떤 관련이 있는지 모르겠어? 30 개의 내장 함수를 추가하는 것은 여전히 ​​사소한 일입니다. 그러나 실제로는 N 씬 래퍼에서 사용하는 단일 일반 내장 함수를 사용하는 것이 훨씬 더 쉽습니다. " as 사운드를 만들고 unsafe 캐스트 API 도입"옵션을 선택해도 숫자는 변경되지 않습니다.

나는 이것이 _ 알려진 _ 중요한 회귀를 다루는 좋은 접근 방식이라고 생각하지 않습니다. 일부 사용자의 경우 성능 손실이 실제 문제가 될 수 있지만 알고리즘은 입력이 항상 범위 내에 있는지 확인합니다. 이 스레드에 가입하지 않은 경우 변경 사항이 Stable 채널에 도달했을 때만 영향을 받는다는 것을 알 수 있습니다. 이 시점에서 요청 즉시 안전하지 않은 API를 제공하더라도 6 ~ 12 주 동안 멈출 수 있습니다.

+1

모든 릴리스 채널에서 경고없는 상태를 유지하는 것보다 모든 릴리스 채널에서 성능 회귀없는 상태를 유지하는 것이 덜 중요해 보이기 때문에 사용 중단 경고 절차 (교체가 안정된 경우 야간에만 사용 중단)가 필요한지 확실하지 않습니다. 하지만 다시 12 주 더 기다리는 것은 기본적으로이 문제가 얼마나 오래 지속되었는지에 대한 반올림 오류입니다.

또한 -Zsaturating-float-casts 는 그대로 두어도됩니다 (기본값 만 변경). 즉, 야간 사용자는 잠시 동안 계속해서 cange에서 옵트 아웃 할 수 있습니다.

(예, 내장 함수의 수는 구현 세부 사항 일 뿐이며 어떤 것에 대한 주장이나 반대의 의미가 아닙니다.)

내가 여기에 의견을 모두 소화 한 것으로 주장 할 수 없습니다,하지만 난 LLVM이 있다는 인상이다 @rkruppe 지금 , 바로 여기 UB 제거에 "최단 경로를"차단 항목이었다 동결 명령을 가지고있다?

freeze 이 너무 새롭기 때문에 우리의 LLVM 버전에서는 사용할 수 없을 수도 있습니다. 그래도 아마도 2020 년 상반기에 개발을 모색해야 할 것 같습니까?

이 시점에서 우리가 원하는 경로에 대한 대략적인 합의를 얻기 위해 T- 컴파일러 회의에서 토론을 위해 지명합니다.

freeze 은 여기에 언급 된 모든 이유로 여전히 문제가 freeze 가 임의의 쓰레기 또는 비밀 키를 반환 할 것으로 예상됩니다. (어딘가에서 온라인으로 읽었고 요약이 정말 마음에 듭니다. : D)

어쨌든 무작위 쓰레기를 반환하는 것조차 as 캐스트에는 다소 나빠 보입니다. unchecked_add 와 유사하게 필요한 경우 속도를 위해 더 빠른 작업을 수행하는 것이 합리적이지만 기본값 이 Rust의 정신에 상당히 반하는 것처럼 보입니다.

@SimonSapin 당신은 먼저 반대 접근법을 제안했습니다 (기본값은 불건전 / "이상한"의미론이고 명시 적으로 건전한 방법을 제공합니다). 나는 당신이 건전성 (적절한 전환 기간 이후)에 불이행하는 것이 합리적이라고 생각하는지 또는 더 낫다고 생각하는지 나중에 당신의 의견에서 말할 수 없습니다.

뿡뿡

나는 LLVM이 이제 동결 명령을 가지고 있다는 인상을 받고 있는데, 이것은 여기서 UB를 제거하는 "최단 경로"를 차단하는 항목이었습니다. 맞습니까?

몇 가지주의 사항이 있습니다. 가장 중요한 것은 UB를 제거하고 번들로 제공되는 LLVM을 freeze (언제든지 할 수 있음)을 포함하도록 업데이트하더라도 여러 이전 버전을 지원합니다 (다시 LLVM 6으로 순간) 모든 사용자의 UB를 실제로 제거하려면 대체 구현이 필요합니다.

둘째, 물론 "UB가 아니라"라는 질문이 우리가 그것에있는 동안 우리가 관심을 갖는 전부인지 여부입니다. 특히 freeze(fptosi %x) 매우 반 직관적으로 작동한다는 점을 다시 강조하고 싶습니다. 이것은 비 결정적이며 실행될 때마다 다른 결과 ( @RalfJung이 말한 것처럼 민감한 메모리에서 가져온 결과도)를 반환 할 수 있습니다. 지금 다시 논의하고 싶지는 않지만 채도를 기본값으로 만들고 선택되지 않은 (안전하지 않거나 freeze 사용) 변환을 만들기 위해 조금 더 많은 작업을 수행하려면 회의에서 고려해 볼 가치가 있습니다. 기본값이 아닌 옵션.

@RalfJung 내 입장은 as 는 입력 및 출력 유형에 따라 크게 다른 의미 (잘림, 채도, 반올림,…)를 가질 수 있기 때문에이 문제와 관계없이 완전히 피하는 것이 가장 좋습니다. 코드를 읽을 때 분명합니다. (후자조차도 foo as _ 으로 추론 할 수 있습니다.) 그래서 저는 as 이 오늘날 수행하는 경우를 포괄하는 다양한 명시 적으로 명명 된 변환 방법을 제안하기위한 사전 RFC 초안을 가지고 있습니다. .

내 생각 as 그것의 사용 외부 될 수 있기 때문에 확실히, UB가 없어야 unsafe . 쓰레기를 반납하는 것도 좋지 않습니다. 그러나 우리는 포화 캐스트로 인한 성능 회귀의 알려진 사례에 대해 일종의 완화 / 전환 / 대안을 가져야합니다. 이 전환에 대한 RFC 초안을 차단하지 않기 위해 포화 캐스트의 라이브러리 구현에 대해서만 질문했습니다.

뿡 빵뀨

내 입장은이 문제에 관계없이 완전히 피하는 것이 가장 좋습니다. 왜냐하면 그것은 매우 다른 의미 (절단, 포화, 반올림,…)를 가질 수 있기 때문입니다.

동의합니다. 그러나 그것은이 문제를 해결하는 데 실제로 도움이되지 않습니다.

(또한, as 을 (를) 필요로하지 않게 만들기 위해 노력하고있어 기쁩니다. 기대합니다. : D)

안전하지 않은 외부에서 사용할 수 있기 때문에 UB가 없어야한다고 생각합니다. 쓰레기를 반납하는 것도 좋지 않습니다. 그러나 우리는 포화 캐스트로 인한 성능 회귀의 알려진 사례에 대해 일종의 완화 / 전환 / 대안을 가져야합니다. 이 전환에 대한 RFC 초안을 차단하지 않기 위해 포화 캐스트의 라이브러리 구현에 대해서만 질문했습니다.

그래서 우리는 최종 상태가 float-to-int as 포화 상태 여야한다는 데 동의하는 것 같습니다. 나는 그것이 우리가 향하고있는 최종 목표 인 한 어떤 전환 계획에 만족합니다.

그 최종 목표는 나에게 좋은 것 같습니다.

나는 이것이 _ 알려진 _ 중요한 회귀를 다루는 좋은 접근 방식이라고 생각하지 않습니다. 일부 사용자의 경우 성능 손실이 실제 문제가 될 수 있지만 알고리즘은 입력이 항상 범위 내에 있는지 확인합니다. 이 스레드에 가입하지 않은 경우 변경 사항이 Stable 채널에 도달했을 때만 영향을 받는다는 것을 알 수 있습니다. 이 시점에서 요청 즉시 안전하지 않은 API를 제공하더라도 6 ~ 12 주 동안 멈출 수 있습니다.

내 생각에, 해당 사용자가 6-12 주 동안 rustc 업그레이드를 기다리면 세상의 종말이 아닐 것입니다. 두 경우 모두 다가오는 릴리스에서 아무것도 필요하지 않거나 라이브러리에 MSRV 제약이있을 수 있습니다. 받치다.

한편, 스레드에 가입하지 않은 사용자는 성능 손실이 발생할 수있는 것처럼 잘못 컴파일 될 수 있습니다. 무엇을 우선시해야합니까? 우리는 안정성에 대한 보증을 제공하고 안전에 대한 보증을 제공합니다.하지만 제가 아는 한 성능에 대해서는 그러한 보증이 제공되지 않습니다 (예 : RFC 1122는 성능을 전혀 언급하지 않음).

오히려 사용 중단 경고에 대해 이미 설정된 패턴을 따르고 싶습니다. 한동안 Stable에서 대안을 사용할 수있게 된 후에 만 ​​Nightly에서 전환하십시오.

지원 중단 경고의 경우 안정적인 대안이있을 때까지 지원 중단을 기다리는 결과는 적어도 내가 아는 한 대기 기간 동안 건전성 구멍이 발생하지 않습니다. (또한 여기에 내장 함수를 제공 할 수 있지만 일반적인 경우 건전성 구멍을 고칠 때 합리적으로 대안을 제공하지 못할 수 있습니다. 따라서 안정적인 대안을 갖는 것이 어려운 요구 사항이 될 수 있다고 생각하지 않습니다.)

좋아, 날 잡았지만 그게 어떤 관련이 있는지 모르겠어? 30 개의 내장 함수를 추가하는 것은 여전히 ​​사소한 일입니다. 그러나 실제로는 N 씬 래퍼에서 사용하는 단일 일반 내장 함수를 사용하는 것이 훨씬 더 쉽습니다. " as 사운드를 만들고 unsafe 캐스트 API 도입"옵션을 선택해도 숫자는 변경되지 않습니다.

단일 제네릭 내장 함수는 12/30 특정 모노 모픽 인스턴스화를 위해 컴파일러에서 별도의 구현을 요구하지 않습니까?

LLVM이 이미 대부분의 작업을 수행했기 때문에 컴파일러에 내장 함수를 추가하는 것은 사소 할 수 있지만 전체 비용과는 거리가 멀습니다. 또한 Miri, Cranelift의 구현 및 사양에 필요한 최종 작업이 있습니다. 그래서 누군가가 필요로하는 기회에 내장 기능을 추가해서는 안된다고 생각합니다.

그러나 나는 더 많은 내재를 노출하는 것을 반대하지는 않지만 누군가 그것을 필요로하는 경우 제안 (예 : 정교한 설명이있는 PR)을 만들고 벤치마킹 수치 등으로 추가를 정당화해야합니다.

또한 -Zsaturating-float-casts 는 그대로 두어도됩니다 (기본값 만 변경). 즉, 야간 사용자는 잠시 동안 계속해서 cange에서 옵트 아웃 할 수 있습니다.

이것은 나에게 괜찮아 보이지만 이미이 플래그를 사용하는 사람들을 위해 의미를 불건전하게 변경하지 않도록 플래그 이름을 -Zunsaturating-float-casts 로 변경하는 것이 좋습니다.

센트릴

단일 제네릭 내장 함수는 12/30 특정 모노 모픽 인스턴스화를 위해 컴파일러에서 별도의 구현을 요구하지 않습니까?

아니요, 대부분의 구현은 소스 및 대상 비트 폭에 대한 매개 변수화를 통해 이미 공유 될 수 있으며 이미 공유됩니다. 몇 비트 만 대소 문자 구분이 필요합니다. miri의 구현에도 동일하게 적용되며 다른 구현 및 사양에도 적용됩니다.

(편집 : 명확하게 말하면,이 공유는 N 개의 고유 한 내장 함수가있는 경우에도 발생할 수 있지만 단일 일반 내장 함수는 내장 함수별로 필요한 상용구를 줄입니다.)

그래서 누군가가 필요로하는 기회에 내장 기능을 추가해서는 안된다고 생각합니다.

그러나 나는 더 많은 내재를 노출하는 것을 반대하지는 않지만 누군가 그것을 필요로하는 경우 제안 (예 : 정교한 설명이있는 PR)을 만들고 벤치마킹 수치 등으로 추가를 정당화해야합니다. 그동안 건전성 구멍을 고치는 것을 막아야한다고 생각하지 않습니다.

이미 벤치마킹 수치가 있습니다. 오래 전 벤치 마크 요청을 통해 JPEG 인코딩이 포화 캐스트를 사용 상당히 느려진다 는 것을 알고 있습니다. 누군가 다시 실행할 수 있지만 이것이 변경되지 않았다고 확신하고 (물론 특정 숫자가 동일하지는 않지만) 채도가 구현되는 방식에 대한 향후 변경 (예 : 인라인 asm 또는 @nikic이 작업 한 LLVM 내장 함수)는 근본적으로이를 바꿀 것입니다. 미래에 대해 확신하기는 어렵지만, 제가 추측 한 바에 따르면 성능을 되 찾을 수있는 유일한 방법은 unsafe 변환 또는 freeze 사용하는 것과 같이 범위 검사없이 코드를 생성하는 것을 사용하는 것입니다.

좋습니다. 기존 벤치마킹 수치를 보면 해당 내장 함수에 대한 적극적인 욕구가있는 것 같습니다. 그렇다면 다음과 같은 실행 계획을 제안합니다.

1. 동시에 :
   
   
   
   • #[unstable(...)] 함수를 통해 야간에 노출되는 내장 함수를 소개합니다.
   
   
   • -Zsaturating-float-casts 제거하고 -Zunsaturating-float-casts 합니다.
   
   
   • 기본값을 -Zsaturating-float-casts 전환합니다.
   
   
2. 잠시 후 내장 함수를 안정화합니다. 우리는 조금 빨리 추적 할 수 있습니다.
3. 잠시 후 -Zunsaturating-float-casts 제거하십시오.

좋아. 내장 함수가 일부 공용 API의 구현 세부 사항이라는 점을 제외하면 f32 및 f64 메소드 일 수 있습니다. 다음 중 하나 일 수 있습니다.

• 선택적으로 전주곡에서 일반 특성의 메서드 (변환의 정수 반환 유형에 대한 매개 변수 포함)
• 다양한 반환 유형을 지원하기 위해 지원 트레이 트 ( str::parse 및 FromStr 와 유사)가있는 고유 메서드
• 이름에 대상 유형이있는 여러 비 일반 고유 메서드

네, 방법이나 그와 같은 것을 통해 내장 함수를 노출하는 것을 의미했습니다.

이름에 대상 유형이있는 여러 비 일반 고유 메서드

이것은 우리가하는 일반적인 일처럼 느껴집니다.이 옵션에 대한 이의가 있습니까?

그래도? 메소드 이름의 일부로 유형 (서명)의 이름이있을 때 임시 "하나의"변환 (예 Vec::as_slice 및 [T]::to_vec ) 또는 차이가 유형이 아닌 일련의 전환 (예 to_ne_bytes , to_be_bytes , to_le_bytes ). 그러나 std::convert 의 특성에 대한 동기의 일부는 u8::to_u16 , u8::to_u32 , u8::to_u64 등과 같은 수십 개의 개별 메서드를 피하는 것이 었습니다.

내 궁금한 점은 메서드가 unsafe fn 여야한다는 점을 감안할 때 이것이 자연적으로 특성에 일반화 될 수 있는지 여부입니다. 고유 한 메서드를 추가하면 항상 트레이 트 구현에있는 메서드에 위임 할 수 있습니다.

안전하지 않은 변환에 대한 특성을 추가하는 것이 이상해 보이지만 아마도 Simon은 부동 소수점과 정수 유형의 각 조합에 대해 다른 방법이 필요할 수 있다는 사실에 대해 생각하고있을 것입니다 (예 : f32::to_u8_unsaturated , f32::to_u16_unsaturated 등).

긴 실에 얽매이지 않기 위해 나는 완전히 무지하게 읽지 않았지만 그것이 바람직하거나 u32 또는 다른 것으로 변환되는 f32::to_integer_unsaturated 를 갖는 것으로 충분합니까? 안전하지 않은 변환의 대상 유형에 대한 분명한 선택이 있습니까?

안전하지 않은 변환을 i32 / u32 (예를 들어)로만 제공하면 값 범위가 엄격하게 작지 않은 모든 정수 유형이 완전히 제외되며, 이는 반드시 필요한 경우가 있습니다. 더 작은 크기 (JPEG 인코딩에서와 같이 u8까지)도 종종 필요하지만 더 넓은 정수 유형으로 변환하고 as (일반적으로 무료는 아니지만 저렴함)로 잘라서 에뮬레이션 할 수 있습니다.

그러나 우리는 가장 큰 정수 크기로의 변환만을 제공 할 수 없습니다. 그것들은 항상 기본적으로 지원되는 것은 아니며 (따라서 느리게) 최적화로 해결할 수 없습니다. 후자는 UB (LLVM IR에서)를 가지고 있기 때문에 "큰 정수로 변환 한 다음 자르기"를 "작은 정수로 직접 변환"으로 최적화하는 것은 옳지 않습니다. / 잘라낼 때 원래 변환 결과가 래핑 된 경우 다른 결과 (기계 코드 수준, 대부분의 아키텍처).

실용적으로 128 비트 정수를 제외하고 64 비트 정수에 초점을 맞추더라도 일반적인 32 비트 대상에는 여전히 좋지 않습니다.

나는이 대화에 익숙하지 않지만 프로그래밍에는 익숙하지 않습니다. 사람들이 포화 변환과 NaN을 0으로 변환하는 것이 합리적인 기본 동작이라고 생각하는 이유가 궁금합니다. Java가이 작업을 수행한다는 것을 이해합니다 (랩핑이 훨씬 더 일반적으로 보이지만), NaN이 실제로 올바른 변환이라고 말할 수있는 정수 값은 없습니다. 마찬가지로 예를 들어 1000000.0을 65535 (u16)로 변환하는 것은 잘못된 것 같습니다. 분명히 정답 인 u16은 없습니다. 적어도 C / C ++, C #, go 및 기타와 공유되는 동작 인 16960으로 변환하는 현재 동작보다 낫다고 생각하지 않습니다. 따라서 적어도 다소 놀랍지 않습니다.

오버플로 검사와의 유사성에 대해 여러 사람이 언급 한 바 있으며 이에 동의합니다. 또한 정수를 0으로 나누는 것과 유사합니다. 잘못된 변환은 잘못된 산술처럼 당황해야한다고 생각합니다. NaN-> 0 및 1000000.0-> 65535 (또는 16960)에 의존하는 것은 정수 오버플로 또는 가상의 n / 0 == 0에 의존하는 것만 큼 오류가 발생하기 쉬운 것처럼 보입니다. 기본적으로 오류를 생성해야하는 종류입니다. (릴리스 빌드에서 rust는 정수 산술과 마찬가지로 오류 검사를 제거 할 수 있습니다.) 그리고 드물게 NaN을 0으로 변환하거나 부동 소수점 포화를 갖기를 _ 원하는 경우에는 다음과 같이 선택해야합니다. 정수 오버플로를 선택해야합니다.

성능에 관해서는 일반 변환을 수행하고 하드웨어 결함에 의존하는 것이 가장 높은 일반 성능을 제공하는 것 같습니다. 예를 들어 x86과 ARM 모두 부동 소수점에서 정수로의 변환을 올바르게 표현할 수없는 경우 (NaN 및 범위를 벗어난 경우 모두 포함) 하드웨어 예외를 발생시킵니다. 이 솔루션은 디버그 빌드에서 부동 소수점에서 작은 정수 유형으로 직접 변환하는 경우를 제외하고는 유효하지 않은 변환을 제외하고 비용이 들지 않습니다. 드문 경우이지만 여전히 비교적 저렴해야합니다. (이러한 예외를 지원하지 않는 이론적 인 하드웨어에서는 소프트웨어에서 에뮬레이션 할 수 있지만 다시 디버그 빌드에서만 가능합니다.) 하드웨어 예외는 정확히 0으로 정수 나누기를 감지하는 것이 오늘날 구현되는 방식이라고 생각합니다. LLVM에 대한 많은 이야기를 보았으므로 여기에 제한이있을 수 있지만 본질적으로 잘못된 변환에 대해 모호한 대체 동작을 제공하기 위해 릴리스 빌드에서도 모든 부동 소수점 변환에서 소프트웨어 에뮬레이션을 사용하는 것은 불행한 일입니다.

@admilazz 우리는 LLVM이 할 수있는 일에 제약을 받고 있으며 현재 LLVM은 정의되지 않은 동작의 위험없이 실수를 정수로 효율적으로 변환하는 방법을 노출하지 않습니다.

포화 상태는 언어가 as 캐스트를 항상 성공하도록 정의하기 때문에 연산자를 대신 패닉 상태로 변경할 수 없기 때문입니다.

마찬가지로 예를 들어 1000000.0을 65535 (u16)로 변환하는 것은 잘못된 것 같습니다. 분명히 정답 인 u16은 없습니다. 적어도 나는 그것을 16960으로 변환하는 현재 동작보다 더 나은 것으로 보지 않습니다.

그것은 나에게 분명하지 않았기 때문에 지적 할 가치가 있다고 생각합니다. 16960은 1000000.0을 충분한 폭의 정수로 변환 한 다음 16 개의 하위 비트를 유지하기 위해 자른 결과입니다.

이것은 ~이 스레드에서 이전에 제안 된 옵션이 아니며 ~ (편집 : 여기에서 잘못되었습니다. 찾지 못해 죄송합니다) 현재 동작도 아닙니다. Rust의 현재 동작은 범위를 벗어난 float-to-integer 변환이 Undefined Behavior라는 것입니다. 실제로 이것은 종종 가비지 값으로 이어지며 원칙적으로 잘못 컴파일 및 취약성을 유발할 수 있습니다. 이 스레드는 모든 것을 고치는 것입니다. Rust 1.39.0에서 아래 프로그램을 실행하면 매번 다른 값을 얻습니다.

fn main() {
    dbg!(1000000.0 as u16);
}

놀이터 . 출력 예 :

[src/main.rs:2] 1000000.0 as u16 = 49072

개인적으로 정수형 잘림이 채도보다 낫거나 나쁘지 않다고 생각합니다. 둘 다 범위를 벗어난 값에 대해 수치 적으로 잘못되었습니다. UB가 아니라 결정 론적이라면 오류없는 변환이 그 자리를 차지합니다. 알고리즘을 통해 값이 범위 내에 있음을 이미 알고 있거나 그러한 경우에 대해 신경 쓰지 않을 수 있습니다.

Result 를 반환하는 잘못된 변환 API 도 추가해야한다고 생각하지만 여전히 RFC 초안 작성을 완료해야합니다. :)

"수학적 정수로 변환 한 다음 대상 너비로 자르기"또는 "랩 어라운드"시맨틱 은 이 스레드에서 이전에 제안되었습니다 (https://github.com/rust-lang/rust/issues/10184#issuecomment-299229143). 나는 특히 그것을 좋아하지 않는다 :

• 채도보다 약간 덜 현명하다고 생각합니다. 채도는 일반적으로 범위를 벗어난 숫자에 대해 합리적인 결과를 제공하지 않지만 다음과 같습니다.
  
  
  
  • 숫자가 범위를 약간 벗어날 때 (예 : 누적 된 반올림 오류로 인해) 랩 어라운드보다 더 현명하게 작동합니다. 반대로, 둘러싸는 캐스트는 float 계산에서 약간의 반올림 오류를 정수 영역에서 가능한 최대 오류로 증폭 할 수 있습니다.
  
  
  • 디지털 신호 처리에서 다소 일반적으로 사용되므로 실제로 원하는 응용 프로그램이 적어도 있습니다. 대조적으로, 나는 랩 어라운드 시맨틱으로부터 이득을 얻는 단일 알고리즘을 모른다.
  
  
• AFAIK는 랩 어라운드 의미론을 선호 하는 유일한 이유는 소프트웨어 에뮬레이션의 효율성이지만, 이것은 증명되지 않은 가정처럼 보입니다. 나는 틀렸다는 것이 증명되어 기쁠 것이지만, 간략하게 살펴보면 ALU 명령의 긴 체인 (무한과 NaN을 개별적으로 처리하기위한 분기 포함)이 필요한 것처럼 보이므로 분명한 것이 더 낫다고 생각하지 않습니다. 다른 것보다 성능.
• NaN 대해 무엇을해야하는지에 대한 질문은 정수로의 변환에 대한 추악한 문제이지만, 채도는 적어도 무한대에 대해 특별한 대 / 소문자를 필요로하지 않습니다 (의미론이나 대부분의 구현에서). 그러나 랩 어라운드의 경우 +/- 무한대에 해당하는 정수는 무엇입니까? JavaScript는 그것이 0이라고 말하고, NaN에서 as 패닉을 만들면 무한대에서도 패닉 할 수 있다고 가정합니다. 그러나 어느 쪽이든 정상 및 비정규 숫자를 보는 것보다 빠르게 랩 어라운드를 만드는 것이 더 어려워 보입니다. 혼자서 제안 할 것입니다.

변환을위한 포화 의미론에 의해 회귀 된 대부분의 코드는 SIMD를 사용하는 것이 더 나을 것이라고 생각합니다. 따라서 안타깝게도이 변경으로 인해 고성능 코드가 작성되는 것을 막을 수 없으며 (특히 다른 의미 체계를 가진 내장 함수가 제공되는 경우) 일부 프로젝트를 더 빠른 (이동성이 떨어지는 경우) 구현으로 이동시킬 수도 있습니다.

그렇다면 건전성 구멍을 막는 것을 방지하기 위해 약간의 성능 회귀를 정당화해서는 안됩니다.

https://github.com/rust-lang/rust/pull/66841 은 값이 알려진 경우 LLVM의 fptoui 및 fptosi 로 변환하는 unsafe fn 메서드를 추가합니다. 범위 내에 있고 포화 상태가되는 것은 측정 가능한 성능 회귀입니다.

그 후 나는 as 의 기본값을 바꾸는 것이 좋다고 생각합니다 (그리고 아마도 다른 -Z 플래그를 추가하여 옵트 아웃 할 수 있습니까?). 비록 그것은 아마도 공식적인 Lang 팀 결정일 것입니다.

그 후 나는 as 의 기본값을 바꾸는 것이 좋다고 생각합니다 (그리고 아마도 다른 -Z 플래그를 추가하여 옵트 아웃 할 수 있습니까?). 비록 그것이 공식적인 Lang 팀 결정일 것입니다.

그래서 우리는 (적어도 거기에 있었던 사람들과 함께 언어 팀) 이것을 https://github.com/rust-lang/lang-team/blob/master/minutes/2019-11-21.md 에서 논의했고 우리는 생각했습니다 새로운 내장 함수를 추가하고 -Zunsaturated-float-casts 를 추가하는 것이 좋은 첫 번째 단계입니다.

필요한 경우 FCP를 사용하여 기본값을 그 일부로 또는 그 직후에 전환하는 것이 좋을 것이라고 생각합니다.

새로운 내장 함수에 의해 https://github.com/rust-lang/rust/pull/66841 과 같은 것을 의미한다고 가정합니다.

기본값을 변경하지 않고 -Z unsaturated-float-casts 을 추가한다는 것은 무엇을 의미합니까? "오류 : 알 수없는 디버깅 옵션"을 표시하지 않고 no-op으로 수락 하시겠습니까?

새로운 내장 함수에 의해 다음과 같은 의미가 있다고 가정합니다. # 66841

네 👍-선두에 서서 감사합니다.

기본값을 변경하지 않고 -Z unsaturated-float-casts 을 추가한다는 것은 무엇을 의미합니까? "오류 : 알 수없는 디버깅 옵션"을 표시하지 않고 no-op으로 수락 하시겠습니까?

네 기본적으로. 또는 -Z saturated-float-casts 대신 -Z unsaturated-float-casts 하고 기본값을 직접 전환하지만 더 적은 수의 PR에 대해 동일한 결과로 이어져야합니다.

나는 "불포화"제안을 정말로 이해하지 못한다. 목표가 새로운 기본값을 옵트 아웃 할 수있는 노브를 제공하는 것이라면 기존 플래그의 기본값을 변경하고 더 이상 아무것도하지 않는 것이 더 쉽습니다. 목표가 트레이드 오프 (불건전 함)에 대해 더 명확한 새 이름을 선택하는 것이라면 "불포화"는 끔찍합니다. 대신 "안전하지 않은"또는 "UB"또는 이와 유사한 이름을 포함하는 이름을 제안합니다. 무서운 단어 (예 -Z fix-float-cast-ub .

unchecked 는 API 이름에 선례가있는 용어입니다.

@admilazz 우리는 LLVM이 할 수있는 일에 제약을 받고 있으며 현재 LLVM은 정의되지 않은 동작의 위험없이 실수를 정수로 효율적으로 변환하는 방법을 노출하지 않습니다.

그러나 아마도 정수 오버플로와 마찬가지로 디버그 빌드에서만 런타임 검사를 추가 할 수 있습니다.

AFAIK는 랩 어라운드 의미론을 선호하는 유일한 이유는 소프트웨어 에뮬레이션의 효율성입니다.

둘 다 틀 렸기 때문에 wraparound 또는 saturation을 선호하지 않는다고 생각하지만 wraparound는 C / C ++, C #, go, 아마도 D, 그리고 확실하게 rust와 비슷한 많은 언어에서 사용되는 방법이라는 이점이 있습니다. 더 많은 것, 그리고 녹의 현재 행동 (적어도 때때로)이기도합니다. 즉, 정수 오버플로와 0으로 나누기와 같은 유효하지 않은 산술에 대해 수행하는 것처럼 "잘못된 변환에 대한 패닉 (아마도 디버그 빌드에서만)"이 이상적이라고 생각합니다.

(흥미롭게도 놀이터 에서 16960을 얻었습니다. 그러나 게시 된 다른 예에서 녹이 다르게 작동한다는 것을 알 수 있습니다 ...)

포화 상태는 언어가 항상 성공하기 위해 캐스트로 정의하기 때문에 연산자를 대신 패닉 상태로 변경할 수 없기 때문입니다.

우리가 이미이 작업을 수행 한 사람들의 결과에 관심이있는 한 작업의 평가 대상을 변경하는 것은 이미 큰 변화입니다. 이처럼 당황하지 않는 행동도 바뀔 수 있습니다.

NaN에서 패닉으로 만들면 무한대에서도 패닉 할 수 있다고 생각합니다. 그러나 어느 쪽이든 빠르게 만들기가 더 어려워 질 것 같습니다.

정수 오버플로가 그렇듯이 디버그 빌드에서만 확인하면 두 가지 장점을 모두 얻을 수 있다고 생각합니다. 변환이 정확하다는 것이 보장되고 (디버그 빌드에서) 사용자 오류가 잡힐 가능성이 더 높으며 옵트 인 할 수 있습니다. 랩 어라운드 및 / 또는 원하는 경우 채도와 같은 이상한 동작에 대한 성능은 가능한 한 좋습니다.

또한 명령 줄 스위치를 통해이 항목을 제어하는 ​​것이 이상해 보입니다. 그것은 큰 망치입니다. 확실히 범위를 벗어난 변환의 원하는 동작은 알고리즘의 특성에 따라 달라 지므로 변환 단위로 제어해야합니다. f.to_u16_sat () 및 f.to_u16_wrap () 또는 이와 유사한 옵트 인을 제안하고 코드의 의미를 변경하는 명령 줄 옵션이 없습니다. 그것은 서로 다른 코드 조각을 혼합하고 일치시키는 것을 어렵게 만들고 그것을 읽는 것으로 무엇을하는지 이해할 수 없습니다 ...

그리고 "유효하지 않은 경우 패닉"을 기본 동작으로 만드는 것이 진정으로 용납되지 않는 경우이를 구현하지만 디버그 빌드에서 유효성 검사 만 수행하는 내장 메서드를 사용하여 (vast 대부분?) 변환 후 동일한 수를 얻을 것으로 예상되지만 릴리스 빌드에서 페널티를 지불하지 않는 경우.

흥미롭게도 놀이터에서 16960을 얻었습니다.

이것이 Undefined Behavior가 작동하는 방식입니다. 프로그램의 정확한 공식화와 정확한 컴파일러 버전 및 정확한 컴파일 플래그에 따라 결정적 동작이나 매 실행마다 변경되는 가비지 값 또는 잘못된 컴파일이 발생할 수 있습니다. 컴파일러는 무엇이든 할 수 있습니다.

랩 어라운드는 C / C ++, C #, go, 아마도 D 등의 여러 언어에서 사용되는 방법이라는 장점이 있습니다.

정말인가요? 적어도 C와 C ++에서는 아니지만 Rust와 같은 Undefined Behavior를 가지고 있습니다. 이것은 우연이 아닙니다. 우리는 주로 C와 C ++를 구현하는 clang을 위해 구축 된 LLVM을 사용합니다. C #에 대해 확신하고 가십니까?

C11 표준 https://port70.net/~nsz/c/c11/n1570.html#6.3.1.4

실수 부동 형의 유한 값이 _Bool이 아닌 정수형으로 변환되면 소수 부분이 삭제됩니다 (즉, 값이 0으로 잘림). 정수 부분의 값을 정수 유형으로 표시 할 수없는 경우 동작이 정의되지 않습니다.

정수형의 값이 부호없는 유형으로 변환 될 때 수행되는 나머지 연산은 실수 부동 형의 값이 부호없는 유형으로 변환 될 때 수행 할 필요가 없습니다. 따라서 이식 가능한 실제 부동 값의 범위는 (-1, Utype_MAX + 1)입니다.

C ++ 17 표준 http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4659.pdf#section.7.10

부동 소수점 유형의 prvalue는 정수 유형의 prvalue로 변환 될 수 있습니다. 변환이 잘립니다. 즉, 소수 부분이 삭제됩니다. 잘린 값을 대상 유형으로 표시 할 수없는 경우 동작이 정의되지 않습니다.

C # 참조 https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/builtin-types/numeric-conversions

double 또는 float 값을 정수 유형으로 변환하면이 값은 가장 가까운 정수 값으로 0으로 반올림됩니다. 결과 정수 값이 대상 유형의 범위를 벗어나면 결과는 오버플로 검사 컨텍스트에 따라 달라집니다. 확인 된 컨텍스트에서는 OverflowException이 throw되고 확인되지 않은 컨텍스트에서는 결과가 대상 유형의 지정되지 않은 값입니다.

따라서 UB가 아니라 "지정되지 않은 값"일뿐입니다.

@admilazz 이것과 정수 오버플로 사이에는 큰 차이가 있습니다. 정수 오버플로는 바람직하지 않지만 잘 정의되어 있습니다. 부동 소수점 형변환은 정의되지 않은 동작 입니다.

당신이 요구하는 것은 릴리스 모드에서 Vec 경계 검사를 끄는 것과 비슷하지만 정의되지 않은 동작을 허용하기 때문에 잘못된 것입니다.

안전 코드에서 정의되지 않은 동작을 허용하는 것은 릴리스 모드에서만 발생하더라도 허용되지 않습니다. 따라서 수정 사항은 릴리스 및 디버그 모드 모두에 적용되어야합니다.

물론 디버그 모드에서 더 제한적인 수정을 할 수 있지만 릴리스 모드에 대한 수정은 여전히 ​​잘 정의되어 있어야합니다.

@admilazz 이것과 정수 오버플로 사이에는 큰 차이가 있습니다. 정수 오버플로는 바람직하지 않지만 잘 정의되어 있습니다. 부동 소수점 캐스트는 정의되지 않은 동작입니다.

물론입니다.하지만이 스레드는 동작을 정의하는 것입니다. Amanieu가 위에서 유용하게 참조한 C # 사양에서와 같이 "대상 유형의 지정되지 않은 값"을 생성하는 것으로 정의 된 경우 더 이상 정의되지 않을 것입니다 (위험한 방식으로). 디버그 빌드에서 여전히 패닉 상태가되기 때문에 실제 프로그램에서 정수 오버플로의 잘 정의 된 특성을 쉽게 사용할 수 없습니다. 마찬가지로, 릴리스 빌드에서 유효하지 않은 캐스트에 의해 생성 된 값은 예측 가능하거나 특히 유용 할 필요가 없습니다. 디버그 빌드에서 패닉이 발생하면 프로그램이 실제로 사용할 수 없기 때문입니다. 이것은 실제로 최적화를 위해 컴파일러에 최대 범위를 제공하는 반면, 포화와 같은 동작을 선택하면 컴파일러가 제한되고 네이티브 포화 변환 명령이없는 하드웨어에서 상당히 느려질 수 있습니다. (그리고 채도가 명확하게 정확하지 않습니다.)

당신이 요구하는 것은 릴리스 모드에서 Vec 경계 검사를 끄는 것과 유사하지만 정의되지 않은 동작을 허용하기 때문에 잘못된 것입니다. 안전한 코드에서 정의되지 않은 동작을 허용하는 것은 허용되지 않습니다.

정의되지 않은 모든 동작이 동일하지는 않습니다. 정의되지 않은 동작은 무슨 일이 일어나는지 결정하는 것은 컴파일러 구현 자에게 달려 있음을 의미합니다. float를 int로 캐스팅하여 rust의 안전 보장을 위반할 방법이없는 한, 사람들이 임의의 메모리 위치에 쓸 수 있도록 허용하는 것과 유사하지 않다고 생각합니다. 그럼에도 불구하고 물론 나는 그것이 반드시 예측 가능하지는 않더라도 안전을 보장한다는 의미로 정의되어야한다는 데 동의합니다.

정말인가요? 적어도 C와 C ++는 아니지만 Rust와 같은 Undefined Behavior를 가지고 있습니다 ... C #에 대해 확신하고 가세요?

그럴 수 있지. 나는 그들의 모든 사양을 읽지 않았습니다. 방금 다양한 컴파일러를 테스트했습니다. "내가 시도한 모든 컴파일러가 이런 식으로 수행한다"는 말은 "언어 사양이이를 이렇게 정의한다"는 말과 다르다는 말이 맞습니다. 그러나 나는 어쨌든 오버플로를 찬성하는 것이 아니라 그것이 가장 흔한 것 같다는 것을 지적 할 뿐이다. 저는 1) 정수 오버플로로부터 보호하는 것과 같은 이유로 1000000.0이 65535 또는 16960이되는 것과 같은 "잘못된"결과로부터 보호하는 변환에 찬성하고 있습니다. 버그 일 가능성이 높으므로 사용자가 선택해야합니다. , 및 2) 릴리스 빌드에서 최대 성능을 허용합니다.

정의되지 않은 모든 동작이 동일하지는 않습니다. 정의되지 않은 동작은 무슨 일이 일어나는지 결정하는 것은 컴파일러 구현 자에게 달려 있음을 의미합니다. float를 int로 캐스팅하여 rust의 안전 보장을 위반할 방법이없는 한, 사람들이 임의의 메모리 위치에 쓸 수 있도록 허용하는 것과 유사하지 않다고 생각합니다. 그럼에도 불구하고 물론 나는 그것이 정의되어야한다는 데 동의합니다 : 정의되어야하지만 반드시 예측 가능한 것은 아닙니다.

정의되지 않은 동작은 옵티 마이저 (C 및 C ++에 중점을 둔 LLVM 개발자가 제공)가 발생할 수 없다고 가정하고 정의되지 않은 캐스트를 통과해야만 도달 할 수있는 코드 청크 삭제를 포함하여 해당 가정에 따라 코드를 변환 할 수 있음을 의미합니다. 또는,로 이 예제의 첫 번째가 정의되지 않은 동작 될 것 호출하지 않고 호출 코드를 호출하기 때문에 쇼, 실제로 아니 었더라도, 과제가 호출되어 있어야합니다 가정.

다른 최적화 단계를 구성하는 것이 위험한 비상 동작을 생성하지 않는다는 것을 증명하는 것이 합리적이라고해도 LLVM 개발자는이를 보존하기 위해 의식적으로 노력하지 않을 것입니다.

나는 모든 정의되지 않은 행동 이 그 근거에서 비슷하다고 주장하고 싶습니다.

다른 최적화 단계를 구성하는 것이 위험한 비상 동작을 생성하지 않는다는 것을 증명하는 것이 합리적이라고해도 LLVM 개발자는이를 보존하기 위해 의식적으로 노력하지 않을 것입니다.

글쎄요, LLVM이 이런 방식으로 Rust의 디자인에 영향을 미친다는 것은 불행한 일입니다.하지만 저는 방금 LLVM 명령어 참조 중 일부를 읽었으며 위에서 언급 한 "고정"작업을 언급했습니다 ( "... 또 다른 방법은 LLVM이 고정을 추가 할 때까지 기다리는 것입니다. 개념… ") LLVM 수준에서 정의되지 않은 동작을 방지합니다. 녹이 이전 버전의 LLVM에 연결되어 있습니까? 그렇지 않다면 우리는 그것을 사용할 수 있습니다. 그러나 정확한 동작에 대한 문서는 명확하지 않습니다.

인수가 undef 또는 poison이면 'freeze'는 'ty'유형의 임의의 고정 값을 반환합니다. 그렇지 않으면이 명령어는 작동하지 않으며 입력 인수를 반환합니다. 동일한 '고정'명령에 의해 반환 된 값의 모든 사용은 항상 동일한 값을 준수하도록 보장되지만 다른 '고정'명령은 다른 값을 생성 할 수 있습니다.

"고정 값"또는 "동일한"동결 "명령"이 무엇을 의미하는지 모르겠습니다. 이상적으로는 no-op으로 컴파일하고 예측할 수없는 정수를 제공 할 것이라고 생각하지만 비용이 많이 드는 일을 할 수있는 것처럼 들립니다. 이 동결 작업을 시도한 사람이 있습니까?

글쎄, LLVM이 이런 식으로 녹의 디자인에 영향을 미친 것은 불행한 일입니다.

LLVM 개발자가 최적화 프로그램을 작성하는 것은 아닙니다. rustc 개발자가 옵티 마이저를 작성하더라도 옵티 마이저를 연결하는 새로운 속성으로 인해 정의되지 않은 유혹은 본질적으로 큰 발판입니다. 문제의 반올림이 최적화 단계를 연결하여 생성 된 새로운 행동 일 때 인간의 두뇌는 단순히 "반올림 오류의 잠재적 크기를 직감"하도록 진화하지 않았습니다.

나는 거기에서 당신과 동의하지 않을 것입니다. :-)이 LLVM "고정"명령이이 정의되지 않은 동작을 피할 수있는 제로 비용 방법을 제공하기를 바랍니다.

그것은 위에서 논의되었으며 결론은 캐스팅 후 동결이 정의 된 동작이지만 전혀 합리적인 동작이 아니라는 것입니다. 릴리스 모드에서 이러한 캐스트는 경계를 벗어난 입력 (완전히 안전한 코드)에 대해 임의의 결과를 반환합니다. 그것은 as 처럼 순진 해 보이는 것에 대한 좋은 의미가 아닙니다.

IMO는 그러한 의미론은 우리가 피하고 싶은 나쁜 언어 디자인 일 것입니다.

내 입장은 as 는 입력 및 출력 유형에 따라 크게 다른 의미 (잘림, 채도, 반올림,…)를 가질 수 있기 때문에이 문제와 관계없이 완전히 피하는 것이 가장 좋습니다. 코드 읽기. (후자조차도 foo as _ 으로 추론 할 수 있습니다.) 그래서 저는 as 이 오늘날 수행하는 경우를 포괄하는 다양한 명시 적으로 명명 된 변환 방법을 제안하기위한 사전 RFC 초안을 가지고 있습니다. .

초안 끝났어! https://internals.rust-lang.org/t/pre-rfc-add-explicitly-named-numeric-conversion-apis/11395

모든 피드백을 환영합니다. 그러나 여기보다는 내부 스레드에 알려주십시오.

릴리스 모드에서 이러한 캐스트는 경계를 벗어난 입력 (완전히 안전한 코드)에 대해 임의의 결과를 반환합니다. 그것은 순진한 것처럼 보이는 것에 대한 좋은 의미가 아닙니다.

반복해서 미안하지만 정수 오버플로에도 동일한 주장이 적용된다고 생각합니다. 일부 숫자를 곱하고 결과가 오버플로되면 수행하려는 계산이 거의 확실하게 무효화되는 매우 잘못된 결과를 얻게되지만 디버그 빌드에서 패닉이 발생하여 버그가 잡힐 가능성이 높습니다. 사용자 코드의 버그를 나타낼 가능성이 매우 높기 때문에 매우 잘못된 결과를 제공하는 숫자 변환도 당황해야한다고 말하고 싶습니다. (일반적인 부동 소수점 부정확성의 경우는 이미 처리되어 있습니다. 계산이 65535.3을 생성하는 경우 이미이를 u16으로 변환하는 것이 유효합니다. 범위를 벗어난 변환을 얻으려면 일반적으로 코드에 버그가 필요합니다. 버그를 고칠 수 있도록 알림을 받고 싶습니다.)

릴리스 빌드가 유효하지 않은 변환에 대해 임의적이지만 정의 된 결과를 제공하는 기능은 또한 최대 성능을 허용합니다. 이는 제 생각에 숫자 변환과 같은 기본적인 것에 대해 중요합니다. 항상 포화 상태는 성능에 상당한 영향을 미치고 버그를 숨기며 예기치 않게 올바른 결과를 제공하는 계산을 거의하지 않습니다.

반복해서 미안하지만 정수 오버플로에도 동일한 주장이 적용된다고 생각합니다. 일부 숫자를 곱하고 결과가 오버플로되면 수행하려는 계산을 거의 확실하게 무효화하는 매우 잘못된 결과를 얻게됩니다.

우리는 곱셈에 대해 말하는 것이 아니라 캐스트에 대해 이야기하고 있습니다. 그리고 예, 정수 오버플로에도 동일하게 적용됩니다. int-to-int 캐스트는 오버플로하더라도 패닉이 발생하지 않습니다. 이는 as , 설계 상 디버그 빌드에서도 패닉이 발생하지 않기 때문입니다. 안전하지 않은 코드에 대한 정확성과 안전성은 당황하지 않는 특정 작업에 의존 할 수 있기 때문에 부동 소수점 캐스트를 위해 이것에서 벗어나는 것은 기껏해야 놀랍고 최악의 경우 위험합니다.

as 의 디자인은 올바른 변환이 항상 가능하지 않은 유형간에 오류없는 변환을 제공하기 때문에 결함이 있다고 주장하고 싶다면 우리 대부분이 동의 할 것이라고 생각합니다. 그러나 이것은 as casts의 기존 프레임 워크 내에서 float-to-int 변환을 수정하는이 스레드의 범위를 완전히 벗어났습니다. 이것들은 오류가 없어야하고 디버그 빌드에서도 당황해서는 안됩니다. 따라서 합리적인 ( freeze 포함되지 않음), float-to-int 캐스트에 대한 비 패닉 의미를 제안하거나 패닉을 허용하기 위해 as 재 설계에 대한 새로운 토론을 시작하십시오. 캐스트가 손실 일 때 (그리고 int-to-int 및 float-to-int 캐스트에 대해 일관되게 수행)-후자는이 문제에서 주제를 벗어 났으므로 새 스레드 (RFC 이전 스타일)를여십시오. 그에 대한.

UB를 수정하기 위해 지금 freeze 시맨틱을 구현하는 것으로 시작하면 어떨까요? 그리고 나서 우리가 선택한 모든 시맨틱이 freeze 와 역 호환 될 것이기 때문에 우리가 실제로 원하는 시맨틱에 대해 전 세계에서 항상 동의 할 수 있습니다.

UB를 수정하기 위해 freeze 시맨틱 _now_를 구현하는 것으로 시작하면 어떨까요? 그러면 우리가 선택한 모든 시맨틱이 freeze 와 역 호환 될 것이기 때문에 우리가 실제로 원하는 시맨틱에 대해 전 세계에서 항상 동의 할 수 있습니다.

1. 패닉은 동결과 역 호환되지 않으므로 적어도 패닉과 관련된 모든 제안을 거부해야합니다. UB에서 패닉으로 이동하는 것은 덜 명백하게 호환되지 않지만 위에서 논의했듯이 as 패닉을 일으키지 않는 다른 이유가 있습니다.
2. 내가 전에 썼 듯이 ,
   > 우리는 몇 가지 이전 버전 (현재 LLVM 6으로 돌아 가기)을 지원하며 실제로 모든 사용자에 대해 UB를 제거하려면 대체 구현이 필요합니다.

나는 단지 as 캐스트를 당황하게 만드는 것은 매우 바람직하지 않다는 @RalfJung의 의견에 동의하지만, @admilazz가 만든이 점이 분명히 정확하다고 생각하지 않습니다.

(일반적인 부동 소수점 부정확성의 경우는 이미 처리되어 있습니다. 계산이 65535.3을 생성하는 경우 이미이를 u16으로 변환하는 것이 유효합니다. 범위를 벗어난 변환을 얻으려면 일반적으로 코드에 버그가 필요합니다. 버그를 고칠 수 있도록 알림을 받고 싶습니다.)

f32-> u16의 경우 반올림 오류에서 u16 범위를 벗어나려면 매우 큰 반올림 오류가 필요하지만 f32에서 32 비트 정수로 변환하는 경우에는 그다지 분명하지 않습니다. i32::MAX 는 f32에서 정확하게 표현할 수 없으며 가장 가까운 표현 가능 숫자는 i32::MAX 에서 47 할인입니다. 따라서 수학적으로 최대 i32::MAX 의 수를 산출해야하는 계산이있는 경우 0에서 1 ULP 이상의 오류가 발생하면 범위를 벗어납니다. 그리고 정밀도가 낮은 부동 소수점 (IEEE 754 binary16 또는 비표준 bfloat16)을 고려하면 훨씬 더 나빠집니다.

우리는 곱셈에 대해 말하는 것이 아니라 캐스트에 대해 이야기하고 있습니다.

음, 부동 소수점에서 정수로의 변환은 곱셈과 같은 맥락에서 거의 독점적으로 사용됩니다 : 숫자 계산, 그리고 정수 오버플로의 동작과 유용한 병렬이 있다고 생각합니다.

그리고 예, 정수 오버플로에도 동일하게 적용됩니다. int-to-int 캐스트는 오버플로 되더라도 패닉이 발생하지 않습니다. 당황하지 않는 특정 작업에 의존 할 수 있습니다.

나는 여기에서의 불일치가 일반적인 관행에 의해 정당화되고 그렇게 놀랍지 않을 것이라고 주장합니다. 시프트, 마스크 및 캐스트를 사용하여 정수를 자르고 자르는 작업-비트 AND 형식으로 캐스트를 효과적으로 사용하고 크기 변경을 추가하는 것은 매우 일반적이며 시스템 프로그래밍에서 오랜 역사를 가지고 있습니다. 적어도 일주일에 여러 번하는 일입니다. 그러나 지난 30 년 이상 동안 NaN, Infinity 또는 범위를 벗어난 부동 소수점 값을 정수로 변환하여 합리적인 결과를 기대했던 적이 없었습니다. (내가 기억할 수있는 모든 경우는 값을 생성 한 계산의 버그였습니다.) 따라서 정수-> 정수 캐스트와 부동 소수점-> 정수 캐스트의 경우는 동일하게 처리되어야한다고 생각하지 않습니다. 즉, 일부 결정이 이미 결정된 것을 이해할 수 있습니다.

… float-to-int 캐스트에 대해 합리적이고 (고정을 포함하지 않음) 당황하지 않는 의미론을 제안하십시오.

글쎄요, 제 제안은 :

1. 의미 체계에 중요한 변경 사항을 적용하는 전역 컴파일 스위치를 사용하지 마십시오. (나는 -Zsaturating-float-casts가 명령 줄 매개 변수 또는 유사하다고 가정합니다.) 포화 동작에 의존하는 코드, 예를 들어 그것없이 컴파일하면 깨질 것입니다. 아마도 다른 기대치를 가진 코드는 같은 프로젝트에서 함께 섞일 수 없었을 것입니다. 계산이 원하는 의미를 지정하는 로컬 방법이 있어야합니다. 아마도이 pre-RFC 와 같은 것입니다.
2. as 캐스트가 캐스트에서 예상되는대로 기본적으로 최대 성능을 갖도록합니다.
   
   
   
   • 이를 지원하는 LLVM 버전의 동결과 지원하지 않는 LLVM 버전의 다른 변환 의미 (예 : 잘림, 포화 등)를 통해이 작업을 수행해야한다고 생각합니다. 나는 '고정이 민감한 메모리에서 값을 유출 할 수있다'는 주장이 순전히 가설이라고 생각합니다. (또는 y = freeze(fptosi(x)) 만 y 변경하지 않고 그대로 두어 초기화되지 않은 메모리가 누출되는 경우 먼저 y 를 지워서 해결할 수 있습니다.)
   
   
   • as 가 기본적으로 상대적으로 느리면 (예 : 포화 상태이기 때문에), 최대 성능을 얻을 수있는 방법을 제공하십시오 (예 : 방법-필요한 경우 안전하지 않음-동결을 사용하는 방법).
   
   

1. 의미 체계에 중요한 변경 사항을 적용하는 전역 컴파일 스위치를 사용하지 마십시오. (-Zsaturating-float-casts가 명령 줄 매개 변수 또는 유사하다고 가정합니다.)

분명히 말하면 누구도 동의하지 않는다고 생각합니다. 이 플래그는 라이브러리가 이러한 회귀를 수정하기 위해 업데이트되는 동안 성능 회귀를보다 쉽게 ​​측정하고 해결하기위한 단기 도구로만 제안되었습니다.

f32-> u16의 경우 반올림 오류에서 u16 범위를 벗어나려면 매우 큰 반올림 오류가 필요하지만 f32에서 32 비트 정수로 변환하는 경우에는 그다지 분명하지 않습니다. i32 :: MAX는 f32에서 정확하게 표현할 수 없으며, 가장 가까운 표현 가능한 숫자는 i32 :: MAX에서 47 떨어져 있습니다. 따라서 수학적으로 최대 i32 :: MAX까지의 수를 산출해야하는 계산이있는 경우 0에서 1 ULP를 초과하는 오류는 범위를 벗어납니다.

이것은 약간의 주제에서 벗어 났지만 수학적으로 최대 2 ^ 31-1까지 f32를 생성해야하는 가상 알고리즘이 있다고 가정 해 봅시다 (하지만 반올림 오류로 인한 경우를 제외하고는 2 ^ 31 이상을 생성해서는 안됩니다). 이미 결함이있는 것 같습니다.

1. 가장 가까운 표현 가능한 i32는 실제로 i32 :: MAX보다 127보다 낮다고 생각합니다. 따라서 부동 소수점 부정확성이없는 완벽한 세계에서도 최대 2 ^ 31-1의 값을 생성 할 것으로 예상되는 알고리즘은 실제로 (법적 ) 값은 최대 2 ^ 31-128입니다. 아마도 그것은 이미 버그 일 것입니다. 2 ^ 31-1에서 측정 된 오류에 대해 그 숫자를 표현할 수없는 경우에 대해 이야기하는 것이 합리적 일지 모르겠습니다. 범위를 벗어나려면 가장 가까운 표현 가능한 숫자 (반올림 고려)에서 64만큼 떨어져야합니다. 물론, 당신이 2 ^ 32에 가까워 질 때 퍼센트 현명하지 않습니다.
2. 가장 가까운 표현 가능한 값이 128만큼 떨어져있을 때 1만큼 떨어진 값 (즉, 2 ^ 31-1이지만 2 ^ 31은 아님)의 차별을 기 대해서는 안됩니다. 또한 i32의 3.5 % 만 f32로 표현할 수 있습니다 (및 u32의 2 % 미만). f32로 그런 종류의 정밀도를 가지면서도 그런 종류의 범위를 얻을 수 없습니다. 알고리즘이 작업에 잘못된 도구를 사용하는 것처럼 들립니다.

나는 당신이 설명하는 것을 수행하는 모든 실용적인 알고리즘이 어떻게 든 정수와 밀접하게 연결되어 있다고 생각합니다. 예를 들어, 임의의 i32를 f32로 다시 변환하는 경우 i32 :: MAX-64 이상이면 실패 할 수 있습니다. 그러나 그것은 당신의 정밀도를 심하게 저하시키고 왜 당신이 그런 일을하는지 모르겠습니다. 전체 i32 범위를 출력하는 거의 모든 i32-> f32-> i32 계산은 정수 수학으로 더 빠르고 정확하게 표현할 수 있습니다. 그렇지 않으면 f64가 없습니다.

어쨌든 범위를 벗어난 변환을 수행하는 알고리즘이 포화에 의해 수정되는 경우를 찾을 수 있다고 확신하지만 드물다고 생각합니다. 드물기 때문에이를 수용하기 위해 _all_ 변환 속도를 늦추지 않아야합니다. . 그리고 이러한 알고리즘은 여전히 ​​결함이 있으며 수정해야한다고 주장합니다. 그리고 알고리즘을 수정할 수없는 경우, 가능한 범위를 벗어난 변환 (또는 포화 변환 함수 호출) 전에 항상 범위 검사를 수행 할 수 있습니다. 이렇게하면 결과를 제한하는 비용이 필요한 경우에만 지불됩니다.

추신 : 모두에게 행복한 추수 감사절을 뒤늦게했습니다.

분명히 말하면 누구도 동의하지 않는다고 생각합니다. 이 플래그는 단기간 도구로만 제안되었습니다.

나는 주로 -Zsaturated-float-casts를 -Zunsaturated-float-casts로 대체하라는 제안을 언급했습니다. 채도가 기본값이 되더라도 -Zunsaturated-float-casts와 같은 플래그는 호환성에 좋지 않은 것처럼 보이지만 일시적인 의도라면 괜찮습니다. :-)

어쨌든, 나는 모두가 내가이 문제에 대해 충분히 말했으면 좋겠다고 확신한다. 저는 Rust 팀이 전통적으로 사람들이 성능과 안전성 사이에서 자신의 선택을 할 수 있도록 여러 가지 방법을 제공하려고 노력해 왔음을 알고 있습니다. 저는 여러분들이 결국 좋은 해결책을 내놓을 것이라는 제 관점과 신뢰를 공유했습니다. 조심해!

나는 -Zunsaturated-float-casts 가 일시적으로 만 존재하고 언젠가는 제거 될 것이라고 가정했습니다. 적어도 -C 아니라 -Z 옵션 (Nightly에서만 사용 가능)이라는 점이 제안합니다.

가치가있는 경우 채도와 UB만이 유일한 선택은 아닙니다. 또 다른 가능성은 CPU의 기본 오버플로 동작을 사용하는 fptosi 의 변형을 추가하도록 LLVM을 변경하는 것입니다. 즉, 오버플로 동작은 아키텍처간에 이식 할 수 없지만 주어진 아키텍처에서 잘 정의됩니다 ( 예를 들어 x86에서 0x80000000 반환), 절대로 포이즌이나 초기화되지 않은 메모리를 반환하지 않습니다. 기본값이 포화 상태가 되더라도 옵션으로 사용하면 좋을 것입니다. 결국 포화 캐스트는 기본 동작이 아닌 아키텍처에 내재 된 오버 헤드가있는 반면, "CPU가하는 작업 수행"은 특정 컴파일러 최적화를 금지하는 경우에만 오버 헤드가 있습니다. 확실하지는 않지만 float-to-int 오버플로를 UB로 처리하여 활성화 된 최적화는 틈새 시장이며 대부분의 코드에 적용 할 수 없다고 생각합니다.

즉, 아키텍처에 오버플로시 다른 값을 반환하는 여러 float-to-int 명령어가있는 경우 문제가 될 수 있습니다. 이 경우 하나 또는 다른 하나를 선택하는 컴파일러는 관찰 가능한 동작에 영향을 미치며, 이는 그 자체로는 문제가되지 않지만 단일 fptosi 가 복제되고 두 복사본이 다르게 동작하는 경우 하나가 될 수 있습니다. 그러나 이러한 종류의 차이가 실제로 인기있는 아키텍처에 존재하는지 확실하지 않습니다. 부동 소수점 축소를 포함한 다른 부동 소수점 최적화에도 동일한 문제가 적용됩니다.

const fn (miri)는 Rust 1.26 이후 포화 캐스트 동작을 이미 선택했습니다 (CTFE와 RTFE 결과가 일관되기를 원한다고 가정) (1.26 이전에는 오버플로 컴파일 타임 캐스트가 0을 반환 함)

const fn g(a: f32) -> i32 {
    a as i32
}

const Q: i32 = g(1e+12);

fn main() {
    println!("{}", Q); // always 2147483647
    println!("{}", g(1e+12)); // unspecified value, but always 2147483647 in miri
}

Miri / CTFE는 apfloat의 to_u128 / to_i128 메서드 를 사용하여 변환을 수행합니다. 그러나 이것이 안정적인 보증인지 확실하지 않습니다. 특히 이전에 변경된 것처럼 보였습니다 (미리에서 해당 항목을 구현할 때 알지 못함).

나는 이것을 어떤 코드 젠이 선택하든간에 조정할 수 있다고 생각한다. 그러나 LLVM의 apfloat (Rust 버전이 직접 포트 임)가 채도를 사용한다는 사실은 이것이 일종의 "합리적인 기본값"이라는 좋은 지표입니다.

관찰 가능한 동작에 대한 한 가지 해결책은 컴파일러 또는 결과 바이너리를 빌드 할 때 사용 가능한 메서드 중 하나를 무작위로 선택하는 것입니다.
그런 다음 특정 동작이 필요한 사용자를 위해 a.saturating_cast::<i32>() 와 같은 기능을 사용합니다.

뿡뿡

"무작위"라는 단어는 재현 가능한 빌드를 얻으려는 노력에 반하여 실행되며 컴파일러 버전 내에서 예측할 수있는 경우 누군가 변경되지 않는 것에 의존한다고 결정할

@comex가 설명 한 IMO (이 스레드 IIRC에 새로운 것이 아니며 오래된 모든 것이 다시 새 것입니다) 채도를 원하지 않는 경우 차선책입니다. 이를 테스트하기 위해 LLVM 변경이 필요하지 않습니다. 인라인 asm을 사용할 수 있습니다 (이러한 지침이있는 아키텍처에서).

즉, 아키텍처에 오버플로시 다른 값을 반환하는 여러 float-to-int 명령어가있는 경우 문제가 될 수 있습니다. 이 경우 하나 또는 다른 하나를 선택하는 컴파일러는 관찰 가능한 동작에 영향을 미치며, 이는 그 자체로는 문제가되지 않지만 단일 fptosi 가 복제되고 두 복사본이 다르게 동작하는 경우 하나가 될 수 있습니다.

IMO 이러한 비결정론은 freeze 비해 거의 모든 실질적인 이점을 포기할 것입니다. 이렇게한다면, 우리는 아키텍처 당 하나의 명령어를 선택하고 그것에 충실해야합니다. 두 가지 모두 결정 성을 위해 그리고 프로그램이 실제로 의미가있을 때 명령어의 동작에 의존 할 수 있도록해야합니다. 일부 아키텍처에서 이것이 가능하지 않다면 소프트웨어 구현으로 돌아갈 수 있습니다 (하지만 이것은 전적으로 가설적인 것입니다).

이 결정을 LLVM에 위임하지 않고 대신 인라인 asm을 사용하여 작업을 구현하는 것이 가장 쉽습니다. 부수적으로 LLVM을 변경하여 새로운 내장 함수를 추가하고 모든 백엔드에서 낮추는 것보다 훨씬 쉽습니다.

뿡뿡

[...] 부수적으로 LLVM을 변경하여 모든 백엔드에서 새로운 내장 함수를 추가하고 낮추는 것보다 훨씬 쉽습니다.

또한 LLVM은 대상 종속 의미론을 사용하는 내장 함수에 대해 정확히 만족하지 않습니다.

그러나 캐스트를 잘 정의하려면 해당 동작을 정의해야합니다. "빠른 일을 좀해라"는 실제 정의가 아니고, 나는 우리가 타겟 독립적 구조에 타겟 의존적 행동을 주어야한다고 생각하지 않습니다.

https://groups.google.com/forum/m/#!msg/llvm -dev / cgDFaBmCnDQ / CZAIMj4IBAA

저는 # 10184를 T-lang으로 만 다시 태그를 지정할 것입니다. 해결해야 할 문제에는 float as int 의미에 대한 의미 론적 선택이 있습니다.

(즉, 당황스러운 의미를 갖도록 허용할지 여부, freeze 기반의 과소 명세를 허용할지 여부 등)

이 질문은 최소한 초기 토론 인 IMO에서 T- 컴파일러가 아닌 T-lang 팀을 겨냥한 질문입니다.

다시 컴파일하지 않아도 _ 실행 사이에 재현 할 수없는 _ 결과를 생성하는이 문제가 발생했습니다. as 연산자는 이러한 경우 메모리에서 일부 쓰레기를 가져 오는 것 같습니다.

"float as int"에 대해 as 사용을 완전히 금지하고 대신 특정 반올림 방법에 의존하는 것이 좋습니다. 추론 : as 는 다른 유형에 대해 손실이 없습니다.

추론 : 다른 유형의 경우 손실이 없습니다.

맞나요?

Rust Book을 기반으로 저는 특정 경우 (즉, From<X> 가 유형 Y에 대해 정의 된 경우)에서만 무손실이라고 가정 할 수 있습니다. 즉, u8 를 u32 캐스트 할 수 있습니다 From 를 사용하지만 그 반대는 아닙니다.

"손실이 아님"은 적합 할만큼 작은 값을 캐스팅하는 것을 의미합니다. 예 : 1_u64 as u8 는 손실이 없으므로 u8 as u64 as u8 은 손실이 없습니다. float의 경우 20000000000000000000000000000_u128 as f32 는 손실이없는 반면 20000001_u32 as f32 는 손실이 없으므로 "fits"에 대한 간단한 정의가 없으므로 float as int 도 int as float 도 손실이 없습니다.

256u64 as u8 는 손실이 있습니다.

그러나 <anything>_u8 as u64 as u8 는 그렇지 않습니다.

손실은 정상이며 캐스트에서 예상되는 것이지 문제가 아니라고 생각합니다. 캐스트 (예 : u32 as u8 )를 사용하여 정수를 자르는 것은 제가 알고있는 모든 C와 유사한 언어에서 일관된 잘 이해 된 의미를 가진 일반적인 작업입니다 (적어도 2의 보수 정수 표현을 사용하는 아키텍처에서는 기본적으로 요즘 모두). 유효한 부동 소수점 변환 (즉, 정수 부분이 대상에 맞는 위치)도 잘 이해되고 합의 된 의미 체계를 갖습니다. 1.6 as u32 는 손실이 있지만 결과가 1이어야한다는 데 동의하는 모든 C와 유사한 언어입니다.이 두 경우 모두 이러한 변환이 작동해야하는 방식과 C의 규칙에 대한 하드웨어 제조업체 간의 합의에서 벗어납니다. -캐스트하는 언어는 고성능이어야합니다. "내가하는 일을 알고 있습니다"종류의 연산자.

따라서 유효하지 않은 부동 소수점 변환과 같은 방식으로 문제를 고려해서는 안된다고 생각합니다. C와 유사한 언어 나 하드웨어에서 합의 된 의미가 없기 때문입니다 (하지만 일반적으로 오류 상태가 발생합니다). 또는 하드웨어 예외) 거의 항상 버그 (내 경험상)를 나타내므로 일반적으로 올바른 코드에 존재하지 않습니다.

이 문제가 발생하여 다시 컴파일하지 않아도 실행간에 재현 할 수없는 결과가 생성되었습니다. as 연산자는 이러한 경우 메모리에서 일부 쓰레기를 가져 오는 것 같습니다.

개인적으로 나는 변환이 유효하지 않을 때만 발생하고 가비지 값을 생성하는 것 외에 부작용이없는 한 괜찮다고 생각합니다. 코드 조각에서 유효하지 않은 변환이 정말로 필요하다면, 그것이 가져야한다고 생각하는 의미론으로 유효하지 않은 케이스를 직접 처리 할 수 ​​있습니다.

쓰레기 값을 생성하는 것 외에 부작용이 없습니다.

부작용은 가비지 값이 메모리 어딘가에서 발생하고 일부 (아마도 민감한) 데이터를 드러낸다는 것입니다. float 자체에서만 계산 된 "무작위"값을 반환하는 것은 괜찮지 만 현재 동작은 그렇지 않습니다.

유효한 부동 소수점 변환 (즉, 정수 부분이 대상에 맞는 위치)도 잘 이해되고 합의 된 의미 체계를 갖습니다.

명시 적 trunc() , round() , floor() 또는 ceil() 동반하지 않는 float-int 변환의 사용 사례가 있습니까? as 의 현재 반올림 전략은 "정의되지 않음"이므로 as 반올림되지 않은 숫자에 거의 사용할 수 없습니다. 나는 대부분의 경우 x as u32 를 쓰는 사람이 실제로 x.round() as u32 원한다고 생각합니다.

손실은 정상이며 캐스트에서 예상되는 것이지 문제가 아니라고 생각합니다.

동의하지만 손실을 쉽게 예측할 수있는 경우에만 가능합니다. 정수의 경우 손실 변환 조건이 분명합니다. 수레의 경우 모호합니다. 매우 큰 숫자에 대해서는 무손실이지만 둥근 경우에도 일부 작은 숫자에는 손실이 있습니다. 개인적으로 실수로 손실 변환을 도입하지 않기 위해 손실 및 무손실 변환에 대해 두 개의 다른 연산자를 사용하는 것이 좋지만 손실 여부를 알 수 있다면 한 명의 연산자만으로도 괜찮습니다.

부작용은 가비지 값이 메모리 어딘가에서 발생하고 일부 (아마도 민감한) 데이터를 드러낸다는 것입니다.

나는 그것이 목적지를 변경하지 않고 그대로두기를 기대하지만 그것이 정말로 문제라면 먼저 제로화 될 수 있습니다.

명시 적 trunc (), round (), floor () 또는 ceil ()을 동반하지 않는 float-int 변환의 사용 사례가 있습니까? as 의 현재 반올림 전략은 "정의되지 않음"이므로 반올림되지 않은 숫자에 거의 사용할 수 없습니다.

반올림 전략이 정말로 정의되지 않았다면 그것은 나에게 놀라운 일이며, 이미 정수를 제공하지 않는 한 연산자가 거의 유용하지 않다는 데 동의합니다. 0으로 잘릴 것으로 예상합니다.

나는 대부분의 경우 x as u32 를 쓰는 사람이 실제로 x.round() as u32 원한다고 생각합니다.

나는 그것이 도메인에 달려 있다고 생각하지만 x.trunc() as u32 도 꽤 일반적으로 바람직하다고 생각합니다.

동의하지만 손실을 쉽게 예측할 수있는 경우에만 가능합니다.

나는 확실히 동의합니다. 예를 들어 1.6 as u32 가 1 또는 2가되는지 여부는 정의되지 않아야합니다.

https://doc.rust-lang.org/nightly/reference/expressions/operator-expr.html#type -cast-expressions

float에서 정수로 캐스팅하면 float가 0으로 반올림됩니다.
참고 : 현재 반올림 된 값을 대상 정수 유형으로 나타낼 수없는 경우 정의되지 않은 동작이 발생합니다. 여기에는 Inf 및 NaN이 포함됩니다. 이것은 버그이며 수정 될 것입니다.

메모는 여기에 링크됩니다.

"적합한"값의 반올림은 잘 정의되어 있으며이 문제에 대한 내용이 아닙니다. 이 스레드는 이미 길기 때문에 이미 확립되고 문서화 된 사실에 대한 탄젠트를 추측하지 않는 것이 좋습니다. 감사.

결정해야 할 사항은 다음과 같은 경우 f as $Int 를 정의하는 방법입니다.

• f.trunc() > $Int::MAX (양의 무한대 포함)
• f.trunc() < $Int::MIN (음의 무한대 포함)
• f.is_nan()

-Z saturating-casts 컴파일러 플래그를 사용하여 Nightly에서 이미 구현되고 사용 가능한 한 가지 옵션은 각각 $Int::MAX , $Int::MIN 및 0을 반환하도록 정의하는 것입니다. 그러나 여전히 다른 행동을 선택할 수 있습니다.

내 견해는 행동이 확실히 결정적이어야하고 (예를 들어 당황하지 않고) 정수 값을 반환해야하지만 정확한 값은 그다지 중요하지 않으며 이러한 경우에 관심이있는 사용자는 별도로 제안하는 변환 방법을 사용해야합니다. 추가 : https://internals.rust-lang.org/t/pre-rfc-add-explicitly-named-numeric-conversion-apis/11395

나는 그것이 도메인에 달려 있다고 생각하지만 x.trunc() as u32 도 꽤 일반적으로 바람직하다고 생각합니다.

옳은. 일반적으로 x.anything() as u32 , 대부분 round() 이지만 trunc() , floor() , ceil() 있습니다. 구체적인 반올림 절차를 지정하지 않고 x as u32 만하면 실수 일 가능성이 큽니다.

내 견해는 행동이 확실히 결정적이어야하며 (예를 들어 당황하지 않고) 정수 값을 반환해야하지만 정확한 값은 너무 중요하지 않습니다.

개인적으로 "정의되지 않은"값을 사용해도 괜찮습니다. 단 부동 자 자신에만 의존하지 않고 가장 중요한 것은 관련없는 레지스터 및 메모리 내용을 노출하지 않는 경우입니다.

-Z saturating-casts 컴파일러 플래그를 사용하여 Nightly에서 이미 구현되고 사용 가능한 한 가지 옵션은 각각 $Int::MAX , $Int::MIN 및 0을 반환하도록 정의하는 것입니다. 그러나 여전히 다른 행동을 선택할 수 있습니다.

f.trunc() > $Int::MAX 및 f.trunc() < $Int::MIN 대해 예상되는 동작은 부동 소수점 숫자가 무한 크기의 정수로 변환 된 다음 그 중 가장 낮은 유효 비트가 반환 될 때와 동일합니다 ( 정수 유형의 변환에서와 같이). 기술적으로 이것은 지수에 따라 왼쪽으로 이동 된 유의미한 부분이 될 것입니다 (양수의 경우 음수는 2의 보수에 따라 반전이 필요합니다).

예를 들어 정말 큰 숫자가 0 로 변환 될 것으로 예상합니다.

무한대와 NaN이 무엇으로 변환되는지 정의하는 것이 더 어렵거나 임의적 인 것 같습니다.

WebAssembly는 다음과 같은 의미 체계로 포화 캐스트를 안정화했습니다.

https://github.com/WebAssembly/nontrapping-float-to-int-conversions/blob/master/proposals/nontrapping-float-to-int-conversion/Overview.md#design

@CryZe 그래서 내가 올바르게 읽으면 -Z saturating-casts (그리고 Miri가 이미 구현 한 것)와 일치합니까?

@RalfJung 맞습니다.

멋져요, https://github.com/WebAssembly/testsuite/blob/master/conversions.wast (트랩이 지정된 결과로 대체 됨)를 Miri의 테스트 스위트에 복사합니다. :)

@RalfJung 새로운 포화 변환 연산자에 대한 테스트를 포함하도록 방금 업데이트 된 conversions.wast의 최신 버전으로 업데이트하십시오. 새 연산자는 이름에 "_sat"가 있고 트 랩핑이 없으므로 아무것도 교체 할 필요가 없습니다.

@sunfishcode 업데이트

_sat 테스트는 테스트되는 값의 측면에서 다른가요? (편집 : 값이 동일하다는 의견이 있습니다.) Rust의 포화 형 캐스트의 경우 이러한 값 중 많은 것을 가져와 https://github.com/rust-lang/miri/pull/1321에 추가했습니다

UB intrinsic의 경우 wasm 측의 트랩이 Miri에서 컴파일 실패 테스트가되어야한다고 생각합니다.

입력 값은 모두 동일하지만 _sat 연산자는 트 랩핑 연산자가 예상되는 트랩을 가지고있는 입력에서 예상 출력 값을 갖는다는 점만 다릅니다.

https://github.com/rust-lang/miri/pull/1321 에 Miri (및 Rust CTFE 엔진)에 대한 테스트가 추가되었습니다 rustc -Zmir-opt-level=0 -Zsaturating-float-casts 도 해당 파일의 테스트를 통과하는지 로컬에서 확인했습니다.
이제 Miri에서 확인되지 않은 내장 함수를 구현했습니다 ( https://github.com/rust-lang/miri/pull/1325 참조).

나는 내가 이해 한 현재 상태를 문서화하는 https://github.com/rust-lang/rust/pull/71269#issuecomment -615537137을 게시했으며 PR은 포화 -Z 플래그의 동작을 안정화하기 위해 이동합니다.

이 스레드의 길이를 감안할 때 사람들이 그 댓글에서 내가 놓친 것이 있다고 느끼면 PR에 해설을 지시하거나 사소한 경우 Zulip 또는 Discord (시뮬 라 크럼)에 대해 자유롭게 핑 (ping) 할 수 있습니다. PR 스레드에서 불필요한 소음을 피하기 위해 문제를 해결하십시오.

언어 팀의 누군가가 곧 해당 PR에 대한 FCP 제안을 시작할 것으로 예상하고 병합하면이 문제가 자동으로 종료됩니다. :)

확인 된 전환에 대한 계획이 있습니까? fn i32::checked_from(f64) -> Result<i32, DoesntFit> ?

i32::checked_from(4.5) 반환해야하는지 고려해야합니다.