64 bit makinelerde 64 bit yerine 32 bit yazılımı çalıştırmak için iyi bir neden var mı?

56

64-bit donanım üzerinde modern 64-bit işletim sistemleri çalıştıran, modern masaüstü makinelere yönelik herhangi bir yazılımın 64-bit sürümü ile birlikte 32-bit bir sürüm sağlamak için iyi bir neden var mı?

Görünüşe göre 64-bit yazılım daha verimli olacak, gerektiğinde daha yüksek bellek kullanımına izin verecek vs. gibi görünüyor. Apple, 4 GB’ın altında 1-2 GB RAM’e sahip olsalar bile, telefonları için 64 bit işlemciler kullanıyor. 32 bit işlemciler için limit.

hardware 64-bit 32-bit

— Filip Haglund
kaynak

16

Her modern makine 64 bit işletim sistemi

— kullanmıyor

4

Hiç örneğin var mı?

— Filip Haglund

8

Müşterilerinize sorun.

— Murphy,

22

Retorik soru: çoğu modern 64bit işletim sistemi 32bit ve 64bit uygulamalarını çalıştırmaya izin verdiği için herhangi bir yazılımın 64 bit sürümünü sağlamanın bir nedeni var mı?

— Doktor Brown,

2

Yinelenen bir @gnat değil. Bu soru, bir zaman damgası koymakla ilgili ve bir program çıktığında hata kodunda bir geliştirici kimliği ile ilgili.

— Filip Haglund

80

64 bit ortamlarda 32 bit yazılımın avantajları

Daha düşük bellek kaplama alanı, özellikle işaretçi ağırlıklı uygulamalarda, 64 bit vs 32 bit, bellek gereksinimlerini kolayca ikiye katlayabilir.
Nesne dosyaları da daha küçüktür.
32 bit ortamlarla uyumluluk.
Bellek sızıntıları 2 GB, 3 GB veya 4 GB'a kadar zorlanır ve tüm sistemi değiştirmez.

64 bit ortamlarda 32 bit yazılımın sakıncaları

İşlem başına 2 GB, 3 GB veya 4 GB bellek sınırı. (Yalnızca işlem başına, toplamda birden fazla 32 bit işlem kullanılabilir tam sistem belleğini kullanabilir.)
X64'e bağlı olarak ek kayıtlar ve komut seti uzantıları kullanmamak. Bu oldukça derleyici ve CPU'ya özgüdür.
Tüm (çoğu Linux dağıtımları) veya nadir (çoğu Windows sürümleri) kitaplıklarının ve çalışma zamanı ortamlarının 32 bit sürümlerini gerektirebilir. Paylaşılan bir kütüphanenin 32 bit sürümü yalnızca uygulamanız için yüklüyse ve bu, ayak izinize göre sayılır. Statik olarak bağlanıyorsanız hiçbir fark yoktur.

Diğer görüşler

Sürücüler genellikle bir sorun değildir. Yalnızca kullanıcı alanı kütüphaneleri, çekirdek modüllerinin API'sini değil, 32 bit ve 64 bit arasında farklılık göstermelidir.
Tam sayı veri türleri için farklı varsayılan genişliklere dikkat edin, ek test gerekir.
64 bit CPU mimarisi 32 bit bile desteklemeyebilir.
ASLR ve diğerleri gibi belirli teknikler , fiziksel bellekten çok daha büyük bir adres alanına bağlı olarak, 32 bitlik bir yürütme modunda iyi çalışmaz (veya hiç).

Burada çok spesifik bir CPU mimarisi, işletim sistemi ve kütüphane altyapısını karşılaştırmazsak, daha fazla ayrıntıya giremem.

— Ext3h
kaynak

8

"64bit CPU mimarisi 32bit'i bile desteklemeyebilir." Bu daha teorik bir endişe mi, yoksa dünyada var mı?

— mucaho

10

@mucaho kesinlikle yoktur olmuştur böyle Alpha ve IA64 gibi 64-bit okunur işlemci mimarileri,. Her ikisi de olsa, can sıkıcıdır. Şu anda sadece 64-bit üretilmiş mimarilerin olup olmadığını, kafamın tepesinden bilmiyorum - belki AArch64? 32-bit ARM'in zorunlu bir bileşeni olup olmadığını bilen var mı?

— zwol,

10

@zwol Hayır, ARM için 32 bit zorunlu değildir ve ikisi de 64 bit değildir. Sadece 64 bit ARM ARM'ler varken, diğerleri hem 32 bit hem de 64 bit işlemleri desteklemektedir.

— Ext3h

3

Bir mimariyi seçip yapışmanın ek bir faydası var: daha basit geliştirme ve test etme.

— 16'da

7

@Joshua Her zaman var mıydı? Firavunlar bunu biliyor mu?

— candied_orange

7

32 bit yazılım ve 64 bit yazılım arasındaki fark, işaretçilerin boyutu ve belki de tamsayı yazmaçların boyutudur. Bu kadar.

Bu, programınızdaki tüm işaretçilerin boyutunun iki katı olduğu anlamına gelir. Ve (en azından bir ILP32 / LP64 mimarisinde) longs de iki katı büyüklüğünde. Bu genellikle nesne kodu boyutunda yaklaşık% 30 artışla sonuçlanır. Bu şu demek …

nesne kodunuzun diskten RAM'e yüklenmesi ~% 30 daha uzun sürer
nesne kodunuz bellekte ~% 30 daha fazla yer kaplar
Hafıza bant genişliğini (nesne kodu için) etkin bir şekilde ~% 20 düşürdün.
Öğretim önbelleğinin boyutunu etkili bir şekilde ~% 20 azaltdınız

Bunun performans üzerinde ihmal edilemez bir olumsuz etkisi var.

Bunu yapmak yalnızca, bu performans maliyetlerini bir şekilde "geri alabiliyorsanız" anlamlıdır. Temel olarak, bunu yapmanın iki yolu vardır: 64 bit tam sayı matematiği yaparsınız ya da 4'ten fazla GiByte haritalanmış belleğe ihtiyacınız vardır. Bunlardan biri veya her ikisi de doğruysa, 64 bit yazılımı kullanmak mantıklıdır, aksi halde olmaz.

Not: Karşılık gelen 32 veya 64 bit değişkenlerin olmadığı bazı mimariler var. Bu durumda, soru açıkça belli değil. En iyi bilinen, yalnızca 64 bit ve 32 bit varyantı olmayan IA64 ve yakından ilgili olsa da, farklı mimarilere sahip x86 / AMD64 , x86 sadece 32 bit, AMD64 ise sadece 64 bit idi.

Aslında, bu ikinci ifade artık% 100 doğru değil. Linux, yakın zamanda AMD64 kodunu 32 bitlik göstericilerle çalıştırmanıza izin veren x32 ABI'yi ekledi, bu yüzden "uygun" bir CPU mimarisi olmasa da, AMD64 mimarisini yerel gibi kullanmanın bir yoludur. 32 bit değişken. Bu tam yapılmadı çünkü ben yukarıda belirtilen performans havai neden oldu gerçek gerçek dünya sistemlerinde gerçek dünya kodunu çalıştıran gerçek dünya kullanıcıları için ölçülebilir, ölçülebilir problemleri.

— Jörg K Mittag
kaynak

8

X86'ya kıyasla amd64'teki ekstra kayıtlar ve talimatlar ne olacak? Bu performansı ne kadar arttırıyor?

— Filip Haglund

2

MacOS X ve iOS'ta Objective-C'de kullanılan "etiketli işaretçiler" için Google. Çok büyük miktarlarda nesnenin hafızasında ayrılmış bellek yoktur, ancak nesnenin tamamı 64 bit sistemlerde işaretçinin içine takılmıştır. (Java’nın da benzer bir şey yaptığını duydum). C ++ 'ta, 64 bit üzerindeki std :: string, genellikle herhangi bir bellek ayırması olmadan nesnede en fazla 22 karakter içerir. Önemli bellek tasarrufu ve hız iyileştirmeleri.

— gnasher729

3

İşaretçilerin ve tam sayıların boyutu bu mu? 64 bit mimarisindeki daha geniş adres alanı ve ek yazmaçlara ne dersiniz?

1

"Eğer% 20 ~ tarafından talimat önbelleği [azaltılmış] ettik" komut kümesi tamamen farklı olduğu için tartışmaya açıktır (ve genellikle daha verimli)

— BlueRaja - Dany Pflughoeft

3

“Bunun performans üzerinde ihmal edilemez bir olumsuz etkisi var.” Bu ifade mutlak anlamda doğru olsa da, uygulamaların performans darboğazlarının büyük çoğunluğunun yükleme süresinde ya da bellek kullanımı / bant genişliği veya önbellekteki talimatların sayısı olmadığı gerçeğini görmezden gelir.

— Ian Kemp,

6

Yazılımın doğrudan eski sistemlerle, sürücülerle veya kitaplıklarla arayüzlenmesi gerekiyorsa, AFAIK'in genel olarak işletim sistemi (kesinlikle Windows ve Linux AFAIK) 64-bit ve 32'nin karıştırılmasına izin vermediğinden, 32 bitlik bir sürüm sağlamanız gerekebilir. Bir işlem içinde -bit kodu.

Örneğin, yazılımınızın özel donanıma erişmesi gerekiyorsa, müşterilerin yalnızca 32 bit sürücülerin kullanabileceği eski modelleri kullanması nadir değildir.

— Michael Borgwardt
kaynak

2

Sen edebilirsiniz Windows ve Linux hem de aynı süreçte 32 bit ve 64 bit mix: stackoverflow.com/q/12716419/703382

— Navin

1

@Navin: Ama pratik mi? Bir 64-bit Windows uygulamasında bir COM bileşeni (örneğin , 64-bit bir Windows sürümünde çalışan herhangi bir CPU olarak işaretlenmiş bir .NET uygulaması ) kullanabilir misiniz?

— Peter Mortensen

3

Yazılım bir DLL ise, MUTLAKA hem 32-bit ve 64-bit sürümlerini sağlamaktadır. Müşterinin, DLL ile konuşmak için 32-bit veya 64-bit yazılım kullanıp kullanmayacağı konusunda hiçbir fikriniz yok ve DLL, uygulama ile aynı bit uzunluğunu kullanmak zorunda. Bu pazarlık konusu değil.

Yazılımınız bağımsız bir çalıştırılabilir ise, daha az açıktır. Yazılımınızın eski işletim sistemlerinde çalışması için ihtiyacınız yoksa, 32 bit sürüm sağlamanız gerekmeyebilir. 64-bit'e bağlı kalmanız, 64-bit işletim sistemi gerektirdiğini ve işin tamamlandığını belirtin.

Eski işletim sistemleri üzerinde çalıştırmak için yazılım gerekir yoksa ancak sonra aktif olabilir DEĞİL 64-bit sürüm sunmak istiyorum. İki sürümünüz varsa, testi iki katına çıkarırsınız ve yazılımı çeşitli işletim sistemi sürümleri ve dilleri arasında doğru şekilde test etmek hızlı bir işlem değildir. 32-bit yazılım 64-bit bir platformda mükemmel şekilde mutlu bir şekilde çalıştığından, yazılımın özellikle küçük geliştiriciler tarafından yalnızca 32-bit olarak piyasaya sürülmesi oldukça yaygındır.

Ayrıca, çoğu cep telefonunun 32 bit olduğunu unutmayın. Belki bazı üst seviye olanlar şimdi 64 bit, ancak bu adımı atmak için çok az zorlayıcı sebep var. Bu nedenle, platformlar arası geliştiriyorsanız ve kodunuzun Android'de de çalışmasını istiyorsanız, 32 bit kalmak güvenli bir seçenektir.

— Graham
kaynak

Azaltılmış testler konusundaki pozisyonunuza karşı çıkarım. Bunun yerine, özellikle sadece farklı kayıt büyüklükleriyle değil aynı zamanda farklı bayt siparişleri ile birden fazla platformda test etmeyi ve test etmenin ve ince hataların yakalanmasının kolay bir yolu olduğunu iddia ediyorum. Ek olarak, önerilen asgari donanım gereksinimlerinizi karşılamayan bilgisayarlarda da test yapacağım çünkü bu, çok büyük veri kümeleri dışında başka türlü görünmeyebilecek ek sorunları da ortaya çıkaracaktır.

— hildred

@hildred Sınırsız test kaynağı ile aynı fikirdeyim. Ancak uygulamada, hedefiniz üzerinde daha fazla kontrol sahibi iseniz, o zaman bu testi hemen yapmanız gerekmeyebilir. Bu da hiç de kolay bir yol değil - elbette bir VM'de bu platformların bazılarını simüle edebilirsiniz, ancak fiziksel bir donanıma ihtiyaç duyuyorsanız, bunun için büyük miktarda manuel (otomatik olmayan) çalışma gerekir. Bunu açıkça sınamak için bir test demeti yazmaktan kurtarabilir, ancak hiçbir şekilde ücretsiz değildir.

— Graham

1

Ücretsiz değil, düpedüz ucuz. Platform dışı testinizi otomatik testlerle sınırlandırırsanız, zaman zaman salak test, kullanılmış donanım Kurulumunuz dışında, ilk kurulumunuzdan sonraki başarılı testler için maliyetleriniz güçle sınırlı olacaktır ve test geçişi başına yaklaşık 7 adam. Başarısız testlerin maliyeti elbette daha yüksek olurdu, ama bunlar genellikle daha değerli olurdu (her zaman donanım arızası vardır). Bu tür kurulumlar özellikle programcılar için yararlıdır çünkü kolayca izlenmesi zor olan belirli bir işaretçi problemleri sınıfını kolayca ortaya çıkarır.

— hildred