기준이 최적화될 위험이 있다

묘사

루비의 실현이 점점 강해지면서 기준 IP로 작성된 기준 테스트와 기타 일반적인 마이크로 기준 테스트가 몰래 최적화될 위험이 있다.비전문가로서는 기준 테스트가 곤혹스러운데, 현재 이 문제를 해결하는 유일한 방법은 생성된 기계 코드를 보는 것이다.
문서의 기준 테스트를 예로 들면 다음과 같습니다.

  x.report("addition2") do |times|
    i = 0
    while i < times
      1 + 2
      i += 1
    end
  end

첫 번째 문제는, 여기 기준 테스트의 조작은 운행 시 상수입니다!인라인 캐시, 동적 인라인 및 끊임없는 접기를 통해 우리는 1 + 2를 3로 줄일 수 있고 동적 최적화를 통해 우리는 어떠한 보호도 없이 완성할 수 있다.나는 적어도 오늘 황옥과 송로가 이 점을 해낼 수 있을 것이라고 생각한다. 그리고 Jruby가 새로운 IR를 통해 이 점을 실현할 수 있을 것이라고 나는 확실하지 않다.나도 루비니우스는 확실하지 않아.아마도 미래의 MRI JIT도 이 정도는 할 수 있을 것이다.
두 번째 문제는 전체 순환 자체도 최적화되기 쉽다는 것이다.그것은 부작용도 생기지 않고, 어떤 가치도 생기지 않는다.부작용을 관찰했다고 할 수 있지만 동태를 통해 최적화하거나 보호 장치를 회로에서 들어올리면 회로의 모든 부작용 관찰은 순식간에 발생하고 전체 회로를 한 번씩 모델링할 수 있다.나는 루비의 어떤 실현도 현재 이 순환을 없앨 수 있다고 믿지 않는다. (실천에서는 쉽지 않다.) 그러나 우리는 틀림없이 Truffle에서 그것을 빨리 실현할 것이다.
우리는 무엇을 할 수 있습니까?
문제의 근원은 텍스트 값1과 2이 상수라는 점이다. 컴파일러가 이를 볼 수 있다.컴파일러를 도입해서 알아볼 수 없는 특수 함수를 넣는 게 어때요?만약 우리가 모든 실현을 판 위에 놓을 수 있다고 가정한다면 우리는 Kernel#optimisation_barrier라고 할 수 있다.그러면 코드는 다음과 같습니다.

  x.report("addition2") do |times|
    i = 0
    while i < times
      optimisation_barrier(1) + optimisation_barrier(2)
      i += 1
    end
  end

이것은 첫 번째 문제를 해결했다.순환체가 더 이상 상수가 아니기 때문에, 순환을 제거하는 데 의미가 있습니까?만약 우리가 부작용이 없다고 확신한다면, 우리는 계산을 삭제할 수 있다. 여기는 넘칠 가능성이 없기 때문에 나는 없다고 생각한다.나는 오늘의 균에서 이 점을 실현할 수 있다optimisation_barrier.MRI와 기타 실현에 대해서는 조작할 수 없습니다. 만약 우리가 모든 실현을 실현할 수 없다면, 기준 IP는 그것을 조작할 수 없다고 정의할 수 있습니다. 만약 실현이 제공되지 않는다면.우리도 그것을 단독 보석으로 만들 수 있다.
단점은 기준 테스트를 작성하는 사람이 이 장애물을 어디에 추가해야 하는지 알아야 한다는 것이다. 비록 이것은 MRI에서 불가능하지만, MRI는 그것을 통해 내연을 할 수 없기 때문에 대량의 비용이 증가할 수 있다.
다른 루비 실현자 @headius와 @brixen은 이에 대해 어떻게 생각합니까?우리는 모든 실현 과정에서 이런 장애를 표준화해야 합니까?

토론 #1

나는 이 문제에 흥미가 없다. 왜냐하면 나는 실현된 마이크로 기준 테스트가 아무런 가치가 없다는 것을 발견했기 때문이다.마이크로 기준 테스트와 응용 프로그램 행동 사이에는 유용한 관련이 없습니다.그 밖에 나는 '응용 프로그램 스타일' 기준 테스트에서 거의 쓸모가 없다는 것을 발견했다.
내가 주목하는 것은 실제 응용 프로그램의 성능을 이해하는 데 도움을 주는 도구이다. 메모리 부하, CPU 시간, IO 시간, 합병성 등

토론 #2

. 이것은 비교적 다른 실현 성능이 아니다. 나는 지금까지 이 점을 언급한 적이 없다.
사람들은 동일한 실현에서 서로 다른 루비 방법과 알고리즘의 성능을 비교하기 위해 기준 IP를 사용한다.루비니우스와 JRuby가 점점 복잡해지면서, 우리와 같은 문제점을 발견할 수 있을 것이다. 기준 IP로 작성된 기준이 0으로 최적화될 수 있다는 것이다.
그러나 현재 나는 더 많은 일을 해서 optimisation_barrier가 충분한지 확실하지 않다. 가치 분석을 통해 Truffle는 Fixnum#+의 수신자와 파라미터가 하나의 값만 있다는 것을 발견했기 때문에 상수라고 가정하면 기준은 여전히 최적화되고 있다.
우리가 진정으로 필요로 하는 것은 매번 교체될 때마다 예측할 수 없는 입력을 제공하고, 예를 들어 파일을 쓰는 것과 같은 하드 부작용을 가진 방식으로 출력 값을 사용하는 것이다.

토론 #셋

우선, 사람들은 비교적 다른 실현을 할 수 있기 때문에 나는 이런 상황에 대해 흥미가 없다는 것을 잘 알고 있다.더욱 일반적으로 말하면, 상술한 원인으로 인해 나는 이 문제에 대해 흥미가 없다.

토론 #4

이 라이브러리는 미세한 기준을 위해 설계된 것 같다는 것을 공평하게 지적할 수 있을 것 같다...따라서 만약 이 라이브러리가 여전히 존재한다면, 이를 더욱 정확하거나 신뢰할 수 있도록 개선하는 것을 환영해야 한다.마이크로 기준 표기에 대한 개인적인 관점은 변하지 않을 것이다. 이것은 마이크로 기준 표기 라이브러리라는 사실이다.
그러니까...우리는 일찍이 JRuby에서 마이크로 기준 최적화 문제를 처리해 보았는데, 가장 좋은 답은 줄곧 더 좋은 기준을 작성하는 것이다.까다로운 점은 특정한 기준 테스트를 언제 중단해야 하는지 아는 것이다. 왜냐하면 많은 경우, 우리는 최적화를 측정하여 정상적으로 작동하도록 확보하려고 하기 때문이다.

토론 #5

네, 결과적으로 제 해결 방안이 아무 소용이 없다는 것을 증명했습니다.나는 Truffle optimisation_barrier 에서 기준 테스트 IP를 사용했지만, 컴파일러가 상수를 확정할 수 있기 때문에 기준 테스트의 최적화를 막을 수 없다.이 질문 해줘서 고마워, 크리스.네가 얻은 대답은 네가 말한 내용에 대한 오해에 기초한 것 같다(

토론 #6

이것은 오래된 문제이다.무슨 일이 일어났는지 다시 사람들의 흥미를 끌었습니까?
# 만약 당신의 평론이 제 위의 평론을 가리킨다면 다시 한 번 말씀드리지만 저는 크리스가 직접 저에게 의견을 구했습니다. 저는 의견을 제시했습니다.이 기간 동안 상황은 변하지 않았다.나는 여전히 마이크로 기준에서 어떠한 실용성도 발견하지 못했다.도움이 되었으면 좋겠습니다.나는 지금까지 다른 사람들이 그것들에게서 가치를 찾지 말아야 하거나, 그것들에게서 일을 해서는 안 된다고 말한 적이 없다.다만 나는 그들에게 시간을 쓰지 않을 것이다.