SysV amd64 ABI 문제와 관련하여, 언어 내부 ABI를 SysV가 아닌 다른 것으로 설정할 수 있음. SysV C 호출자에게 노출되지 않는 한, 원하는 호출 규칙을 사용할 수 있음. NeatLang의 차이점은 LLVM 호출 규칙을 변경하는 것보다 훨씬 복잡해 보이며, 저자는 C 프로그램에 일정한 호출 규칙으로 타입을 노출하고자 할 수도 있음.
인수 전달 비용에 대한 이해가 부족한 경우가 많으며, 이에 대해 작성된 글이 유익함. 예를 들어 Google에서는 24바이트 객체를 값으로 전달하는 관행이 프로파일러에 나타나지 않지만 모든 함수에서 비용이 발생함.
x64로 전환할 때, vec3 객체(3xfloat)가 12바이트에서 16바이트로 확장되는 것에 대해 우려하여 그래픽 엔진을 벤치마킹함. 16바이트를 사용하는 것이 8바이트 읽기에 맞춰져 있어 더 빠르다는 것을 발견함. 결과적으로 vec3는 vec4처럼 사용됨. 항상 전체적인 벤치마킹을 수행할 것을 권장함.
레지스터에 미리 로드된 인수가 스택 쓰기보다 성능이 뛰어나며, 스택 조작은 힙 할당된 것보다 더 빠름. 이는 전역 변수가 많은 복잡한 코드가 빠르게 실행되고, 우아한 재귀 함수나 튜플/구조체/리스트 인수가 느린 이유임. 전자는 조밀한 어셈블리 루프로 최적화하기 쉬움.
MSVC에서는 8바이트를 초과하는 구조체가 스택에 전달됨. 이는 이식 가능한 코드에서 의존해선 안 될 ABI 세부 사항임. 그러나 자주 호출되지 않는 함수의 경우에는 너무 스트레스 받지 말고, 자주 호출되는 작은 함수의 경우에는 컴파일러가 코드를 인라인할 수 있도록 하여 레지스터에서 인수를 전달하는 것 이상의 유용한 최적화를 활성화함.
Windows에서 기본 cdecl 호출 규칙을 사용할 때 8바이트보다 큰 구조체는 레지스터에 전달되지 않음.
amd64에서 sysv amd64 ABI를 사용하여 16바이트를 초과하는 구조체를 값으로 전달하고 반환하는 것은 느리지만 코드를 명확하게 만드는 데 종종 가치가 있음. 물론 이 경우에는 해당되지 않지만, 예를 들어 각 C++ 컴파일러, Golang, OCaml, SBCL과 같이 자체 언어 내에서 사용자 정의 ABI를 사용할 수 있음.
C++에서는 비원시 타입은 좋은 이유가 없는 한 참조(또는 필요하다면 포인터)로 전달해야 한다는 경험칙이 있음. 이는 ABI 때문이기도 하고 복사 또는 이동 생성자를 피하기 위함임. 성능 최적화를 원한다면 C++에서 주의를 기울여야 할 지루한 저수준 세부 사항임.
기사는 매우 특수한 벤치마크에 대한 링크를 제공하며, 여기서는 Java(JIT)가 C++보다 빠르고 심지어 Scala보다도 빠름. Julia HO가 무엇이며 왜 그렇게 빠른지, Python과 Pypy 사이의 속도 차이가 크며 Pypy를 사용하지 않을 이유가 있는지, 표준이 되어야 하는지에 대한 의문을 제기함.
제공된 예에서는 호출자에게 영향을 주지 않고 “struct Vector” 매개변수 유형을 “const struct Vector &” 참조로 전달하도록 변경하여 수정할 수 있음. 포인터 버그가 존재하는 많은 C++ 코드가 포인터를 불필요하게 사용했으며, 참조로 전달하는 것이 더 쉽고 안전하게 사용할 수 있었음.
Hacker News 의견