한 언어를 사용하여 구축 된 응용 프로그램의 런타임 성능과 관련하여 많은 비교 연구가 있으며 온라인으로 제공됩니다. 일부는 기업, 일부는 학술, 일부는 개인 실험 보고서에 의해 주도됩니다.

우리는 또한 다음과 같이 프로그래밍 언어와 툴링의 부작용에 대한 비교 연구를 꽤 많이 얻습니다.

• 빌드 시간
• 후반 작업 버그 탐지 가능성
• 표현력
• 기타...

그러나 최근에는 다른 프로그램보다 프로그램의 메모리 소비로 인해 점점 더 많은 시간이 흐르고 있습니다. 이것은 무어의 법칙이 성능 향상을 위해 우리 편에 있지만 다른 병목 현상이 더 중요하다는 사실을 깨닫게되었을 수도 있습니다. 즉, 하드웨어를 자주 업데이트하지 않는 경향이 있으며 오늘날에는 큰 응용 프로그램 없이는 사용할 수없는 "오래된"(4GB RAM의 2005-2006 3.6GHz Pentium 4 읽기) 기능이 있습니다. 모든 주스를 짜내는 데 큰 어려움을 겪어야했습니다 (OS, UI, 서비스 및 데몬 선택, 작업 또는 다른 응용 프로그램에 사용할 응용 프로그램 선택). 솔직히 말해서 때때로 나는 가장 결백 한 프로그램들이 사용하는 기억이 보이는 곳에서 일어나 top거나 procexp울었 습니다 .

나는 위에 나열된 방향으로 계속 나아가고 본질적으로 자신과 내가 사용하는 프로그램을 제한하려고 노력 하여이 문제를 해결할 수 있지만 (그러한 이유로 CLI 프로그램에 대한 사랑이 있습니다.) 어쩌면 우리가 잘못하고있을 수도 있습니다.

현대적인 요구를위한 최신 도구

물론, 더 높은 수준의 언어는 틀림없이 더 좋고 그들의 무게를 정당화 할 수 있습니다. 많은 툴체인에서 당시에 좋은 (또는 의도가 좋은) 이유로 일부 디자인을 선택했습니다. 공유 라이브러리, 메모리 모델, 전 처리기, 유형 시스템 등 ... 그러나 일부는 현대 하드웨어를 사용하는 다른 것보다 더 실행 가능할 수 있으며이 문제에 대한 몇 가지 진지한 연구를 읽고 싶습니다.

내 질문은 벤치 마크 게임 과 언어의 기본 런타임 메모리 소비 비교에 중점을 둔 다른 사람들 에게 펜던트가 있습니까?

그리고 더욱, 일부 연구는 (것과 유사한 다른 매개 변수와 함께이 교차 - 참조하는지가 이 문서가 , 예를 들어, 다른 기준을 위해, 또한 기반으로 한 벤치 마크 게임 )?

^{부분 정보를 찾았으므로 결과를 내 자신의 답변으로 컴파일하기 시작합니다. 자신의 답변에 기여하거나이 답변을 수정하지 못하게하십시오.}

기존 문헌 :

• 7 가지 프로그래밍 언어의 경험적 비교 -Prechelt (2000) [ PDF ]

  약간 날짜가 있지만 관심있는 자료 중 일부를 다루며 런타임 메모리 사용 및 표현력을 보여줍니다. 지금은 결과가 크게 다를 수 있지만 흥미로운 시작입니다.

• 프로그래밍 언어의 속도, 크기 및 종속성 -Marceau (2009) [ 블로그 ]

• 벤치 마크 게임 에서 사용한 코드, 시간 사용 된 모양 [ u32 , u32q , u64 , u64q ]

  런타임 메모리 소비를 다루지는 않지만 Marceau의 작업은 내용과 품질면에서 해당 기준에 대해 기꺼이 찾을 수있는 일종의 참조 또는 경험적 연구입니다. 다른 메트릭스에 대해서만 내가 좋아하는 것에 대한 좋은 예입니다. 두 번째 기사는 Benchmarks Game 사이트에서 발견 된 후속 기사이며, 런타임 메모리 세부 정보는 없지만 최신 화면과 더 많은 언어로 Marceau의 작업 직후에 게시되었습니다. 언어에 대한 언어 비교에 다음이 페이지 리드에 각 그래프 할 수는 있지만 높은 수준의 메모리 정보를 제공합니다.

이것은 당연히 질문에 대답하는 것이 아니라, 관점을 조금 바꿔 놓을 수도 있습니다. 나는 많은 표결의 대상이 될이 답변 의견의 어조를 설정하기 위해 대화의 대화 내용을 염두에두고 있습니다.

효율성을 염려하는 사람, 하드웨어 공급자, 도구 공급자 및 프로그래머가 있습니다. 당분간은 그들과 우리 모두에게 점점 더 큰 관심사가 될 것입니다. 이러한 우려는 모바일 기기, 특히 가장 큰 화면과 가장 강한 라디오를 갖춘 고성능 배터리 고 블링 몬스터에 뿌리를두고 있습니다.

한 걸음 물러나게하려면, 오늘날 우리가 처한 상황에 처한 이유 중 일부는 비교적 방대한 프레임 워크이며, 하드웨어 개선을 넘어서는 일반적인 효율성에 대한 약간의 무시는 레거시입니다. 레거시 시스템과의 호환성은 호환성을 넘어 호환성을 제공합니다. 본질적으로 다른 런타임 환경 (예 : Xbox, Windows mobile pre 7 / 8 / surface, Java 마이크로 프레임 워크)에서 사용될 때 상당히 효율적이고 성능을 발휘하는 동일한 런타임이기 때문에 최상위 런타임의 결함은 그리 크지 않습니다. 등).

데스크톱이 기존 소프트웨어와의 호환성 정도와 모바일 장치의 호환성 정도를 비교하십시오.

모바일 장치를 사용하여 장치 생산자는 일부 호환성을 보장하기 위해 노력하지만 호환성을 핵심 기본 요소로 만들지 않았습니다. 호환성을 계속 제공하고 모바일 시스템의 디자인을 앞으로 이동시키는 것이 선택되면, 모바일 시스템은 앞으로 나아갑니다.

데스크탑의 경우 그 반대가 사실입니다. 중대한 변화가 마케팅 담당자 나 얼리 어답터에게 잘못 타격을 가하면 필요한 기능과 재 설계가 여러 차례 뒷방으로 밀려납니다. 어느 시점에서 저는 Windows 사용자가 Windows XP를 사용하여 완전히 새로운 파일 시스템을 찾은 후 Vista에서 나중에 7과 동일하고 마지막으로 다시 8에서 다시 완전히 증가한다는 효과에 대한 소문을 기억합니다. 우리는 먼저 Windows2000에서 그것을 보았습니까? 새로운 파일 시스템은 오랫동안 앉아 있었고 폐기되었지만 소문으로 그 이야기를 결정합니다. 그것은 아마도 가장 큰 알려진 사례이지만, 그것이 유일한 큰 사례는 아니라고 긍정적입니다.

가장 최근의 태블릿 및 모바일 OS에서도 한 번 시장을 형성 한 Microsoft는 이제 소비자뿐만 아니라 데스크톱 부서의 그림자와도 얽매이지 않습니다. 태블릿은 데스크톱과의 상호 운용성이 있어야했습니다. 아니요. 아키텍처의 차이로 인해 완벽하게 재생할 수는 없었지만 데스크톱 기반의 고풍 적 특성으로 인해 큰 희생을 겪었습니다.

확실히, Windows는이 상황에 대한 모든 종류의 비판의 대상이되기 쉽지만 다른 플랫폼은 "죄송합니다". 리눅스 생태계에 숨어있는 유물이 많이있어 체계적인 개선을 위해 큰 충격을 받게 될 것입니다.

경제학은이 방정식에 큰 역할을합니다. 컴퓨팅과 애플리케이션의 자금 조달 방식과 다른 방식의 금융 지원 방식은 놀라 울 정도로 다른 패턴을 따릅니다. Wintel이 한때 노후화에 큰 영향을 미쳤던 Apple과 Google은이를 거의 엄격한 일정으로 전환했습니다. 이것은 내가 의도 한 것보다 더 멀리 떨어져 있기 때문에 자리에 앉아 독자들이 거기에서 가져갈 수 있도록 할 것입니다.

대규모 공급 업체가 더 이상 사용되지 않는 가격 책정 모델을 변경하면 더 큰 비율로 더 큰 규모의 변경으로 발전 할 수 있습니다. 최상위 언어로 구동되는 최상위 프레임 워크는 비효율적 인 중간 호환성과 하위 계층이 있기 때문에보다 낮은 수준의 효율성으로 높은 수준의 작업을 수행 할 수 있으므로 축소됩니다. 제거하지 않으면 크게 줄어 듭니다.