프로그래밍의 메모리 관리가 관련이없는 문제입니까?

배경
나는 오랜 세월 동안 간 적이 없었던 오래된 (그러나 위대한) 사이트 인 Alioth Language Shootout ( http://benchmarksgame.alioth.debian.org/ )을 다시 방문했습니다 .

몇 년 전에 C / C ++로 프로그래밍을 시작했지만 그 이후로 내가 관여 한 프로젝트의 언어 제약으로 인해 거의 독점적으로 Java로 작업 해 왔습니다. 그림을 기억하지 못하고 대략 Java가 얼마나 잘되는지보고 싶었습니다. 리소스 사용 측면에서 C / C ++에 반대했습니다.

실행 시간이 느린 C / C ++에 비해 4 배를 수행하는 최악의 자바, 여전히 상대적으로 좋은,하지만 평균 주위에 (또는 아래) 배. Java 구현 자체의 특성으로 인해 이것은 놀라운 일이 아니며 성능 시간은 실제로 예상보다 낮았 습니다.

실제 벽돌은 메모리 할당 이었습니다. 최악의 경우 Java가 할당했습니다.

• C보다 52 배 더 많은 메모리
• C ++보다 25 배 더 많습니다.

52 배의 기억력 ... 절대적으로 불쾌한가? ... 아니면? 메모리는 현재 비교적 저렴합니다.

질문 :
작업 메모리 (예 : 임베디드 시스템 등)에 대한 엄격한 제한이있는 대상 플랫폼 측면에서 말하지 않는다면 오늘날 범용 언어를 선택할 때 메모리 사용이 문제가되어야합니까?

스칼라로의 이주를 기본 언어로 고려하고 있기 때문에 부분적으로 묻습니다. 나는 그것의 기능적 측면을 매우 좋아하지만, 내가 볼 수있는 것보다 Java보다 메모리면에서 훨씬 비쌉니다. 그러나 메모리가 올해 더 빠르면서 저렴하고 풍부 해짐에 따라 (최소 4GB의 DDR3 RAM이없는 소비자 랩톱을 찾는 것이 점점 어려워지고 있음) 리소스 관리가 점점 더 많아지고 있다고 주장 할 수 없었습니다 더 읽기 쉬운 솔루션을보다 빠르게 구성 할 수있는 고급 언어 기능 (구현 적으로 비용이 많이 드는)과 비교하여 관련이 없습니까?

메모리 관리는 메모리에 많은 양의 메모리가 있어도 얼마나 빨리 나타나는지 관리하므로 완전히 관련이 있습니다. Call of Duty 또는 Bioshock과 같은 AAA 타이틀 게임이 가장 좋고 가장 대표적인 예입니다. 이들은 최적화 및 사용 측면에서 방대한 양의 제어가 필요한 실시간 응용 프로그램입니다. 사용 자체가 문제가 아니라 관리입니다.

가비지 콜렉션이라는 두 단어로 나뉩니다. 가비지 수집 알고리즘으로 인해 성능이 약간 저하되거나 응용 프로그램이 1-2 초 동안 중단 될 수 있습니다. 회계 앱에서는 대부분 무해하지만 Call of Duty 게임에서 사용자 경험 측면에서 파괴적 일 수 있습니다. 따라서 시간이 중요한 응용 프로그램에서 가비지 수집 언어는 큰 문제가 될 수 있습니다. 예를 들어 Squirrel의 디자인 목표 중 하나이며, 대신 Lua가 참조 카운트를 사용하여 GC와 관련된 문제를 해결하려고합니다.

두통이 더 있습니까? 물론 정확한 제어가 필요하다면이를 따라야합니다.

실제 브릭은 메모리 할당이었습니다. 최악의 경우 Java는 C보다 52 배 많은 메모리를, C ++보다 25 배 더 많은 메모리를 할당했습니다.

당신은 당신 의 질문에 근거한 숫자 를 이해 합니까?

• 얼마나 많은 메모리가 할당 되었습니까?
• 프로그램은 무엇을하고 있었습니까?

Java와 C 프로그램 사이에 큰 차이가있는 경우 libc에 필요한 것보다 대부분 기본 JVM 메모리 할당입니다 .

• n-body
  Java 프로그램 13,996KB :: C 프로그램 320KB :: 무료 파스칼 8KB

메모리 를 할당 해야하는 작업을 살펴보십시오 (또는 추가 버퍼를 사용하여 멀티 코어 프로그램에서 결과를 누적).

• 만델 브로
  자바 프로그램 67 , 8백80킬로바이트 :: C 프로그램 (30) , 444킬로바이트

• K 뉴클레오티드
  자바 프로그램 (494) , 프로그램 C :: 040킬로바이트 153 , 4백52킬로바이트

• 역 보완
  자바 프로그램 (511) , 484킬로바이트 :: C 프로그램 (248) , 632킬로바이트을

• 정규식-DNA
  자바 프로그램 (557) , 080킬로바이트 :: C 프로그램 289 , 088킬로바이트

• 진 나무
  자바 프로그램 (506) , 5백92킬로바이트 :: C 프로그램 99 , 4백48킬로바이트

... 오늘 범용 언어를 선택할 때 메모리 사용이 문제가됩니까?

해결 해야 할 특정 문제 를 해결하기위한 특정 접근 방식 의 특정 사용량 이 사용될 특정 플랫폼 에서 사용 가능한 메모리 의 특정 한계에 의해 제한 되는지 여부에 따라 다릅니다 .

모든 것과 마찬가지로 절충입니다.

단일 사용자 데스크톱에서 실행될 응용 프로그램을 빌드하고 해당 컴퓨터에서 많은 양의 RAM을 제어 할 것으로 예상되는 경우 구현 속도를 위해 메모리 사용을 희생하는 것이 좋습니다. 동일한 머신을 목표로하고 있지만 동시에 실행되는 많은 메모리 부족 애플리케이션과 경쟁 할 작은 유틸리티를 구축하는 경우 해당 트레이드 오프에 대해 더 신중해야 할 수 있습니다. 세계 엔지니어가 지적한 것처럼, 실행 중일 때 모든 메모리를 원하는 게임을 사용하는 것이 좋습니다. 가비지 수집기에서 스윕을 수행하기 위해 주기적으로 작업을 일시 중지하기로 결정하는 경우 염려 될 것입니다. 일하는 능력을 방해합니다. 웹 기반 응용 프로그램을 구축하는 경우 서버에서 사용하는 모든 메모리는 동일한 사용자 집합을 지원하기 위해 더 많은 응용 프로그램 서버에 더 많은 돈을 쓰도록 확장 할 수있는 능력을 제한합니다. 그것은 회사의 경제에 큰 영향을 줄 수 있으므로 그 절충에 대해 매우 신중해야 할 것입니다. 서버에서 사용하는 모든 메모리는 동일한 사용자 집합을 지원하기 위해 더 많은 응용 프로그램 서버에 더 많은 돈을 쓰도록 확장 할 수있는 능력을 제한합니다. 그것은 회사의 경제에 큰 영향을 줄 수 있으므로 그 절충에 대해 매우 신중해야 할 것입니다. 서버에서 사용하는 모든 메모리는 동일한 사용자 집합을 지원하기 위해 더 많은 응용 프로그램 서버에 더 많은 돈을 쓰도록 확장 할 수있는 능력을 제한합니다. 그것은 회사의 경제에 큰 영향을 줄 수 있으므로 그 절충에 대해 매우 신중해야 할 것입니다.

여러 요인, 특히 작업중인 규모에 따라 다릅니다.

논쟁의 여지가 있기 때문에 메모리가 30 배, CPU 사용량이 2 배라고 가정 해 봅시다.

C로 작성된 경우 10 메가 바이트의 메모리와 1 밀리 초의 CPU를 필요로하는 대화식 프로그램을 다루는 경우 300 메가 바이트의 메모리와 2 밀리 초의 실행 시간은 일반적으로 일반적인 데스크톱에서는 전혀 관련이 없습니다. 휴대 전화 나 태블릿에서도 큰 의미는 없습니다.

서버 1 대당 절반의 리소스와 15 대의 서버가 필요한 차이는 훨씬 더 큰 단계입니다. 특히 15 대의 서버로 확장 하려면 개발 하는 데 많은 추가 작업이 필요하지 않기 때문에 더욱 그렇습니다 . 향후 확장이 진행되는 한 고객 기반이 크게 성장 하지 않는 한 지금 하나의 서버에서 실행될 경우 해당 서버를 능가 할 가능성이 매우 높다는 것을 언급하는 것과 동일한 요인이 제시 됩니다. 문제없이 하나의 최신 서버로 교체 할 수 있습니다.

실제로 고려해야 할 다른 요소는 특정 작업에 대해 개발 비용의 차이가 얼마나 큰지입니다. 지금, 당신은 기본적으로 방정식의 한쪽을보고 있습니다. 비용 대 혜택에 대한 좋은 아이디어를 얻으려면, 비용과 혜택을 모두 혼자서 살펴보아야합니다. 실제 질문은 기본적으로 "x는 y보다 큽니까?"입니다. -하지만 x 만 보아도 확인할 수 없습니다. y도 분명히 봐야합니다.

메모리 관리는 오늘날 세계에서 절대적으로 관련이 있습니다. 그러나 당신이 기대할 수있는 방식이 아닙니다. 가비지 수집 언어에서도 참조 누출이 없는지 확인해야합니다.

이것이 코드 인 경우 잘못된 일을하고 있습니다.

static List<string> Cache;

...
Cache.Add(foo); //and then never remove anything from Cache

가비지 콜렉션은 다시 참조 할 수없는 경우가 아니라면 다시 참조를 사용하지 않는 한 절대로 다시는 참조를 사용하지 않을 것이라는 것을 마술처럼 알 수 없습니다 . 즉 Cache=null, 가비지 컬렉터에게 "이봐 요. 더 이상 액세스 할 수 있습니다.

그보다 더 복잡하지만 참조 누출은 기존 메모리 누출보다 해롭지는 않습니다.

가비지 수집기를 넣을 수없는 곳도 있습니다. 예를 들어, ATTiny84는 512 바이트의 코드 ROM과 32 바이트의 RAM을 가진 마이크로 컨트롤러입니다. 행운을 빕니다! 그것은 극단적이며, 아마도 조립 이외의 것으로 프로그래밍되지는 않지만 여전히 프로그램 화 될 것입니다. 다른 경우에는 1M의 메모리가있을 수 있습니다. 물론 가비지 수집기를 장착 할 수는 있지만 프로세서가 제한 속도 나 배터리를 유지하기 위해 매우 느린 경우 가비지 수집기를 사용하지 않으려는 경우 프로그래머 가 알 수 있는 내용을 추적하는 데 너무 많은 비용이 발생합니다. .

응답 시간이 보장되어야 할 때 가비지 수집을 사용하기가 훨씬 어려워집니다. 예를 들어, 심장 모니터 또는 무언가가 있고 1일부 포트에서 수신되는 경우 10ms 이내에 적절한 신호 또는 무언가로 응답 할 수 있는지 확인해야합니다. 응답 루틴 중간에 가비지 콜렉터가 통과해야하고 응답하는 데 100ms가 걸리면 누군가 죽었을 수 있습니다. 타이밍 요구 사항을 보장해야 할 때 가비지 수집은 불가능하지는 않지만 사용하기가 매우 어렵습니다.

물론 최신 하드웨어에서도 가비지 수집기의 오버 헤드에 대해 걱정하지 않고 2 %의 추가 성능이 필요한 경우가 있습니다.

Donald Knuth가 말했듯이 조기 최적화는 모든 악의 근원입니다. 메모리가 병목 현상이 발생한다고 믿을만한 이유가 없다면 걱정하지 마십시오. 그리고 무어의 법칙에 따라 메모리 용량이 계속 증가하고 있지만 (더 빠른 단일 스레드 코드를 얻지 못하더라도) 미래에 우리가 메모리보다 제약이 적을 것이라고 믿는 모든 이유가 있습니다. 오늘입니다.

즉, 최적화가 조기에 이루어지지 않으면 반드시 그렇게하십시오. 나는 개인적으로 메모리 사용을 매우 자세하게 이해하는 프로젝트를 진행하고 있으며 실제로 정확한 제어가 필요하며 쓰레기 청소가 나를 죽일 것입니다. 따라서 C ++에서이 프로젝트를 수행하고 있습니다. 그러나 그 선택은 몇 년에 한 번 내 사건으로 보입니다. (몇 주 동안 몇 년 동안 C ++을 다시 만지지 않을 것입니다.)

"빅 데이터"를 다루는 사람들에게 메모리 관리는 여전히 큰 문제입니다. 천문학, 물리학, 생물 정보학, 기계 학습 등의 프로그램은 모두 멀티 기가 바이트 데이터 세트를 처리해야하며 관련 부분을 메모리에 보관할 수 있으면 프로그램이 훨씬 빠르게 실행됩니다. RAM이 128GB 인 컴퓨터에서 실행해도 문제가 해결되지 않습니다.

GPU를 활용하는 문제도 있지만 임베디드 시스템으로 분류 할 수도 있습니다. CUDA 또는 OpenCL 사용에 대한 대부분의 어려운 생각은 주 메모리에서 GPU 메모리로 데이터를 전송할 때 메모리 관리 문제로 귀결됩니다.

공평하게 말하면, 많은 Java가 성능을 떨어 뜨리고 메모리를 낭비하는 진정한 폭발성과 무의미한 클래스 폭발성 패턴에 빠지지만 그 메모리 중 얼마나 많은 것이 JVM인지 궁금합니다.이 이론적으로 (heh) 새로운 환경을 완전히 다시 작성할 필요없이 여러 환경에서 동일한 앱을 사용할 수 있습니다. 따라서 디자인 트레이드 오프 문제는 다음과 같이 요약된다.

이것은 IMO가 고려할 가치가 있고 합리적입니다. 현대 PC가 너무 강력하고 메모리가 너무 저렴하기 때문에 그러한 우려와 부풀림 기능 및 부풀어 오른 코드를 완전히 무시하고 많은 것들처럼 보일 수있는 선택에 대해 게으름을 줄 수 있다는 개념입니다. 지금은 Windows PC에서 작업하고 Window '95에서와 같은 시간이 걸립니다. 그래도 진심으로, Word? 18 년 만에 사용자 기반의 80 %가 실제로 필요로하는 새로운 쓰레기 수는 얼마입니까? 창문 미리 맞춤법 검사가 제대로 되었습니까? 그러나 우리는 당신이 그것을 많이 가지고 있다면 필연적으로 속도가 아닌 메모리를 말하고 있었기 때문에 나는 탈선했습니다.

그러나 2 주가 아니라 2 년이 아닌 몇 메가 바이트의 비용으로 2 주 안에 앱을 완성 할 수 있다면 K 만 필요한 버전을 얻는 것이 좋습니다. 나는 추측한다) 평균 사용자 컴퓨터에서 4-12 기가 너무 부주의하다는 생각을 비웃기 전에.

그러나 이것은 트레이드 오프 문제를 넘어 스칼라와 어떤 관련이 있습니까? 가비지 수집이기 때문에 범위와 클로저에 무엇이 있는지, 데이터를 그대로 두어야하는지, 아니면 그대로 두어야하는지에 대한 관점에서 데이터 흐름을 항상 생각해서는 안되는 것은 아닙니다. 더 이상 필요하지 않을 때 GC에 의해 할당 해제됩니다. 그것은 우리조차도 JavaScript UI 웹 개발자가 perf에 정통한 암과 같은 다른 문제 영역으로 퍼짐에 따라 생각해야 할 것이며 계속 희망적으로 계속 될 것입니다. 우리는

프로그래밍의 메모리 관리가 관련이없는 문제입니까?

메모리 관리 (또는 제어)는 실제로 C 및 C ++를 사용하는 주요 이유입니다.

메모리는 현재 비교적 저렴합니다.

빠른 메모리가 아닙니다. 우리는 여전히 i7의 L1에 32KB 데이터 캐시, L2에 256KB, L3 / 코어에 2MB와 같은 소수의 레지스터를보고 있습니다. 그것은 말했다 :

작업 메모리 (예 : 임베디드 시스템 등)에 대한 엄격한 제한이있는 대상 플랫폼으로 말하지 않는다면 오늘날 범용 언어를 선택할 때 메모리 사용이 문제가되어야합니까?

일반적인 수준의 메모리 사용은 아닐 수도 있습니다. 나는 여분의 공간이 풍부하고 더 풍부해야하지만, 50MB의 DRAM과 수백 MB의 하드 디스크 공간을 필요로하는 메모장을 좋아하지 않는다는 점에서 약간 비현실적이다. 나는 오랫동안 주변에 있었고, 그런 간단한 응용 프로그램이 킬로 바이트로 할 수있는 것에 대해 너무 많은 메모리를 차지한다는 것을 알기 위해 이상하고 이상한 느낌이 들었습니다. 즉, 여전히 멋지고 반응이 좋으면 그런 일이 생기면 나와 함께 살 수있을 것입니다.

내 분야에서 메모리 관리가 중요한 이유는 일반적으로 메모리 사용량을 크게 줄이지 않기 때문입니다. 수백 메가 바이트의 메모리 사용은 메모리에 자주 액세스하지 않는 경우 사소한 방식으로 응용 프로그램 속도를 늦추지 않습니다 (예 : 버튼 클릭 또는 다른 형태의 사용자 입력시에만 가능합니다. 버튼을 초당 백만 번 클릭 할 수있는 한국 스타 크래프트 플레이어에 대해 이야기하고 있습니다).

내 분야에서 중요한 이유 는 중요한 경로에서 매우 자주 액세스되는 (예 : 모든 단일 프레임에서 반복되는) 메모리를 단단히 고정 시키는 것입니다. 단일 프레임마다 루프로 액세스해야하는 백만 개의 요소 중 하나에 만 액세스 할 때마다 캐시 미스를 원하지 않습니다. 64 바이트 캐시 라인과 같이 큰 청크에서 느린 메모리에서 빠른 메모리로 계층 구조 아래로 메모리를 이동할 때 64 바이트에 여러 요소의 데이터를 넣을 수 있다면 64 바이트에 모두 관련 데이터가 포함되어 있으면 정말 유용합니다. 액세스 패턴이 데이터를 제거하기 전에 모두 사용하도록되어있는 경우.

수백만 개의 요소에 대해 자주 액세스하는 데이터는 기가 바이트이지만 20MB에 불과할 수 있습니다. 메모리가 빡빡하고 서로 가까이 있으면 캐시 미스를 최소화하면 메모리를 관리하고 제어하는 ​​것이 유용한 경우 프레임 당 반복되는 프레임 속도 차이가 여전히 발생합니다. 몇 백만 개의 정점이있는 구의 간단한 시각적 예 :

위의 내용은 메쉬의 지속적인 데이터 구조 표현을 테스트하기 때문에 실제로 변경 가능한 버전보다 느립니다. 그러나 그 점을 제외하고는 데이터의 절반에서도 프레임 속도를 달성하는 데 어려움을 겪었습니다. ) 캐시 누락을 최소화하고 메쉬 데이터에 메모리를 사용하지 않기 때문입니다. 메쉬는 다각형, 가장자리, 꼭짓점, 사용자가 연결하고자하는 텍스처 맵, 뼈 무게 등 많은 상호 의존 데이터를 저장하기 때문에 이와 관련하여 다루기 어려운 까다로운 데이터 구조 중 일부입니다. 컬러 맵, 선택 세트, 모프 타깃, 엣지 웨이트, 폴리곤 머티리얼 등

지난 수십 년 동안 많은 메쉬 시스템을 설계하고 구현했으며 속도는 종종 메모리 사용에 매우 비례했습니다. 내가 작업했을 때보 다 훨씬 많은 메모리를 사용하고 있지만 새로운 메쉬 시스템은 첫 번째 디자인 (거의 20 년 전)보다 10 배 이상 빠르며 약 1/10의 기억. 최신 버전은 인덱싱 된 압축을 사용하여 가능한 한 많은 데이터를 크램 핑하고 압축 해제의 처리 오버 헤드에도 불구하고 압축은 실제로 성능이 향상되었으므로 다시는 귀중한 빠른 메모리가 거의 없기 때문입니다. 이제 텍스처 좌표, 가장자리 주름, 재료 할당 등을위한 백만 개의 다각형 메쉬를 약 30MB의 공간 인덱스와 함께 맞출 수 있습니다.

다음은 GF 8400이있는 i3에 8 백만 개가 넘는 사변형과 다중 분할 세분화 방식이있는 변경 가능한 프로토 타입입니다 (몇 년 전). 불변 버전보다 빠르지 만 불변 버전을 유지 관리하기가 훨씬 쉽고 성능 적중이 나쁘지 않기 때문에 프로덕션에는 사용되지 않습니다. 와이어 프레임은 패싯을 나타내지 않지만 패싯의 모든 점은 브러시로 수정되지만 패치 (와이어는 실제로 곡선이며, 그렇지 않으면 전체 메시는 검은 색임)를 나타냅니다.

어쨌든, 나는 메모리 관리가 매우 도움이되고 또한 사람들이 내가 내 엉덩이에서 말하고 있다고 생각하지 않도록 구체적인 예와 영역을 보여주기 위해 위의 일부를 보여주고 싶었습니다. 사람들이 메모리가 너무 풍부하고 저렴하다고 말할 때 약간 짜증을내는 경향이 있습니다. DRAM 및 하드 드라이브와 같은 느린 메모리에 대한 이야기이기 때문입니다. 빠른 메모리에 대해 이야기 할 때 여전히 작고 귀중합니다. 그리고 매우 중요한 (즉, 모든 경우가 아닌 일반적인 경우) 경로의 성능은 소량의 빠른 메모리를 재생하고 가능한 한 효과적으로 활용하는 것과 관련이 있습니다. .

이러한 종류의 경우 C ++과 같은 고급 객체를 디자인 할 수있는 언어로 작업하는 것이 도움이됩니다. 예를 들어, 이러한 객체를 하나 이상의 연속 배열에 저장할 수는 있지만 이러한 모든 객체는 연속적으로 표시되며 객체 당 불필요한 메모리 오버 헤드가 없습니다 (예 : 모든 객체에 반영 또는 가상 디스패치가 필요한 것은 아님). 실제로 성능이 중요한 영역으로 이동하면 실제로 개체 풀을 처리하고 기본 데이터 형식을 사용하여 개체 오버 헤드, GC 비용을 피하고 메모리에 자주 액세스하는 등의 메모리 제어 기능을 제공하는 것이 실제로 생산성 향상이됩니다. 함께 인접합니다.

따라서 메모리 관리 / 제어 (또는 부족)는 실제로 생산성을 향상시켜 문제를 해결할 수있는 언어를 선택하는 주된 이유입니다. 나는 성능에 중요하지 않은 코드를 확실히 작성하고 있으며, C에서 포함하기 쉬운 Lua를 사용하는 경향이 있습니다.