Hacker News 의견

• Java Constraint Solver (Timefold)와 CPython 간의 함수 호출을 위해 FFI를 많이 다루어야 했음

  • FFI의 성능 문제는 주로 호스트 언어와 외국어 간의 통신을 위한 프록시 사용에서 발생함
  • JNI나 새로운 외국 인터페이스를 사용한 직접적인 FFI 호출은 빠르며, Java 메서드를 직접 호출하는 것과 비슷한 속도임
  • 그러나 CPython과 Java의 가비지 컬렉터는 잘 맞지 않아 동기화를 위해 특별한 기술이 필요함
  • JPype나 GraalPy와 같은 프록시를 사용하면 성능 오버헤드가 발생하며, 매개변수와 반환값을 변환해야 하고 추가적인 FFI 호출이 발생할 수 있음
  • CPython 객체를 Java로 전달하면 Java는 CPython 객체에 대한 프록시를 가짐
  • 그 프록시를 다시 CPython으로 전달하면 프록시의 프록시가 생성됨
  • 결과적으로 JPype 프록시는 CPython을 직접 FFI로 호출하는 것보다 1402% 느리고, GraalPy 프록시는 453% 느림
  • 최종적으로 CPython 바이트코드를 Java 바이트코드로 변환하고, 사용된 CPython 클래스에 해당하는 Java 데이터 구조를 생성함
  • 그 결과 프록시를 사용하는 것보다 100배 빠른 성능 향상을 얻음
  • CPython 바이트코드를 변환하거나 읽는 것은 매우 불안정하고 문서화가 부족하며, VM의 여러 특이점 때문에 다른 바이트코드로 직접 매핑하기 어려움
  • 자세한 내용은 블로그 게시물을 참조할 수 있음: 링크

• Rails At Scale과 byroot의 블로그 덕분에 현재 Ruby 내부와 성능에 대한 심도 있는 논의에 관심을 가지기에 좋은 시기임

  • 최근 Ruby와 Rails의 개선 덕분에 Rubyist로서 좋은 시기임

• 외부 함수 호출을 위해 3rd party 라이브러리를 호출하는 대신 코드를 JIT 컴파일할 수 있는지에 대한 질문

  • LuaJIT FFI의 기본 원리라고 확신함: 링크
  • LuaJIT의 FFI가 매우 빠른 이유라고 생각함

• JVMCI를 사용하여 arm64/amd64 코드를 즉석에서 생성하여 JNI 없이 네이티브 라이브러리를 호출하는 라이브러리 관련 정보: 링크

• "가능한 한 많은 Ruby를 작성하라, 특히 YJIT가 Ruby 코드는 최적화할 수 있지만 C 코드는 그렇지 않기 때문"이라는 의견

  • Ruby가 꽤 느린 언어가 아닌가 하는 의문
  • 네이티브로 들어간다면 가능한 한 많은 작업을 네이티브에서 하고 싶음

• 10년 이상 Ruby를 사용해왔고, 최근의 발전을 보는 것이 매우 흥미로움

  • 기대됨

• 왜 JIT 컴파일이 필요한지에 대한 의문

  • C로 작성할 수 있다면 로드 시점에 컴파일할 수 있지 않을까 하는 생각

• FFI - Foreign Function Interface, 즉 Ruby에서 C를 호출하는 방법

• 이것이 바로 libffi가 하는 일 아닌가 하는 질문

• tenderlovemaking.com으로 가지 않은 이유를 알 것 같음