Raspbian ย้ายไปที่โหมด 64- บิต


52

ในหน้านี้ประกาศสถานะ RPi3 อย่างเป็นทางการ:

คุณจะต้องมีภาพ NOOBS หรือ Raspbian ล่าสุดจากหน้าดาวน์โหลดของเรา ตอนเปิดตัวเรากำลังใช้ userland Raspbian แบบ 32 บิตเดียวกับที่เราใช้กับอุปกรณ์ Raspberry Pi อื่น ๆ ในอีกไม่กี่เดือนข้างหน้าเราจะตรวจสอบว่ามีค่าในการย้ายไปยังโหมด 64 บิตหรือไม่

คำถามของฉันคือเนื่องจากตัวประมวลผล 64 บิตไม่ชัดเจนว่าการใช้งานระบบปฏิบัติการใน 64 บิตจะดีขึ้นในทุก ๆ ทางหรือไม่ ฉันพลาดอะไรไป


9
ฉันเคยทำงานให้กับ บริษัท ที่โอนซอฟต์แวร์จาก 32 บิตเป็น 64 บิต OSF ใน DEC / Alpha (เมื่อนานมาแล้ว) เพียงคอมไพล์ซ้ำอีกครั้งเนื่องจาก codebase นั้นเป็นไปตามมาตรฐาน 64 บิตแล้ว ผลการดำเนินงาน 10% ได้รับผลกระทบจากปริมาณการใช้หน่วยความจำเพิ่มเติมในจำนวนเต็มและพอยน์เตอร์ นี่คือย้อนกลับไปในวันที่ประสิทธิภาพการทำงานถูกวัดในหน่วยความจำสามหลัก mhz และสองเท่า (อาจต่ำสาม) ความทรงจำหลัก โดยไม่ต้องมี RAM บนบอร์ด 4+ GB ไม่จำเป็นต้องเป็นความคิดที่ดี
Chris K

6
64 บิตก่อนจ่ายออกด้วยหน่วยความจำมากกว่า Pi มี
Thorbjørn Ravn Andersen

2
บนระบบที่ใช้ x86 ความยากในการตัดสินใจว่าสิ่งนี้ทำให้ลูกผสม abi: en.wikipedia.org/wiki/X32_ABIซึ่งใช้ตัวชี้ 32 บิตและการลงทะเบียนซีพียู 64 บิต
PlasmaHH

1
@ChrisKaminski แต่ ARM และ x86 นั้นแตกต่างกัน เมื่อพวกเขาไปจาก 32 ถึง 64 บิตพวกเขาสองเท่าของจำนวนการลงทะเบียนและออกแบบใหม่บางแง่มุมของชุดคำสั่งที่ทำให้โค้ดทำงานได้เร็วขึ้นในกรณีส่วนใหญ่ คุณสามารถดูเกณฑ์มาตรฐานจำนวนมากได้บนอินเทอร์เน็ต
phuclv

@rsaxvc ดังนั้นสิ่งที่เพิ่มความคิดเห็นของฉันคืออะไร ผมบอกว่า "ARM และ x86" จะบอกว่าในสถาปัตยกรรมผู้ที่จะ 64 บิตช่วยเพิ่มประสิทธิภาพของแอพลิเคชันซึ่งแตกต่างจากสถาปัตยกรรมอื่น ๆ เช่น Dec / อัลฟาหรือ Sparc, MIPS และ ...
phuclv

คำตอบ:


62

เนื่องจากโปรเซสเซอร์เป็น 64 บิตไม่ชัดเจนว่าการใช้งานระบบปฏิบัติการ 64 บิตจะดีกว่าในทุก ๆ ด้านใช่หรือไม่

ไม่จริงมันไม่ใช่ ในบางวิธีการใช้ระบบปฏิบัติการ 64 บิตอาจทำให้ประสิทธิภาพของ Raspberry Pi แย่ลง

ประโยชน์ของ 64 บิต :

ประโยชน์หลักสองประการของการใช้ตัวประมวลผล / ระบบปฏิบัติการ 64 บิตคืออุปกรณ์สามารถจัดการ RAM มากกว่า 4 GB และจัดการกับจำนวนเต็มที่ใหญ่กว่า2^32โดยไม่จำเป็นต้องใช้ไลบรารี bignum

Raspberry Pi ไม่มี RAM มากกว่า 4 GB ที่ RAM ขนาด 1 GB คุณสูญเสียสิทธิประโยชน์ทั้งสองอย่างแรกไปโดยสิ้นเชิง สำหรับประโยชน์ที่สองคนที่ใช้จำนวนมากพอสมควรที่จะใช้ระบบปฏิบัติการที่สองคืออะไร ตามที่ RPi สามารถใช้เป็นจำนวนมากผ่านวิธีการซอฟต์แวร์ แต่ดูเหมือนว่าถ้าคุณจะอยู่ในขอบเขตนั้นอย่างสม่ำเสมอคุณจะต้องใช้ฮาร์ดแวร์ที่ดีกว่าอยู่ดี

มีปัญหากับ 64 บิต :

ความสามารถในการเก็บจำนวนที่มากขึ้นนั้นไม่ได้เกิดจากเวทมนตร์ แต่ขนาดของวัตถุหน่วยความจำจะต้องเพิ่มขึ้น ใน C (และ C ++) ที่นี้หมายถึงการเปลี่ยนไปint int64_tสิ่งนี้ไม่ได้ทำโดยอัตโนมัติดังนั้นความคิดเห็นเกี่ยวกับมูลนิธิที่ไม่ต้องการรักษาสองสาขา

นอกจากนี้แอปพลิเคชันจำนวนมากไม่ได้ให้ประโยชน์ (สำหรับผู้ใช้ส่วนใหญ่) เมื่อทำงานในโหมด 64 บิต โปรดสังเกตว่าเว็บเบราว์เซอร์ส่วนใหญ่, MS Office และโฮสต์ทั้งหมดของซอฟต์แวร์ยอดนิยมอื่น ๆ ทั้งหมดนั้นยังคงมีการจัดส่งและดูแลในรูปแบบ 32 บิต แน่นอนว่าคุณสามารถใช้ MS Office รุ่น 64 บิตได้ แต่ก็ไม่ค่อยได้ใช้

หากเขียนแอปพลิเคชัน / ระบบปฏิบัติการเพื่อใช้ประโยชน์จากสถาปัตยกรรม 64 บิตแอปพลิเคชันของคุณจะใช้หน่วยความจำเพิ่มขึ้นเพียงเพราะตัวแปรและตัวชี้กำลังเพิ่มพื้นที่ว่าง โดยปกติจะเป็นการแลกเปลี่ยนที่ค่อนข้างเล็กสำหรับเครื่องจักรที่จะได้รับประโยชน์จาก perks ในกรณีของเราเรามี perks น้อยมากและ RAM น้อยมาก

ยังทราบ :

เพียงเพราะคุณกำลังทำงานบนเครื่อง 64 บิตไม่ได้หมายความว่าแอปพลิเคชันไม่ได้ทำงานเป็น 32 บิต หน้าต่างนี้จะทำให้ชัดเจนมากโดยมีสองเส้นทางการติดตั้งที่แตกต่างกันและC:\Program FilesC:\Program Files (x86)

ดังนั้นมูลนิธิจะให้การสนับสนุน 64 บิตหรือไม่ :

เรากลับมาที่จุดเดียวกันของ "บางคนอาจเห็นประโยชน์ แต่ส่วนใหญ่จะไม่" คุณจะเห็นโครงการอื่น ๆ ที่มีการสร้างแบบ 64 บิต แต่หากมูลนิธิไม่ได้รับจำนวนมาก (IMO) ที่ไม่สมควรพวกเขาอาจจะไม่และไม่ควร (IMO) การสร้างและรักษาสาขา 64 บิตแยกต่างหากไม่ใช่ความพยายามเพียงเล็กน้อยและโดยสุจริตดูเหมือนจะไม่คุ้มค่า


7
สมมติว่าคุณพูดถึง C และเพื่อน ๆ ขนาดของประเภทใด ๆ <= int ยังคงเหมือนเดิม size_t และพอยน์เตอร์เพิ่มขนาดตามความยาวภายใต้โมเดลที่อยู่ของ Linux คุณพลาดจุดพื้นที่ที่อยู่เสมือนอย่างสมบูรณ์ซึ่งสำคัญเมื่อคุณทำการแมป I / O หน่วยความจำ

3
ไม่ใช่ขั้นสูงที่จะสร้างความแตกต่างระหว่างจำนวนหน่วยความจำกายภาพและหน่วยความจำเสมือน มันยังไม่ก้าวหน้าที่จะไม่เผยแพร่ข้อมูลที่ผิด sizeof(char)เป็นหนึ่งเสมอ ภายใต้ Linux, sizeof(short), sizeof(int), sizeof(float), sizeof(double)ไม่แตกต่างกันกับ bitness นั่นมีความแตกต่างที่สำคัญในการเรียกร้องของคุณ

11
ฉันมีปัญหากับการใช้x64คำตอบนี้ เป็นคำย่อของx64 x86-64นี่ไม่ใช่คำพ้องกับ "64 บิต" 64 บิตซีพียู ARM AArch64เป็น
Oli

6
มีข้อดี 64 บิตมากกว่าที่คุณระบุไว้ มีข้อได้เปรียบด้านประสิทธิภาพสำหรับ ARM64หรือไม่en.wikipedia.org/wiki/64-bit_computing#Pros_and_cons
phuclv

3
คุณพลาดเหตุผลที่ยิ่งใหญ่ที่สุดในการเปลี่ยนมาใช้ระบบปฏิบัติการ 64 บิต 19 มกราคม 2038 Linux 32 บิตไม่สามารถจัดการกับวันที่ผ่านมาได้ การแก้ไขเป็น Linux 64 บิต (และอัปเกรดซอฟต์แวร์ใด ๆ ตามเวลา 32 บิต unix) สักพัก 2038 อยู่ห่างออกไป 20 ปีแล้ว แต่ Raspberry Pi ซึ่งเป็นเครื่องฝังตัวขนาดเล็กมีศักยภาพที่จะใช้งานได้ในอนาคต ไม่มีใครทำปัญหา Y2K อย่างจริงจังในปี 1980 เช่นกัน
Steve Sether

19

เป็นที่น่าสังเกตว่าสถานการณ์นั้นแตกต่างกันสำหรับ ARM และ Intel / AMD นั่นเป็นเพราะสวิตช์เป็น x86_64 ยังถูกใช้เป็นโอกาสในการอัปเดตสถาปัตยกรรมที่ไม่ดีแก่ผู้สูงอายุโดยทั่วไปแล้วมีเพียง 8 รีจิสเตอร์วัตถุประสงค์ทั่วไปเท่านั้นและเพิ่มเป็นสองเท่าในโหมด 64 บิต ดังนั้นการเปลี่ยนระบบ Intel / AMD เป็นโหมด 64 บิตยังหมายถึงการเปิดใช้คุณสมบัติที่แท้จริงซึ่งสร้างความแตกต่างอย่างมากในประสิทธิภาพ

ARM ไม่มีปัญหานี้ในการเริ่มต้น (แม้ว่า AArch64 จะเพิ่มการลงทะเบียนแต่ทว่าสถาปัตยกรรมแบบ 32 บิตไม่ได้ถูกอดอาหาร) ดังนั้นข้อดีก็คือหน่วยความจำที่สามารถระบุตำแหน่งได้โดยตรงมากกว่าและการสนับสนุนจำนวนเต็มขนาดใหญ่ จัดการและอาจต่อต้านโดยข้อเสีย (หน่วยความจำเพิ่มเติมที่ใช้สำหรับทุกอย่าง)

(นอกจากนี้ด้วยเหตุผลนี้มีงานบางอย่างในการสร้าง"x32" abi สำหรับ Intel / AMD Linuxทำให้การปรับปรุง CPU แต่ใช้ตัวชี้แบบ 32 บิต)


5
แม้ว่า AArch32 จะมีการลงทะเบียนมากกว่า x86 แล้ว แต่ AArch64 ก็ทำได้ดีกว่าเพราะตอนนี้มี SP และ PC แยกต่างหาก ก่อนที่คุณจะมีการลงทะเบียนโดยทั่วไปไม่เกิน 14 ครั้ง นอกจากนี้คุณยังมีชุดคำสั่งที่ออกแบบมาดีกว่ามีคำแนะนำเกี่ยวกับประสิทธิภาพของ ARM64 , 64-bit ARM (Aarch64) เพิ่มประสิทธิภาพการทำงาน 15 ถึง 30% เมื่อเทียบกับคำแนะนำ ARM 32-bit (Aarch32)
phuclv


มันจะน่าสนใจที่จะเห็นเกณฑ์มาตรฐานใน Pi3 (โดยเฉพาะกับงานในโลกแห่งความเป็นจริง)
mattdm

6

ฉันแน่ใจว่ามีผู้ใช้ Debian Aarch64 (ARMv8) บน Pi 3 อยู่แล้ว แน่นอนว่ามันคงไม่ยากสำหรับหลาย ๆ คน ( ดูที่นี่สำหรับเบาะแสบางอย่างเกี่ยวกับสิ่งที่อาจใช้งานได้) 1ถึงแม้ว่าสำหรับผู้ใช้ส่วนใหญ่

อย่างไรก็ตามหาก Raspbian และ / หรือ Foundation ไม่ออกมาพร้อมกับรุ่น 64 บิตคุณจะเห็นคนที่มีบล็อกและอื่น ๆ เพิ่มขึ้นเรื่อย ๆ อธิบายวิธีเรียกใช้และยังคงได้รับสินค้าที่คุณต้องการ


ขณะนี้มีการเปิดตัว Fedora aarch64สำหรับ Pi 3


1. จะมีปัญหาบางอย่างกับ/opt/vcสิ่งของ32 บิตฉันไม่แน่ใจว่าเอาชนะได้อย่างไร เคยเป็น libs ที่เข้ากันได้ 32- บิตสำหรับ x86-64 แต่ Aarch64 ... อาจจะไม่


1
raspbian.org/RaspbianFAQ#What_is_Raspbian.3Fกล่าวถึง ( จำเป็นต้องพูดถึง Raspbian): พอร์ตจำเป็นเพราะ Debian Whhzy Armhf อย่างเป็นทางการจะเข้ากันได้กับสถาปัตยกรรม ARM รุ่นที่ใหม่กว่า Raspberry Pi (ARMv7-A เท่านั้น) และสูงกว่าเทียบกับ CPU ARMv6 ของ Raspberry Pi สิ่งนี้ยังคงเป็นจริงสำหรับ RPi3 หรือไม่?
zundi

@Sandy ฉันคิดว่าเป็น 1) ค่อนข้างโบราณ; 2) สับสนและ / หรือไม่ถูกแก้ไขตั้งแต่นั้นเนื่องจาก Debian armhf ถูกคอมไพล์ด้วยโฟลตอย่างหนักนั่นคือสิ่งที่ hf ใช้สำหรับและมีเดเบียนอีกหนึ่งตัวสำหรับ ARMv4 / 5 ที่ฉันคิดว่าเป็นตัวแรกที่ใช้กับ ISA มีทุ่นลอย (ฉันคิดว่าไม่มีเลข 6 จนกระทั่งถึงจุดหนึ่ง แต่มันเป็นแบบนั้นตลอดเวลานั่นคือ ARM1176JZ (F) -S) ดังนั้นจึงมี Raspbian รุ่นเดียว, คาบ, ARMv6 พร้อมการสนับสนุนจุดลอยตัวของฮาร์ดแวร์ความแตกต่างเพียงอย่างเดียวระหว่างรุ่น A / B / + / 0 และ 2 คือเคอร์เนลที่ใช้ดังนั้นน่าจะเป็นเช่นเดียวกันกับ 3
goldilocks

2
... "armel" เป็นเดเบียนที่ไม่ใช่ hf ที่ใช้ก่อน Raspbian
goldilocks

@Sandy ที่ประโยคถูกเขียนขึ้นในวันที่ของ pi1 ดังนั้นเมื่อมันบอกว่า pi มันหมายถึงสิ่งที่เราจะเรียกว่า pi1 มีบุคคลที่สามที่ปล่อยภาพ armhf debian สำหรับ pi2 (และสันนิษฐาน pi3) แต่ rpf ได้ตัดสินใจที่จะติดกับภาพหนึ่งภาพสำหรับบอร์ดทั้งหมดในตอนนี้
ปีเตอร์กรีน

5

ในฐานะที่เป็นส่วนหนึ่งของการเปิดตัวโฆษณาฉันเห็นว่าข้อกังวลประการหนึ่งคือความพยายามในการรักษาฐานรหัสสองชุดแยกกัน (32 และ 64 บิต) วิดีโอการเปิดตัว Adafruit PI3 ยังกล่าวอีกว่าการย้ายไปยังตัวประมวลผล 64 บิตเป็นเรื่องเกี่ยวกับความเร็วสัญญาณนาฬิกาเพิ่มชิปใหม่ที่มีให้มากกว่าการใช้โหมด 64 บิต


ฉันคิดว่าโค้ดจะเหมือนกัน แต่คอมไพเลอร์จะรับผิดชอบในการปรับโค้ดสุดท้ายเพื่อใช้ประโยชน์จากสถาปัตยกรรม มันค่อนข้างง่ายที่จะสร้างงานสร้างใหม่หรือไม่? พูดว่าให้เรียกใช้ Debian ใน 64 บิต?
zundi

@Sandy Easy จะขึ้นอยู่กับระดับความสามารถและประสบการณ์ของคุณ กรณีการใช้งานที่ต้องการในตอนนี้คืออะไร?
Steve Robillard

ไม่มีใครต้องการเพียงแค่เพิ่มประสิทธิภาพสูงสุดที่ RPi3 สามารถทำได้
zundi

@sandy มูลนิธิได้กล่าวว่าการแทนที่ Pi3 จะไม่มาเร็วเท่า Pi3 ตามด้วย Pi2 (ประมาณ 1 ปี) พวกเขาอาจใช้สวิตช์เป็น 64 บิตเพื่อประสิทธิภาพการทำงานโดยไม่ต้องใช้ฮาร์ดแวร์ใหม่ - หมายเหตุนี่เป็นการเก็งกำไรในส่วนของฉัน
Steve Robillard

4

การกำหนดแอดเดรส 64- บิตจะมีประโยชน์แม้ว่าคุณจะไม่มีหน่วยความจำมากกว่า 1GB

ช่วยให้คุณสามารถแมปไฟล์ขนาดใหญ่ของหน่วยความจำเพื่อให้คุณมีตัวชี้และให้ระบบปฏิบัติการทำ I / O โปร่งใส อีกวิธีหนึ่งในการทำ I / O คุณต้องมีที่อยู่ 64 บิตเพื่อดำเนินการนี้กับไฟล์ขนาดใหญ่

อีกตัวอย่างที่ฉันเห็นว่ามันมีประโยชน์คือการอนุญาตให้กระบวนการมีพื้นที่แอดเดรสมากกว่า 2GB โดยใช้พื้นที่สว็อป ฉันเพิ่งมีปัญหากับ NAS แบบ 32 บิตที่มีพื้นที่เก็บข้อมูลมากมายและระบบไฟล์ที่เสียหาย กระบวนการ fsck มีหน่วยความจำไม่เพียงพอแม้เปิดใช้งานตัวเลือกการแคชแล้ว การเพิ่มพื้นที่สว็อปไม่สามารถแก้ปัญหาได้พื้นที่ที่อยู่แบบ 32 บิตเป็นขีด จำกัด ที่ยาก ดังนั้นจึงไม่มีทางที่จะเรียกใช้ fsck บนระบบไฟล์ขนาดใหญ่ที่เสียหายด้วยไบนารีแบบ 32 บิต ด้วยไบนารี 64 บิตและพื้นที่สว็อปบางส่วนมันจะทำงานได้


3

การยืนยันว่าโปรแกรมเนทีฟ 64 บิตนั้นมีขนาดใหญ่กว่า (หน่วยความจำเพิ่มเติมสำหรับข้อมูลและพอยน์เตอร์) และไม่มีประโยชน์ใด ๆ ที่เห็นได้ชัดเจนสำหรับระบบปฏิบัติการ 64 กับ 32 บิตบน ARMv8 ที่มี RAM น้อยกว่า 4GB จุด

มีความแตกต่างที่สำคัญในการทำสิ่งต่าง ๆ ใน ARMv7 (และก่อนหน้านี้) และ ARMv8 ซึ่งเป็นสถาปัตยกรรมที่ทำให้การดำเนินการ ARMv8 มีประสิทธิภาพมากขึ้น บางส่วนนี้มาจากเส้นทางข้อมูลภายในที่กว้างขึ้นบางส่วนเป็นการกำจัดกรณีพิเศษและไปป์ไลน์ที่ลึกกว่ามาก) การเปลี่ยนแปลงแบบเดียวกันนี้ทำให้ ARMv8 ทำงานได้ดีกว่าในการรันโค้ด ARMv7 (32 บิต)

แอปพลิเคชันเนทีฟ 64 บิตใช้พอยน์เตอร์ 64 บิตและ 'size_t' คือ 64 บิตดังนั้นองค์ประกอบที่ใช้สิ่งเหล่านั้นจะใหญ่ขึ้น ส่วนที่เหลือของข้อมูลจะมีขนาดเท่าเดิม อย่างไรก็ตามความสำคัญของสิ่งนี้คือเล็กน้อยตามขนาดของอิมเมจที่ใช้งานได้

ที่ 64 บิตเนทิฟส่องแสงจริงๆ (ถ้าคุณไม่สนใจเรื่องจำนวนเต็มและจำนวนจุดลอยตัว) จะมีพื้นที่ที่อยู่เสมือนที่ใหญ่กว่า:

  • ระบบปฏิบัติการสามารถแบ่งพื้นที่ที่อยู่เสมือนออกเป็นส่วน ๆ ได้มากขึ้นช่วยให้การจัดการทรัพยากรที่ใช้ร่วมกันง่ายขึ้นการสลับบริบทที่มีความคล่องตัวยิ่งขึ้นระหว่างระดับสิทธิ์ที่แตกต่างกันและอื่น ๆ
  • หากคุณเปิดใช้งานการสลับคุณสามารถเรียกใช้กระบวนการมากขึ้นและมากขึ้นเกินขีด จำกัด หน่วยความจำฟิสิคัล (จริง ๆ แล้วเป็นจริงใน 32 บิตเช่นกัน แต่คุณ จำกัด น้อยกว่าใน 64 บิต)

ไม่ว่าระบบปฏิบัติการปัจจุบันจะใช้ประโยชน์จากสิ่งนี้หรือไม่มันจะสร้างความแตกต่างเมื่อกระแสหลักเคลื่อนตัวออกจาก 32 บิต

ฉันคิดว่าอาร์กิวเมนต์ที่ดีที่สุดสำหรับการย้ายไปใช้เคอร์เนล AArch64 แบบ 64 บิตคือความสามารถในการพกพา: เดสก์ท็อปหลักได้ย้ายไปเป็นโปรเซสเซอร์ 64 บิตเป็นส่วนใหญ่และฉันเห็นแพ็คเกจเพิ่มเติมที่ถือว่า 64 บิตและการย้ายรหัสดังกล่าว กว่าพอร์ตจาก 32 ถึง 64 บิต ในพื้นที่ผู้ใช้คุณสามารถเรียกใช้แอปพลิเคชัน 32 บิตและแอปพลิเคชัน 64 บิตเคียงข้างกันโดยสมมติว่าคุณได้ติดตั้งไลบรารีหลายอาร์คแล้วดังนั้นจึงไม่จำเป็นต้องใช้พอร์ต 32 ถึง 64 บิต เรื่อง. ระบบปฏิบัติการ 64 บิตเป็นเพียงการให้ซอฟต์แวร์ที่มีขนาดใหญ่ขึ้น

ฉันไม่ได้บอกว่าการผลิตเคอร์เนล 64 บิตสำหรับ Raspberry PI 3 นั้นเป็นเรื่องง่าย - มีความแตกต่างที่สำคัญที่ต้องมีการเปลี่ยนแปลงในระดับต่ำไม่ใช่ไดรเวอร์อุปกรณ์ทั้งหมดจะสะอาด 64 บิต (โดยเฉพาะไดรเวอร์สำหรับ GPU เฉพาะ ARM) อาจเป็นได้ว่า Raspberian จะยังคงใช้ระบบปฏิบัติการ 32 บิตได้ แต่ฉันเชื่อว่า (ในระยะยาว) นั้นจะเป็นสายตาสั้น

สื่อการบู๊ตเดี่ยว (เช่นการ์ด SD) สามารถมีทั้งระบบปฏิบัติการเวอร์ชัน 64 และ 32 บิตและซอฟต์แวร์การบู๊ตสำรอง (u-boot, arm-boot และอื่น ๆ ) สามารถกำหนดได้ว่าจะโหลดแบบใด ส่วนที่ยากขึ้นคือ userland - ระบบไฟล์จะต้องเป็นแบบ multi-arch แม้กระทั่งในระบบ 32 บิตซึ่ง 64 บิตนั้นจะไร้ประโยชน์ ฉันจะแก้ไขปัญหานี้ด้วยสคริปต์หรือยูทิลิตี้ที่สามารถรันได้หลังจากการบู๊ตครั้งแรกเพื่อลบไลบรารีที่ไม่จำเป็นและโปรแกรมที่เรียกใช้งานได้บนระบบ 32 บิตเท่านั้น


บางทีเราต้องการ x32 ABI สำหรับ ARM จากนั้นเราสามารถมีตัวชี้ขนาดเล็กและทะเบียนทั้งหมด
rsaxvc

2

คำตอบที่มีอยู่ครอบคลุมปัญหาของ arch 64 บิตได้เป็นอย่างดี แต่ฉันไม่เห็นข้อดีหลายประการของการอัพเกรด ดังนั้นนี่คือสองฉันเพิ่งค้นพบ:

  • เมื่อ PHP จัดการ timestamps Unix ขนาดจำนวนเต็มในโค้ง 32 บิตกำหนดขีด จำกัด บนในวันดังกล่าวว่าพวกเขาไม่สามารถไปได้ไกลกว่าวันใดวันหนึ่งใน 2038 ฉันคาดหวังว่านี่เป็นปัญหาสำหรับทุกภาษาที่จัดการกับการประทับเวลา (โชคดีที่ระบบย่อยการจัดการวันที่ส่วนใหญ่ที่ไม่ได้ใช้ Unix timestamps เช่น DateTime ของ PHP ได้รับการออกแบบมาโดยเฉพาะเพื่อไม่ให้ถูก จำกัด ด้วยปัญหานี้แม้จะอยู่บน CPU รุ่นเก่า)
  • Mongo ถูก จำกัด ไว้ที่ฐานข้อมูลที่มีขนาดต่ำกว่า 2G บนซุ้มประตูนี้และการสร้าง 32- บิตจะเลิกใช้เร็ว ๆ นี้ จากคู่มือ :

    เริ่มต้นใน MongoDB 3.2 ไบนารี 32 บิตจะถูกคัดค้านและจะไม่สามารถใช้งานได้ในรุ่นต่อไป

    แม้ว่าบิวด์ 32 บิตนั้นมีอยู่สำหรับ Linux และ Windows แต่ก็ไม่เหมาะสมสำหรับการปรับใช้ในการผลิต บิลด์ 32 บิตไม่สนับสนุนเอ็นจิ้นการเก็บข้อมูล WiredTiger


แปลกขึ้นอยู่กับแพลตฟอร์มของคุณ โดยปกติแล้วจะไม่ใช่ขนาดจำนวนเต็ม แต่ขนาด time_t ในไลบรารี 'C' แม้แต่บนแพลตฟอร์ม 32 บิตก็เป็นไปได้ที่จะใช้ time_t 64- บิตกับโอเวอร์เฮดเวลา CPU บางตัว แต่แพลตฟอร์ม 32 บิตจำนวนมากยังไม่สามารถทำได้เนื่องจากมีปัญหาความเข้ากันได้ของไบนารีในการทำเช่นนั้น
rsaxvc

@rsaxvc น่าสนใจขอบคุณ ดังนั้นฉันจะได้รับ 64-bit-time-handling โดยการคอมไพล์ PHP ใหม่หรือจะต้องแก้ไขไลบรารี C พื้นฐานด้วยเช่นกัน? อดีตจะอยู่ในความสามารถของฉัน แต่ไม่แน่ใจเกี่ยวกับหลัง - ฉันกำลังไตร่ตรอง reassiling ทั้งหมดของ Ras [bian เองด้วย แต่ดูเหมือนจะไม่มีคำแนะนำง่าย ๆ ให้ทำ (ยังไงก็ตาม)
halfer

สำหรับ Linux คุณต้องแก้ไขเคอร์เนล libc และแอปพลิเคชันของคุณ มันอาจจะไม่คุ้มค่า หลังจากอ่านเสร็จ OpenBSD (ไม่ใช้ RPi) time_t คือ 64- บิตตั้งแต่ 5.5 บน Windows 32 บิตโดยใช้ Visual Studio 2005 หรือใหม่กว่า time_t คือ 64- บิต
rsaxvc

@rsaxvc: เอาล่ะขอบคุณ ฉันสงสัยว่ามันสมเหตุสมผลหรือไม่ที่ฉันจะต้องรอระบบปฏิบัติการ 64 บิต - มันฟังดูใกล้ ๆ กับบทความข่าวไม่กี่เดือนที่ผ่านมา ....:-)
halfer

-4

ความคิดของฉันเกี่ยวกับเรื่องนี้: แม้ว่าฉันไม่ทราบว่าหน่วยประมวลผล ARM ระบุหน่วยความจำอย่างไรฉันสามารถบอกคุณได้จากสถาปัตยกรรม CPU หลายตัวก่อนหน้านี้ที่ฉันตั้งโปรแกรมไว้ (SPARC / Alpha / i386 / AMD64 / X86_64): เมื่อใช้หน่วยความจำร่วม ด้วยตัวชี้ที่อยู่เสมือน "ของจริง" การย้ายไปยัง 64 บิตนั้นไม่สำคัญ แม้ว่า memcpy ทำในสิ่งที่ควรทำคุณต้องคำนึงว่าใน 64 บิตข้อมูลจะถูกเก็บไว้เช่นนี้ (บิตไปข้างหลัง):

HGFEDCBA
HGFEDCBA
HGFEDCBA

แต่ใน 32 บิตดูเหมือนว่านี้:

ABCD
ABCD
ABCD

ดังนั้นใน 32 บิตเมื่อคุณจัดเก็บพูด jpeg ใน RAM คุณสามารถอ่านไบต์ส่วนหัวของมันหรือทำการตรวจจับขอบโดยไม่มีปัญหาใด ๆ ในแบบเชิงเส้น * พูดโดยไปไบต์ต่อไบต์ แต่ในสถาปัตยกรรม 64 บิตการเปลี่ยนแปลงนี้:

32bit:

for (i=0; i< img_length/4; i++) 
{ 
    address=shm_start+i; 
    for (c=0; c< 4; c++) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

64bit:

for (i=-; i< img_length/8; i++) 
{ 
    address=shm_start+i; 
    for (c=7; c>=0; c--) 
    { 
        byte=((*address >> c) & 15) 
    } 
}

5
Endianness ไม่เกี่ยวข้องกับขนาดของคำ Heck, สถาปัตยกรรมจำนวนมากอนุญาตให้โปรแกรมเมอร์เลือก endianness รวมถึง ARM! นอกจากนี้ "64 บิต" อาจมีผลที่แตกต่างกันโดยสิ้นเชิงขึ้นอยู่กับสถาปัตยกรรมที่มีปัญหาและเป็นการยากที่จะเปรียบเทียบข้ามสถาปัตยกรรมหรือพยายามวาดความคล้ายคลึงกันระหว่างพวกเขา
Bob

1
ฉันไม่คิดว่า i = - ถูกต้อง
rsaxvc
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.