Có phải là một thực hành tốt để sử dụng các loại dữ liệu nhỏ hơn cho các biến để tiết kiệm bộ nhớ?

Khi tôi học ngôn ngữ C ++ lần đầu tiên tôi đã học được rằng ngoài int, float v.v., các phiên bản nhỏ hơn hoặc lớn hơn của các loại dữ liệu này tồn tại trong ngôn ngữ. Ví dụ tôi có thể gọi một biến x

int x;
or 
short int x;

Sự khác biệt chính là int ngắn chiếm 2 byte bộ nhớ trong khi int chiếm 4 byte và int ngắn có giá trị nhỏ hơn, nhưng chúng ta cũng có thể gọi đây là để làm cho nó nhỏ hơn nữa:

int x;
short int x;
unsigned short int x;

mà thậm chí còn hạn chế hơn.

Câu hỏi của tôi ở đây là nếu đó là một cách thực hành tốt để sử dụng các loại dữ liệu riêng biệt theo giá trị mà biến của bạn thực hiện trong chương trình. Có phải là một ý tưởng tốt để luôn luôn khai báo các biến theo các loại dữ liệu này?

Hầu hết thời gian chi phí không gian là không đáng kể và bạn không nên lo lắng về nó, tuy nhiên bạn nên lo lắng về thông tin bổ sung mà bạn đang cung cấp bằng cách khai báo một loại. Ví dụ: nếu bạn:

unsigned int salary;

Bạn đang đưa ra một thông tin hữu ích cho một nhà phát triển khác: tiền lương không thể âm.

Sự khác biệt giữa ngắn, int, long hiếm khi gây ra vấn đề về không gian trong ứng dụng của bạn. Bạn có nhiều khả năng vô tình đưa ra giả định sai lầm rằng một số sẽ luôn phù hợp với một số kiểu dữ liệu. Có thể an toàn hơn khi luôn sử dụng int trừ khi bạn chắc chắn 100% số của bạn sẽ luôn rất nhỏ. Thậm chí sau đó, nó không có khả năng giúp bạn tiết kiệm bất kỳ dung lượng đáng chú ý nào.

OP không nói gì về loại hệ thống họ đang viết chương trình, nhưng tôi cho rằng OP đã nghĩ đến một PC điển hình có bộ nhớ GB kể từ khi C ++ được đề cập. Như một trong những ý kiến ​​nói, ngay cả với loại bộ nhớ đó, nếu bạn có vài triệu mục thuộc một loại - chẳng hạn như một mảng - thì kích thước của biến có thể tạo ra sự khác biệt.

Nếu bạn tham gia vào thế giới của các hệ thống nhúng - điều không thực sự nằm ngoài phạm vi của câu hỏi, vì OP không giới hạn nó trong PC - thì kích thước của các loại dữ liệu rất nhiều vấn đề. Tôi vừa hoàn thành một dự án nhanh trên một vi điều khiển 8 bit chỉ có 8K từ bộ nhớ chương trình và 368 byte RAM. Ở đó, rõ ràng mỗi byte đều có giá trị. Người ta không bao giờ sử dụng một biến lớn hơn mức họ cần (cả từ quan điểm không gian và kích thước mã - bộ xử lý 8 bit sử dụng rất nhiều hướng dẫn để thao tác dữ liệu 16 và 32 bit). Tại sao sử dụng CPU với nguồn lực hạn chế như vậy? Với số lượng lớn, chúng có thể có giá chỉ bằng một phần tư.

Tôi hiện đang thực hiện một dự án nhúng khác với bộ vi điều khiển dựa trên MIPS 32 bit, có 512K byte flash và 128K byte RAM (và có giá khoảng 6 đô la về số lượng). Như với PC, kích thước dữ liệu "tự nhiên" là 32 bit. Bây giờ nó trở nên hiệu quả hơn, thông minh mã hơn, để sử dụng ints cho hầu hết các biến thay vì ký tự hoặc quần short. Nhưng một lần nữa, bất kỳ loại mảng hoặc cấu trúc nào cũng phải được xem xét liệu các loại dữ liệu nhỏ hơn có được bảo hành hay không. Không giống như trình biên dịch cho các hệ thống lớn hơn, nhiều khả năng các biến trong cấu trúc sẽ được đóng gói trên một hệ thống nhúng. Tôi cẩn thận luôn cố gắng đặt tất cả các biến 32 bit trước, sau đó 16 bit, sau đó 8 bit để tránh bất kỳ "lỗ hổng" nào.

Câu trả lời phụ thuộc vào hệ thống của bạn. Nói chung, đây là những lợi thế và bất lợi của việc sử dụng các loại nhỏ hơn:

Ưu điểm

• Các loại nhỏ hơn sử dụng ít bộ nhớ hơn trên hầu hết các hệ thống.
• Các loại nhỏ hơn cho phép tính nhanh hơn trên một số hệ thống. Đặc biệt đúng với float vs double trên nhiều hệ thống. Và các kiểu int nhỏ hơn cũng cho mã nhanh hơn đáng kể trên CPU 8- hoặc 16 bit.

Nhược điểm

• Nhiều CPU có yêu cầu căn chỉnh. Một số truy cập dữ liệu liên kết nhanh hơn không được chỉ định. Một số phải có dữ liệu phù hợp để thậm chí có thể truy cập nó. Các kiểu số nguyên lớn hơn bằng một đơn vị căn chỉnh, vì vậy chúng hầu như không được sắp xếp sai. Điều này có nghĩa là trình biên dịch có thể buộc phải đặt các số nguyên nhỏ hơn của bạn thành các số nguyên lớn hơn. Và nếu các loại nhỏ hơn là một phần của cấu trúc lớn hơn, bạn có thể nhận được các byte đệm khác nhau được chèn vào bất kỳ vị trí nào trong cấu trúc bởi trình biên dịch, để sửa lỗi căn chỉnh.
• Chuyển đổi ngầm nguy hiểm. C và C ++ có một số quy tắc tối nghĩa, nguy hiểm về cách các biến được quảng bá thành các biến lớn hơn, hoàn toàn không có lỗi đánh máy. Có hai bộ quy tắc chuyển đổi ngầm được gắn với nhau, được gọi là "quy tắc quảng cáo số nguyên" và "chuyển đổi số học thông thường". Tìm hiểu thêm về họ ở đây . Các quy tắc này là một trong những nguyên nhân phổ biến nhất gây ra lỗi trong C và C ++. Bạn có thể tránh được rất nhiều vấn đề bằng cách sử dụng cùng một kiểu số nguyên trên toàn bộ chương trình.

Lời khuyên của tôi là thích điều này:

system                             int types

small/low level embedded system    stdint.h with smaller types
32-bit embedded system             stdint.h, stick to int32_t and uint32_t.
32-bit desktop system              Only use (unsigned) int and long long.
64-bit system                      Only use (unsigned) int and long long.

Ngoài ra, bạn có thể sử dụng int_leastn_thoặc int_fastn_ttừ stdint.h, trong đó n là số 8, 16, 32 hoặc 64. int_leastn_tloại có nghĩa là "Tôi muốn điều này ít nhất là n byte nhưng tôi không quan tâm nếu trình biên dịch phân bổ nó là một loại lớn hơn để phù hợp với căn chỉnh ".

int_fastn_t có nghĩa là "Tôi muốn nó dài n byte, nhưng nếu nó làm cho mã của tôi sẽ chạy nhanh hơn, trình biên dịch nên sử dụng một loại lớn hơn chỉ định".

Nói chung, các loại stdint.h khác nhau thực hành tốt hơn nhiều so với đơn giản int, v.v., vì chúng là hàng xách tay. Mục đích của việc intlà không cung cấp cho nó một chiều rộng được chỉ định để làm cho nó di động. Nhưng trong thực tế, thật khó để chuyển bởi vì bạn không bao giờ biết nó sẽ lớn như thế nào trên một hệ thống cụ thể.

Tùy thuộc vào cách hệ điều hành cụ thể hoạt động, bạn thường mong muốn bộ nhớ được phân bổ không tối ưu hóa để khi bạn gọi một byte, hoặc một từ hoặc một số loại dữ liệu nhỏ khác được phân bổ, giá trị chiếm toàn bộ đăng ký sở hữu. Cách trình biên dịch hoặc trình thông dịch của bạn hoạt động để diễn giải điều này tuy nhiên là một thứ khác, vì vậy nếu bạn biên dịch một chương trình trong C #, thì giá trị có thể chiếm một thanh ghi cho chính nó, tuy nhiên giá trị sẽ được kiểm tra ranh giới để đảm bảo bạn không cố gắng lưu trữ một giá trị sẽ vượt quá giới hạn của kiểu dữ liệu dự định.

Hiệu suất khôn ngoan và nếu bạn thực sự khoa trương về những thứ như vậy, có thể đơn giản hơn là sử dụng kiểu dữ liệu phù hợp nhất với kích thước thanh ghi mục tiêu, nhưng sau đó bạn bỏ lỡ tất cả các đường cú pháp đáng yêu đó giúp làm việc với các biến dễ dàng .

Điều này giúp bạn như thế nào? Chà, điều đó thực sự tùy thuộc vào bạn để quyết định loại tình huống bạn đang mã hóa. Đối với gần như mọi chương trình tôi từng viết, chỉ cần tin tưởng vào trình biên dịch của bạn để tối ưu hóa mọi thứ và sử dụng kiểu dữ liệu hữu ích nhất cho bạn. Nếu bạn cần độ chính xác cao, hãy sử dụng các kiểu dữ liệu dấu phẩy động lớn hơn. Nếu chỉ làm việc với các giá trị dương, có lẽ bạn có thể sử dụng một số nguyên không dấu, nhưng đối với hầu hết các phần, chỉ cần sử dụng kiểu dữ liệu int là đủ.

Tuy nhiên, nếu bạn có một số yêu cầu dữ liệu rất nghiêm ngặt, chẳng hạn như viết giao thức truyền thông hoặc một loại thuật toán mã hóa nào đó, thì việc sử dụng các kiểu dữ liệu được kiểm tra phạm vi có thể rất hữu ích, đặc biệt nếu bạn đang cố gắng tránh các vấn đề liên quan đến tràn / tràn dữ liệu hoặc giá trị dữ liệu không hợp lệ.

Lý do duy nhất khác mà tôi có thể nghĩ ra khỏi đỉnh đầu để sử dụng các kiểu dữ liệu cụ thể là khi bạn đang cố gắng truyền đạt ý định trong mã của mình. Nếu bạn sử dụng một ví dụ ngắn, bạn đang nói với các nhà phát triển khác rằng bạn đang cho phép các số dương và số âm trong phạm vi giá trị rất nhỏ.

Như Scarfridge nhận xét, đây là một

Trường hợp cổ điển của tối ưu hóa sớm .

Cố gắng tối ưu hóa để sử dụng bộ nhớ có thể ảnh hưởng đến các lĩnh vực hiệu suất khác và các quy tắc tối ưu hóa vàng là:

Nguyên tắc tối ưu hóa chương trình đầu tiên: Đừng làm điều đó .

Quy tắc tối ưu hóa chương trình thứ hai (chỉ dành cho chuyên gia!): Đừng làm điều đó . "

- Michael A. Jackson

Để biết liệu bây giờ là thời gian để tối ưu hóa cần phải có điểm chuẩn và thử nghiệm. Bạn cần biết mã của bạn đang ở đâu không hiệu quả, để bạn có thể nhắm mục tiêu tối ưu hóa.

Để xác định xem phiên bản tối ưu hóa của mã có thực sự tốt hơn so với triển khai ngây thơ tại bất kỳ thời điểm nào không, bạn cần phải đánh giá chúng song song với cùng một dữ liệu.

Ngoài ra, hãy nhớ rằng chỉ vì một triển khai nhất định có hiệu quả hơn đối với thế hệ CPU hiện tại, không có nghĩa là nó sẽ luôn như vậy. Câu trả lời của tôi cho câu hỏi Tối ưu hóa vi mô có quan trọng khi mã hóa không? chi tiết một ví dụ từ kinh nghiệm cá nhân trong đó tối ưu hóa lỗi thời dẫn đến một mức độ giảm tốc độ.

Trên nhiều bộ xử lý, truy cập bộ nhớ không được phân bổ sẽ tốn kém hơn đáng kể so với truy cập bộ nhớ được căn chỉnh. Đóng gói một vài quần short vào cấu trúc của bạn có thể chỉ có nghĩa là chương trình của bạn phải thực hiện thao tác đóng gói / giải nén mỗi khi bạn chạm vào một trong hai giá trị.

Vì lý do này, trình biên dịch hiện đại bỏ qua đề xuất của bạn. Như ý kiến ​​của nikie :

Với các cài đặt trình biên dịch đóng gói / căn chỉnh tiêu chuẩn, các biến sẽ được căn chỉnh theo ranh giới 4 byte, do đó có thể không có bất kỳ sự khác biệt nào.

Thứ hai đoán trình biên dịch của bạn lúc nguy hiểm.

Có một nơi để tối ưu hóa như vậy, khi làm việc với bộ dữ liệu terabyte hoặc bộ điều khiển vi mô nhúng, nhưng đối với hầu hết chúng ta, nó không thực sự là một mối quan tâm.

Sự khác biệt chính là int ngắn chiếm 2 byte bộ nhớ trong khi int chiếm 4 byte và int ngắn có giá trị nhỏ hơn, nhưng chúng ta cũng có thể gọi đây là để làm cho nó nhỏ hơn nữa:

Điều này là không chính xác. Bạn không thể đưa ra các giả định về việc mỗi loại giữ bao nhiêu byte, ngoài charviệc là một byte và ít nhất 8 bit cho mỗi byte, cùng với kích thước của mỗi loại lớn hơn hoặc bằng với trước đó.

Các lợi ích hiệu suất cực kỳ nhỏ cho các biến stack - dù sao chúng cũng có thể được căn chỉnh / đệm.

Bởi vì điều này, shortvà longthực tế không sử dụng ngày nay, và bạn hầu như luôn luôn sử dụng tốt hơn int.

Tất nhiên, cũng stdint.hcó thứ hoàn toàn tốt để sử dụng khi intkhông cắt nó. Nếu bạn đã từng phân bổ các mảng số nguyên / cấu trúc khổng lồ thì sẽ hợp intX_tlý khi bạn có thể hiệu quả và dựa vào kích thước của loại. Điều này hoàn toàn không sớm vì bạn có thể tiết kiệm megabyte bộ nhớ.

Điều này sẽ xuất phát từ một loại quan điểm OOP và / hoặc enterprisey / ứng dụng và có thể không áp dụng được trong một số lĩnh vực / lĩnh vực nhất định, nhưng tôi muốn đưa ra khái niệm về nỗi ám ảnh nguyên thủy .

Nên sử dụng các loại dữ liệu khác nhau cho các loại thông tin khác nhau trong ứng dụng của bạn. Tuy nhiên, có lẽ KHÔNG nên sử dụng các loại tích hợp cho việc này, trừ khi bạn có một số vấn đề nghiêm trọng về hiệu suất (đã được đo lường và xác minh, v.v.).

Nếu chúng ta muốn nhiệt độ mô hình trong Kelvin trong ứng dụng của chúng tôi, chúng tôi có thể sử dụng một ushorthoặc uinthoặc một cái gì đó tương tự để biểu thị rằng "khái niệm về độ tiêu cực Kelvin là ngớ ngẩn và một lỗi logic miền". Ý tưởng đằng sau điều này là âm thanh, nhưng bạn sẽ không đi hết con đường này. Điều chúng tôi nhận ra là chúng tôi không thể có các giá trị âm, vì vậy thật tiện lợi nếu chúng tôi có thể có trình biên dịch để đảm bảo không ai gán giá trị âm cho nhiệt độ Kelvin. Điều đó cũng đúng là bạn không thể thực hiện các thao tác bitwise về nhiệt độ. Và bạn không thể thêm số đo trọng lượng (kg) vào nhiệt độ (K). Nhưng nếu bạn mô hình cả nhiệt độ và khối lượng là uints, chúng ta có thể làm điều đó.

Việc sử dụng các loại tích hợp để mô hình hóa các thực thể DOMAIN của chúng tôi bị ràng buộc dẫn đến một số mã lộn xộn và một số kiểm tra bị bỏ lỡ và các bất biến bị hỏng. Ngay cả khi một loại nắm bắt MỘT SỐ phần của thực thể (không thể âm), thì nó vẫn bị bỏ lỡ các phần tử khác (không thể được sử dụng trong các biểu thức số học tùy ý, không thể được coi là một mảng bit, v.v.)

Giải pháp là xác định các loại mới đóng gói các bất biến. Bằng cách này, bạn có thể chắc chắn rằng tiền là tiền và khoảng cách là khoảng cách và bạn không thể cộng chúng lại với nhau và bạn không thể tạo khoảng cách âm, nhưng bạn CÓ THỂ tạo ra một số tiền âm (hoặc nợ). Tất nhiên, các loại này sẽ sử dụng các loại tích hợp bên trong, nhưng đây là bị ẩn khỏi các máy khách. Liên quan đến câu hỏi của bạn về mức tiêu thụ hiệu năng / bộ nhớ, loại điều này có thể cho phép bạn thay đổi cách mọi thứ được lưu trữ bên trong mà không thay đổi giao diện của các chức năng hoạt động trên các thực thể miền của bạn, nếu bạn phát hiện ra rằng, shortthật quá đáng lớn.

Phải, tất nhiên. Đó là một ý tưởng tốt để sử dụnguint_least8_t cho từ điển, mảng hằng số lớn, bộ đệm, vv Tốt hơn là sử dụng uint_fast8_tcho mục đích xử lý.

uint8_least_t (lưu trữ) -> uint8_fast_t (xử lý) -> uint8_least_t(lưu trữ).

Ví dụ: bạn đang lấy ký hiệu 8 bit từ source, mã 16 bit dictionariesvà một số 32 bitconstants . Hơn bạn đang xử lý các hoạt động 10-15 bit với chúng và xuất ra 8 bit destination.

Hãy tưởng tượng rằng bạn phải xử lý 2 gigabyte source. Số lượng hoạt động bit là rất lớn. Bạn sẽ nhận được tiền thưởng nước hoa tuyệt vời nếu bạn sẽ chuyển sang loại nhanh trong quá trình xử lý. Các loại nhanh có thể khác nhau cho mỗi họ CPU. Bạn có thể bao gồm stdint.hvà sử dụng uint_fast8_t,uint_fast16_t , uint_fast32_tvv

Bạn có thể sử dụng uint_least8_tthay vì uint8_tcho tính di động. Nhưng không ai thực sự biết những gì cpu hiện đại sẽ sử dụng tính năng này. Máy VAC là một mảnh bảo tàng. Vì vậy, có thể nó là một quá mức cần thiết.