Java에 다른 크기의 프리미티브가있는 이유는 무엇입니까?

자바에서는이 원시적 종류 byte, short, int과 long및 대한 같은 일이 float와 double. 프리미티브 값에 몇 바이트를 사용해야하는지 개인에게 설정해야하는 이유는 무엇입니까? 전달 된 숫자의 크기에 따라 크기를 동적으로 결정할 수 없습니까?

내가 생각할 수있는 두 가지 이유가 있습니다.

1. 데이터의 크기를 동적으로 설정하면 데이터도 동적으로 변경할 수 있어야합니다. 잠재적으로 성능 문제가 발생할 수 있습니까?
2. 아마도 프로그래머는 누군가가 특정 크기보다 더 큰 수를 사용하기를 원하지 않을 것이므로 제한 할 수 있습니다.

나는 아직도 단일 사용하여 간단한에 의해 얻을 수있는 많은이 있었어요 수 있다고 생각 int하고 float자바는이 경로를 가지 않기로 결정 특정 이유가 있었다, 유형을?

언어 디자인의 여러 측면과 마찬가지로 성능과의 우아함 (이전 언어의 역사적 영향은 말할 것도 없습니다)과 상충됩니다.

대안

단 하나의 유형의 자연수를 갖는 프로그래밍 언어를 만드는 것은 확실히 가능하고 아주 간단합니다 nat. 학업 연구에 사용되는 거의 모든 프로그래밍 언어 (예 : PCF, System F)에는이 단일 숫자 유형이 있습니다. 그러나 실제로 언어 디자인은 단순한 우아함이 아닙니다. 또한 성능을 고려해야합니다 (성능이 고려되는 범위는 언어의 의도 된 적용에 달려 있음). 성능은 시간과 공간 제약으로 구성됩니다.

공간 제약

프로그래머가 선행 바이트 수를 선택하게하면 메모리가 제한된 프로그램의 공간을 절약 할 수 있습니다. 모든 숫자가 256보다 작 으면 bytes 보다 8 배 많은 s를 long사용하거나 더 복잡한 객체에 저장된 저장소를 사용할 수 있습니다. 표준 Java 응용 프로그램 개발자는 이러한 제약 조건에 대해 걱정할 필요가 없습니다.

능률

공간을 무시하더라도 여전히 CPU에 의해 제약을받습니다. CPU는 고정 된 수의 바이트 (64 비트 아키텍처에서는 8 바이트)에서만 작동하는 명령 만 가지고 있습니다. 즉, 단일 8 바이트 long유형을 제공하는 경우에도 산술 연산을 단일 기본 CPU 명령어에 직접 매핑 할 수 있으므로 무제한 자연 번호 유형을 사용하는 것보다 언어 구현이 훨씬 단순 해집니다 . 프로그래머가 임의로 많은 수를 사용할 수있게하려면 단일 산술 연산 을 복잡한 기계 명령어 시퀀스 에 매핑해야하므로 프로그램 속도가 느려집니다. 이것은 당신이 제기 한 포인트 (1)입니다.

부동 소수점 유형

지금까지의 논의는 정수에만 관한 것입니다. 부동 소수점 유형은 매우 미묘한 의미론과 엣지 케이스가있는 복잡한 짐승입니다. 따라서, 우리는 쉽게 대체 할 수있다하더라도 int, long, short, 및 byte단일과 nat유형, 부동 소수점 숫자의 유형도 무엇 분명하지 않다 입니다 . 실수는 프로그래밍 언어로 존재할 수 없으므로 실수가 아닙니다. 그들은 합리적 인 숫자도 아닙니다 (원한다면 합리적인 유형을 만드는 것이 간단하지만). 기본적으로 IEEE는 대략적인 실제 숫자로가는 방법을 결정했으며 그 이후로 모든 언어 (및 프로그래머)가 계속 붙어 있습니다.

드디어:

아마도 프로그래머는 누군가가 특정 크기보다 더 큰 수를 사용하기를 원하지 않을 것이므로 제한 할 수 있습니다.

이것은 유효한 이유가 아닙니다. 첫째, 유형이 자연스럽게 숫자 범위를 인코딩 할 수있는 상황을 생각할 수는 없지만 프로그래머가 시행하려는 범위가 기본 유형의 크기와 정확히 일치 할 확률은 천문학적으로 낮습니다.

그 이유는 매우 간단합니다 : 효율성 . 여러 가지 방법으로.

1. 기본 데이터 유형 : 언어의 데이터 유형이 하드웨어의 기본 데이터 유형과 일치할수록 언어가 더 효율적으로 간주됩니다. (프로그램이 반드시 효율적이라는 의미는 아니지만 실제로 수행중인 작업을 알고 있다면 하드웨어가 실행할 수있는만큼 효율적으로 실행될 코드를 작성할 수 있습니다.) 제공된 데이터 유형 Java에 의해 바이트, 단어, 더블 워드 및 가장 인기있는 하드웨어의 quadwords에 해당합니다. 가장 효율적인 방법입니다.

2. 32 비트 시스템에서 보증되지 않는 오버 헤드 : 모든 것을 고정 크기 64 비트 길이로 매핑하기로 결정한 경우 64 비트를 수행하기 위해 훨씬 더 많은 클럭 사이클이 필요한 32 비트 아키텍처에 막대한 불이익이 가해졌습니다. 32 비트 작업보다 비트 작업

3. 메모리 낭비 : 메모리 정렬에 대해 너무 까다 롭지 않은 많은 하드웨어가 있으며 (예 : Intel x86 및 x64 아키텍처는 그 예입니다), 해당 하드웨어의 100 바이트 배열은 100 바이트의 메모리 만 차지할 수 있습니다. 그러나 더 이상 바이트가없고 대신 long을 사용해야하는 경우 동일한 배열이 더 많은 메모리를 차지합니다. 바이트 배열은 매우 일반적입니다.

4. 숫자 크기 계산 : 전달 된 숫자가 얼마나 큰지에 따라 동적으로 정수 크기를 결정한다는 개념은 너무 단순합니다. 숫자를 "통과"하는 단일 지점이 없습니다. 더 큰 크기의 결과를 요구할 수있는 모든 단일 작업에서 런타임에 숫자를 얼마나 많이 계산해야하는지 계산 : 숫자를 증가시킬 때마다, 두 숫자를 더할 때마다, 두 개를 곱할 때마다 숫자 등

5. 다른 크기의 숫자에 대한 연산 : 결과적으로 메모리에 잠재적으로 다른 크기의 숫자가 떠 다니면 모든 연산 이 복잡해집니다 . 두 숫자를 간단히 비교하기 위해 런타임은 먼저 비교할 두 숫자가 동일한 지 여부를 확인해야합니다 그렇지 않은 경우 큰 크기와 일치하도록 작은 크기를 조정하십시오.

6. 특정 피연산자 크기가 필요한 연산 : 특정 비트 단위 연산은 특정 크기의 정수에 의존합니다. 미리 정해진 특정 크기가 없으면 이러한 작업을 에뮬레이션해야합니다.

7. 다형성 오버 헤드 : 런타임시 숫자의 크기를 변경하면 다형성이어야 함을 의미합니다. 이는 스택에 할당 된 고정 크기 프리미티브가 될 수 없으며 힙에 할당 된 객체 여야 함을 의미합니다. 그것은 매우 비효율적입니다. (위의 # 1을 다시 읽으십시오.)

다른 답변에서 논의 된 요점을 반복하지 않기 위해 여러 관점을 간략하게 설명하려고합니다.

언어 디자인 관점에서

• 기계 너비에 맞지 않는 정수 연산의 결과를 자동으로 수용하는 프로그래밍 언어 및 실행 환경을 설계하고 구현할 수 있습니다.
• 이러한 동적 너비 정수를이 언어의 기본 정수 유형으로 만들지 여부는 언어 설계자가 선택합니다.
• 그러나 언어 디자이너는 다음과 같은 단점을 고려해야합니다.
  • CPU는 더 많은 코드를 실행해야하는데 시간이 더 걸립니다. 그러나 정수가 단일 기계어 내에 맞는 가장 빈번한 경우에 대해 최적화 할 수 있습니다. 태그가 지정된 포인터 표현을 참조하십시오 .
  • 해당 정수의 크기가 동적이됩니다.
  • 메모리에서 동적 너비 정수를 읽으려면 두 번 이상의 트립이 필요할 수 있습니다.
  • 필드 / 요소 내부에 동적 너비 정수가 포함 된 구조체 (객체) 및 배열의 ​​크기는 동적입니다.

역사적 이유

이것은 이미 Java의 역사에 관한 Wikipedia 기사에서 논의되었으며 Marco13의 답변 에서도 간략하게 논의되었습니다 .

나는 지적했다 :

• 언어 디자이너는 미적 감각과 실용적 사고 방식을 전환해야합니다. 미적 사고 방식은 정수 오버플로와 같이 잘 알려진 문제가 발생하지 않는 언어를 디자인하려고합니다. 실용적인 사고 방식은 설계자에게 프로그래밍 언어가 유용한 소프트웨어 응용 프로그램을 구현하고 다른 언어로 구현 된 다른 소프트웨어 부분과 상호 운영 할 수있을만큼 충분히 우수해야한다는 것을 상기시킵니다.
• 오래된 프로그래밍 언어에서 시장 점유율을 차지하려는 프로그래밍 언어는 실용적입니다. 한 가지 가능한 결과는 기존 언어에서 기존 프로그래밍 구성과 스타일을 더 많이 통합하거나 빌릴 수 있다는 것입니다.

효율성 이유

효율성은 언제 중요합니까?

• 대규모 응용 프로그램 개발에 적합한 프로그래밍 언어를 광고하려는 경우
• 수백만 및 수십억 개의 작은 품목에 대한 작업이 필요한 경우 모든 효율성이 향상됩니다.
• 다른 프로그래밍 언어와 경쟁해야 할 때, 귀하의 언어는 훌륭하게 수행해야합니다. 최고는 아니지만 최고의 성능을 유지하는 데 도움이됩니다.

스토리지 효율성 (메모리 또는 디스크)

• 컴퓨터 메모리는 한때 희귀 한 자원이었습니다. 예전에는 컴퓨터로 처리 할 수있는 응용 프로그램 데이터의 크기가 컴퓨터 메모리의 양에 의해 제한되었지만 영리한 프로그래밍 (구현하는 데 더 많은 비용이 소요됨)을 사용하여 해결할 수는있었습니다.

실행 효율성 (CPU 내 또는 CPU와 메모리 간)

• Gardenhead의 답변 에서 이미 논의했습니다 .
• 프로그램이 연속으로 저장된 매우 작은 수의 배열을 처리해야하는 경우, 많은 양의 데이터로 인해 CPU와 메모리 간의 처리량이 병목 현상이 발생하므로 메모리 내 표현의 효율성은 실행 성능에 직접적인 영향을 미칩니다. 이 경우 데이터를 더 조밀하게 패킹하면 단일 캐시 라인 페치로 더 많은 데이터를 검색 할 수 있습니다.
• 그러나 데이터가 연속적으로 저장되거나 처리되지 않으면이 추론이 적용되지 않습니다.

특정 문맥으로 제한 되더라도 작은 정수에 대한 추상화를 제공하기위한 프로그래밍 언어의 필요성

• 이러한 요구는 종종 언어 자체 표준 라이브러리를 포함한 소프트웨어 라이브러리 개발에서 발생합니다. 다음은 그러한 경우입니다.

상호 운용성

• 종종 고급 프로그래밍 언어는 운영 체제 또는 다른 하위 언어로 작성된 소프트웨어 (라이브러리)와 상호 작용해야합니다. 이러한 하위 수준 언어는 종종 "structs"를 사용하여 통신합니다. "structs" 는 다른 유형의 필드로 구성된 레코드의 메모리 레이아웃을 엄격하게 지정합니다.
• 예를 들어, 고급 언어는 특정 외부 함수가 char256 크기 의 배열을 허용하도록 지정해야 할 수 있습니다 (예).
• 운영 체제 및 파일 시스템에서 사용하는 일부 추상화에는 바이트 스트림을 사용해야합니다.
• 일부 프로그래밍 언어 BitConverter는 좁은 정수를 비트 스트림 및 바이트 스트림으로 패킹 및 언 패킹하는 데 도움이되는 유틸리티 기능 (예 :)을 제공하도록 선택합니다 .
• 이 경우 더 좁은 정수 유형은 언어에 내장 된 기본 유형일 필요는 없습니다. 대신 라이브러리 유형으로 제공 될 수 있습니다.

문자열 처리

• 문자열을 조작하는 주요 디자인 목적의 응용 프로그램이 있습니다. 따라서 문자열 처리의 효율성은 이러한 유형의 응용 프로그램에 중요합니다.

파일 형식 처리

• 많은 파일 형식이 C와 같은 사고 방식으로 설계되었습니다. 이와 같이, 좁은 폭 필드의 사용이 일반적이었다.

바람직 함, 소프트웨어 품질 및 프로그래머의 책임

• 많은 유형의 응용 분야에서 정수의 자동 확장은 실제로 바람직한 기능이 아닙니다. 포화도 및 랩 어라운드도 아닙니다 (모듈러스).
• 많은 유형의 응용 프로그램은 API 수준과 같이 소프트웨어의 다양한 중요 지점에서 최대 허용 값을 프로그래머가 명시 적으로 지정하면 도움이됩니다.

다음 시나리오를 고려하십시오.

• 소프트웨어 API는 JSON 요청을 수락합니다. 요청에는 하위 요청 배열이 포함됩니다. Deflate 알고리즘으로 전체 JSON 요청을 압축 할 수 있습니다.
• 악의적 인 사용자가 10 억 개의 자식 요청을 포함하는 JSON 요청을 만듭니다. 모든 자녀 요청은 동일합니다. 악의적 인 사용자는 시스템이 쓸모없는 작업을 수행하여 일부 CPU주기를 태우려고합니다. 압축으로 인해 이러한 동일한 하위 요청은 총 크기가 매우 작게 압축됩니다.
• 데이터의 압축 된 크기에 대한 사전 정의 된 제한으로는 충분하지 않습니다. 대신, API는 API에 포함될 수있는 하위 요청 수에 사전 정의 된 제한 및 / 또는 데이터의 축소 된 크기에 사전 정의 된 제한을 적용해야합니다.

많은 수의 자릿수를 안전하게 확장 할 수있는 소프트웨어는 복잡성을 증가시키면서 해당 목적에 맞게 엔지니어링해야하는 경우가 종종 있습니다. 정수 오버플로 문제가 제거 되더라도 자동으로 오지 않습니다. 이것은 언어 설계 관점에 대한 완전한 결론에 도달합니다. 종종 의도하지 않은 정수 오버플로가 발생했을 때 작업을 거부하는 소프트웨어 (오류 또는 예외 발생)가 천문학적으로 큰 작업을 자동으로 준수하는 소프트웨어보다 낫습니다.

이것은 OP의 관점을 의미합니다.

프리미티브 값에 몇 바이트를 사용해야하는지 개인에게 설정해야하는 이유는 무엇입니까?

정확하지 않습니다. 프로그래머는 소프트웨어의 중요한 부분에서 정수 값이 취할 수 있는 최대 크기 를 지정하도록 허용해야하며 때로는 필요 합니다. 가든 헤드의 답변에서 알 수 있듯이 기본 유형에 의해 부과 된 자연 제한은이 목적에 유용하지 않습니다. 언어는 프로그래머가 크기를 선언하고 그러한 제한을 시행 할 수있는 방법을 제공해야합니다.

그것은 모두 하드웨어에서 나옵니다.

바이트는 대부분의 하드웨어에서 주소를 지정할 수있는 가장 작은 메모리 단위입니다.

방금 언급 한 모든 유형은 몇 바이트의 바이트로 작성됩니다.

바이트는 8 비트입니다. 그것으로 당신은 8 개의 부울을 표현할 수 있지만 한 번에 하나씩 만 볼 수는 없습니다. 당신은 1을, 당신은 8을 모두 다루고 있습니다.

그리고 그것은 그렇게 간단했지만 우리는 8 비트 버스에서 16, 32, 그리고 이제 64 비트 버스로 갔다.

즉, 바이트 수준에서 여전히 주소를 지정할 수 있지만 인접한 바이트를 가져 오지 않고는 더 이상 메모리에서 단일 바이트를 검색 할 수 없습니다.

이 하드웨어에 직면 한 언어 설계자들은 하드웨어에 맞는 유형을 선택할 수있는 유형을 선택할 수 있도록 선택했습니다.

이러한 세부 사항은 특히 모든 하드웨어에서 실행되는 언어로 추상화 할 수 있으며 추상화해야한다고 주장 할 수 있습니다. 이것은 숨겨진 성능 문제가 있지만 당신이 옳을 수도 있습니다. 그런 식으로 일어나지 않았습니다.

자바는 실제로 이것을 시도합니다. 바이트는 자동으로 Int로 승격됩니다. 처음으로 심각한 비트 이동 작업을 시도 할 때 견딜 수있는 사실.

그렇다면 왜 잘 작동하지 않습니까?

알려진 좋은 C 알고리즘으로 앉아서 Java로 입력하고 약간 조정하면 작동 할 수있는 방식으로 Java의 큰 판매 포인트. 그리고 C는 하드웨어와 매우 가깝습니다.

통합 유형에서 그 크기를 유지하고 추상화하는 것은 효과가 없었습니다.

그래서 그들은 가질 수있었습니다. 그들은 단지하지 않았다.

아마도 프로그래머는 누군가가 특정 크기보다 더 큰 수를 사용하기를 원하지 않을 것이므로 제한 할 수 있습니다.

이것은 유효한 생각입니다. 이를 수행하는 방법이 있습니다. 하나 의 클램프 기능 . 언어는 임의의 범위를 그들의 유형으로 구울 수 있습니다. 그리고 컴파일 타임에 해당 경계가 알려진 경우 해당 숫자가 저장되는 방식을 최적화 할 수 있습니다.

자바는 그 언어가 아닙니다.

아마도 이러한 유형이 Java에 존재하는 한 가지 중요한 이유는 간단하고 고민스럽지 않은 기술입니다.

C와 C ++에도 이런 유형이있었습니다!

이것이 그 이유라는 증거를 제공하기는 어렵지만 최소한 몇 가지 강력한 증거가 있습니다. 오크 언어 사양 (버전 0.2)에는 다음 구절이 포함되어 있습니다.

3.1 정수형

Oak 언어의 정수는 C 및 C ++의 정수와 비슷하지만 두 가지 예외가 있습니다. 모든 정수 유형은 기계에 독립적이며 C가 도입 된 이후 세계의 변화를 반영하기 위해 일부 전통적인 정의가 변경되었습니다. 네 가지 정수 유형의 너비는 8, 16, 32 및 64 비트이며 unsigned수정자가 접두사를 붙이지 않는 한 부호가 있습니다.

따라서 질문은 다음과 같이 요약 될 수 있습니다.

C에서 짧고 int이며 오래 발명 된 이유는 무엇입니까?

여기에서 묻는 질문의 맥락에서 편지 질문에 대한 답변이 만족 스러운지 확실하지 않습니다. 그러나 여기에있는 다른 답변과 함께 이러한 유형을 갖는 것이 유리 할 수 ​​있음이 분명해질 수 있습니다 (자바에 존재하는 것이 C / C ++의 유산인지 여부에 관계없이).

내가 생각할 수있는 가장 중요한 이유는

• 바이트는 주소를 지정할 수있는 가장 작은 메모리 단위입니다 (이미 언급 한 CandiedOrange). A byte는 기본 데이터 블록으로, 파일이나 네트워크를 통해 읽을 수 있습니다. 어떤 이의 명시 적 표현이 존재한다 (그리고 때로는 변장에 오는 경우에도 그것은 대부분의 언어에 존재한다).

• 실제로는 단일 유형을 사용하여 모든 필드와 로컬 변수를 표시하고이 유형을 호출하는 것이 이치에 맞습니다 int. stackoverflow에 대한 관련 질문 이 있습니다. Java API가 short 또는 byte 대신 int를 사용하는 이유는 무엇입니까? . 내 대답에서 언급했듯이 더 작은 유형 ( byte및 short) 을 갖는 것에 대한 한 가지 정당화 는 이러한 유형의 배열 을 만들 수 있다는 것입니다 . Java에는 여전히 "하드웨어에 가까운"배열이 있습니다. 다른 언어를 달리 (와 같은 개체의 배열과 대조적 Integer[n]어레이) int[n]배열 값 힙 걸쳐 흩어져 참조 모음 아니다. 대신, 그것은 것입니다실제로 n*4는 알려진 크기와 데이터 레이아웃을 가진 하나의 메모리 덩어리 인 연속적인 바이트 블록이어야 합니다. 임의 크기의 정수 값 개체 모음 또는 1000 바이트를 사용하는 1000 바이트를 저장하도록 선택 byte[1000]하면 후자는 실제로 일부 메모리를 절약 할 수 있습니다. (이것의 일부 다른 장점은 더 미묘 할 수 있으며 Java를 기본 라이브러리와 인터페이스 할 때만 분명해집니다)

귀하가 구체적으로 요구 한 사항에 관하여 :

전달 된 숫자의 크기에 따라 크기를 동적으로 결정할 수 없습니까?

데이터의 크기를 동적으로 설정하면 데이터도 동적으로 변경할 수 있어야합니다. 잠재적으로 성능 문제가 발생할 수 있습니까?

완전히 새로운 프로그래밍 언어를 처음부터 설계하려는 경우 변수의 크기를 동적으로 설정할 수 있습니다. 나는 컴파일러 건설에서 전문가가 아니지만, 동적으로 변화하는 유형의 현명 mangage 컬렉션에 힘들 것이라고 생각 - 특히, 당신이있을 때 강력하게 입력 언어를. 따라서 "일반적인 임의의 정밀 숫자 데이터 형식"으로 저장되는 모든 숫자로 요약 할 수 있으며, 이는 성능에 영향을 줄 수 있습니다. 물론, 거기에 있습니다 강력하게 형식화 및 / 또는 임의의 크기의 숫자 유형을 제공하는 프로그래밍 언어,하지만 난 이런 식으로 가서 진정한 범용 프로그래밍 언어가 있다고 생각하지 않습니다.

사이드 노트 :

• unsignedOak 사양에서 언급 된 수정 자 에 대해 궁금했을 것 입니다. 실제로, " unsigned아직 구현되지 않았으며 결코 그렇지 않을 수도 있습니다." 라는 설명도 포함되어 있습니다. . 그리고 그들은 옳았습니다.

• C / C ++에 왜 이러한 다른 정수 유형이 있는지 궁금해하는 것 외에도 왜 그렇게 많은 비트를 엉망으로 만들 었는지 궁금 할 수 있습니다 int. 이에 대한 타당성은 일반적으로 성능과 관련이 있으며 다른 곳에서 찾아 볼 수 있습니다.

성능과 아키텍처에 대해 아직 배우지 않았 음을 보여줍니다.

• 첫째, 모든 프로세서가 큰 유형을 처리 할 수있는 것은 아니므로 한계를 알고 이에 대해 작업해야합니다.
• 둘째, 유형이 작을수록 작업 수행시 성능이 향상됩니다.
• 또한 크기가 중요합니다. 데이터를 파일이나 데이터베이스에 저장 해야하는 경우 크기는 모든 데이터의 성능과 최종 크기 모두에 영향을 미칩니다. 예를 들어 15 개의 열이있는 테이블이 있고 여러 개가 있다고 가정 해 봅시다. 수백만의 기록. 각 열에 필요한 크기만큼 작은 것을 선택하거나 가장 큰 유형을 선택하는 것의 차이는 작업 성능에서 가능한 데이터 수와 시간의 차이입니다.
• 또한 복잡한 계산에도 적용됩니다. 여기서 처리되는 데이터의 크기는 게임과 같이 큰 영향을 미칩니다.

데이터 크기의 중요성을 항상 무시하면 성능에 영향을 미치므로 필요한만큼 많은 리소스를 사용해야하지만 더 이상은 아닙니다!

그것은 정말 간단한 일을하고 많은 자원을 필요로하고 그 시스템을 실제로 사용하는데 엄청난 비효율적 인 프로그램이나 시스템의 차이입니다. 또는 많은 기능을 수행하지만 다른 시스템보다 빠르게 실행되고 실제로 실행하기에는 비용이 적게 드는 시스템.

몇 가지 좋은 이유가 있습니다

(1) 1 바이트 변수 구절의 저장 길이는 중요하지 않지만, 어레이에서 수백만의 저장은 매우 중요합니다.

(2) 특정 정수 크기에 기반한 "하드웨어 네이티브"산술이 훨씬 더 효율적일 수 있으며 일부 플랫폼의 일부 알고리즘의 경우 중요 할 수 있습니다.