많은 양의 RAM이 필요한 애플리케이션에 C ++ 또는 Java를 선택 하시겠습니까? [닫은]


11

나는 프로세서 사용량이 많고 힙 사용량이 많은 과학 응용 프로그램을 생각하고 있습니다 (최소 몇 기가 바이트). 일년 중 다른 시간에 C ++을 즐겁게 사용하지만이 경우 C ++ 메모리 관리자에 자연스러운 조각화가 Java의 압축 수집기의 이점과 비교하여 심각한 문제가 될 수 있는지 궁금합니다.

아무도 이것과 관련된 실제 사례를 가리킬 수 있습니까?


이 경우 언어가 프로그래밍만큼 중요하지 않다고 생각합니다. 모든 성숙한 언어는 계산 규모에 따라 작동 할 수 있습니다. 이 역할을 수행 할 수있는 Java, C / C ++, 심지어 Python 및 Rubies도 있습니다. 메모리 누수에 대한 확실한 확신이 필요한 것처럼 들리므로 일부는 다른 것보다 어렵습니다.
Rig

2
7.99 달러에 GB를받을 수 있다면 문제가 있습니까? Kingston 1GB DDR3
Bo Persson

2
@BoPersson, 내 경험에 따르면, 이러한 종류의 문제가있는 사람들은 고급 마더 보드를 완전히 채우고 시작하여 원하는만큼 넣을 수 없다고 불평하고 관리 가능한 한 큰 데이터 세트를 공급 한 다음 불만을 제기합니다. 충분하지 않습니다.
AProgrammer

@dsign, 요즘에는 1000 € 미만으로 수백 기가 바이트의 메모리를 수용하는 마더 보드를 얻을 수있는 몇 가지 공연은 메모리 사용량이 많지 않습니다.
AProgrammer

1
싸구려 메모리 부분에 동의하십시오. 개발에 관해서는, 나는 오랫동안 C ++에 있었고 좋은 코딩 관행은 누출을 다소 드문 현상으로 만듭니다. 사실, 그 점에서 Java보다 C ++을 선호합니다.
dsign

답변:


11

머신의 한계 를 강조 하는 응용 프로그램에 대해 이야기하고 있다면 , 그 한계를 초과하지 않도록 프로그래밍 트릭을 수행 할 것으로 기대한다면 C ++이 나아갈 길입니다. C ++은 (Emilio가 지적한 바와 같이) Java가 그렇지 않은 곳에서 최적화를위한 공간을 제공 할뿐만 아니라 가비지 컬렉터는 메모리를 많이 사용하는 공간입니다.

이 질문에 대한 답변 : StackOverflow : 가비지 수집에 필요한 추가 메모리 양은 얼마 입니까? 다소 어두운 그림을 그리십시오.하지만 가비지 수집기에는 여유 메모리가 할당 된 메모리 만큼 있어야합니다 (내가 들었던 것). 이것은 여전히 ​​Java를 사용하면 여전히 많은 여유 메모리가 필요하다는 것을 의미합니다 효율적으로 실행됩니다.

반면, 오늘날 우리는 일반적으로 하드웨어의 한계를 초과하지 않도록 프로그래밍 트릭을 수행하는 것보다 비싼 하드웨어를 구입하는 것을 선호합니다. 귀하의 경우, RAM 문제는 일반적으로 64 비트 시스템을 사용하고 필요한만큼 많은 RAM 모듈을 던져서 해결됩니다. 요즘 하드웨어 개발 비용은 선진국의 개발 시간 비용과 거의 비슷합니다.

나는이 옵션을 진지하게 고려해야한다고 생각하며 가능하면 C ++보다 Java로 무언가를 개발하고 나중에 유지하는 것이 훨씬 쉽기 때문에이 옵션과 C ++ 대신 Java를 사용하십시오.


답변 주셔서 감사합니다. 하드웨어 일러스트에 동의합니다.
dsign

가비지 수집이 실행되는 동안 프로그램 일시 중지에 신경 쓰지 않으면 메모리 요구가 훨씬 작아집니다.

1
나는 마지막 단락에 동의하지 않습니다. Java가 C ++보다 개발하기가 반드시 쉽지는 않습니다. 지난 5-6 년 동안 많은 C ++과 비교적 적은 Java를 해왔 기 때문에 나에게는 적합하지 않습니다. C ++ 및 Java로 유지 보수 가능하고 유지 보수 불가능한 코드를 작성할 수 있습니다.
David Thornley

1
@DavidThornley 저는 10 년 이상 C / C ++를, 6 년 이상 Java를 수행했습니다. 프로토 타이핑, 개발, 확장 및 유지 관리와 같은 모든면에서 Java가 더 쉬워졌습니다. 그러나 어쨌든 그것은 의견이 의도하는 것입니다 : 다릅니다 . C-: =
Mike Nakis

빅 데이터, 프로세서 굶주린 프로젝트를 위해 프로그래밍 한 사람이 있습니까? 거기에 의견이 있습니까?
dsign

7

문제는 Java이므로 C ++을 사용하지 않고 C ++이므로 Java를 사용하지 않는 것입니다. C ++ 컨테이너는 일반적으로 Java 프리 스토어처럼 과도한 조각화를 피하기 위해 구현됩니다.

그러나 메모리를 직접 할당하면 Java에서 허용하지 않는 작업을 수행하여 조각화가 발생할 수 있습니다.

적절한 솔루션 (C ++에서)은 고정 된 "플렉스"(여기서는 중요한 할당 자 클래스를 작성 함)를 통해 할당을 관리하는 할당 자 클래스를 통해 컨테이너 및 스마트 포인터를 사용하는 것입니다. 그리고 이것은 Java와 아무 관련이없는 프로그래밍 스타일이므로 어떤 비교도 의미가 없습니다.

[편집] 오래된 샘플 일 수 있습니다. 고정 할당


답변 해 주셔서 감사합니다. Emilio. C ++의 유연성을 잘 알고 있으며 귀하와 동의하는 경향이 있습니다. 그런 다음 다시이 기술이 성공에 사용 된 실제 사용 사례를 알고 싶습니다.
dsign

@dsign : 게시물 수정, 링크 참조
Emilio Garavaglia

1
이전에 이러한 기술을 사용했습니다. 성능이 떨어지는 앱의 할당자는 고정 블록 힙 세트를 사용하도록 할당자를 변경했습니다. 따라서 4 바이트 블록을 원할 때 4 바이트 블록 만 저장 한 힙에서 나왔습니다. 5 바이트를 원한다면 8 바이트 블록 힙 등에서 비롯된 것입니다. 성능이 크게 향상되었습니다 (우리의 많은 할당 앱의 경우). 좋은 결과를 얻지 못할 수도 있지만 매우 효과적 일 수 있습니다. 모든 할당이 고정 된 블록으로 들어 왔을 때 조각화도 없었습니다.
gbjbaanb

2

가비지 수집의 장점은 메모리가 무한한 컴퓨터를 시뮬레이션한다는 것입니다. 해당 추상화의 메커니즘 또는 구현은 프로그래머에게 완전히 투명하도록 고안되었습니다. 우리는 메커니즘이 더 이상 프로그램에서 사용하지 않는 메모리를 회수한다는 것을 알고 있지만 실제로는 보장되지 않습니다. 프로그램이 실제로 사용하는 것보다 더 많은 RAM이있는 머신에서 프로그램을 실행하면 가비지 콜렉션이 발생하지 않을 수 있습니다. 메모리를 사용하는 방법에 관계없이 프로그램을 작성할 수 있기 때문에 관련이 없습니다. 메모리 관리자는 프로그램이 요청할 때마다 더 많은 RAM을 할당하므로 이러한 할당이 항상 성공할 것이라고 가정 할 수 있습니다. Java는 가비지 수집 언어이며 C ++은 그렇지 않습니다. 1

가비지 수집의 단점은 모든 추상화와 마찬가지로 누출되는 경향이 있다는 것입니다. 항상 가장자리에서 항상 완벽하게 작동하는 것은 아니며 버그가 발생할 가능성이 있습니다. 가비지 수집 알고리즘 (프로그래머로서 투명해야하는 알고리즘)을 작성한 사람들은 가장 일반적인 경우에 최적화되어 있으며 일반적인 경우의 문제는 결코 흔한 일이 아니라는 것입니다. 일반적으로 가비지 수집기가 메모리를 관리하는 것보다 더 나은 방법은 없습니다. 그러나 특정 상황에서 (그리고 충분한 시간, 에너지 및 이해가 주어진 경우) 가능할 수 있습니다. C ++은 이러한 유연성을 제공합니다. 자바는 그렇지 않습니다.

나는 언어를 선택하기위한 표준 조언이 여기에 적용된다고 생각합니다.이 경우 제약 조건이 주어지면 훨씬 더 그렇습니다. 프로젝트의 주요 개발자에게 가장 친숙한 언어를 선택하십시오. 앱을보다 빠르고 효율적으로 개발할 수있는 명백한 이유 외에도 특히Java를 프로그래밍하는 것과 같은 C ++ 프로그래밍은 메모리 관리 관행을 끔찍하게 초래하여 누출 및 충돌이 발생하기 때문에 설명하는 경우 중요합니다. 마찬가지로 C ++로 프로그래밍하는 것과 같은 Java 프로그래밍은 그리 좋지 않을 것입니다. 가비지 수집 알고리즘이 가장 일반적인 경우에 맞게 조정되고 조정되면 최적화되지 않은 프로그램이 생성 될 수 있습니다 .

가비지 수집 언어로 작업하는 데 사용되는 프로그래머는 가비지 수집기에서 싸우는 것이 아니라 신뢰하는 방법을 배웁니다. 가비지 수집 언어로 작업하는 경우 이들은 프로젝트에서 원하는 프로그래머입니다. 그렇지 않은 프로그래머가비지 수집 언어로 작업하는 데 사용되는 것은 "무한 메모리"추상화에 대해 회의적이며, 많은 이유가 있습니다. 이 프로그래머들에게는 좋겠지 만, 이들은 가비지 수집 언어로 작업하기를 원하는 사람들이 아닙니다. 왜냐하면 그들은 항상 모든 단계에서 GC와 싸우고, 끊임없이 그것을 추론하고 종종 느리고 메모리 효율이 낮습니다. 다른 유형의 프로그래머보다 코드. 기껏해야 그들은 휠을 재발 명하는 데 많은 시간을 할애하여 많은 비용과 장기적인 유지 보수 비용을 지불해야합니다.

그리고 정말로 중요한지 스스로에게 물어봐야합니다. Bo의 스 네이드 의견에 대한 힌트 이상의 사실이있다. 메모리가 너무 저렴해서 손으로 쓸 가치가 거의 없다. 막대한 양 이 필요하더라도 그 양은 10 년 전과 거의 비슷하지 않습니다. 프로그래머와 응용 프로그램 개발은 RAM과 처리 능력을 구입하는 것보다 훨씬 비쌉니다. 그렇다고 가능한 곳에서 경제를 피해야한다는 의미는 아니지만 너무 많은 시간을 낭비하지 않아야합니다.


1 물론,이 가정은 문제의 깊은 결함을 강조한다. "Java 또는 C ++"는 약간의 청어입니다. 표준 Java 구현은 가비지 콜렉션을 제공하고 C ++은 언어 표준에 따르지 않지만 C ++에 써드 파티 가비지 콜렉터를 사용할 수없는 이유는 없습니다. 많은 회사들이 이런 것들을 팔아 생계를 꾸려 왔으며, 어떤 사람들은 생계를 꾸려서 무료로 줬을 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.