jlar, diğer çekirdeklerde olduğu gibi sistem çağrıları tarafından tetiklenmesine rağmen, Mach altında gerçek talebi işleyen tüm çekirdeklerin çoğu başka bir programa kalmıştı.

Konu ve eşzamanlılık desteği IPC mekanizmalarıyla iletilen mesajdan yararlanıyordu, çünkü görevler şimdi mesaj işleme sırasında Mach'ın donması ve dondurulamayacağı birden çok kod iş parçacıklarından oluşuyordu. Bu, sistemin birçok Mach işlemcisinde olduğu gibi paylaşılan belleği kullanarak birden çok işlemciye dağıtılmasını veya gerekirse iletiyi başka bir işlemciye kopyalamak için kod ekleyerek sistemin dağıtılmasına izin verdi. Geleneksel bir çekirdekte bunu uygulamak zordur; sistem, farklı programların aynı bellekte farklı işlemcilerden yazmaya çalışmadığından emin olmalıdır. Bununla birlikte, Mach bağlantı noktaları, hafıza erişimi süreci, bunu iyi tanımlanmış ve uygulanması kolaylaştırıyor ve bu sistemde birinci sınıf bir vatandaş haline geldi.

IPC sistemi başlangıçta performans sorunları yaşadı, bu nedenle etkiyi en aza indirmek için birkaç strateji geliştirildi. Öncülü Accent gibi Mach, mesajı bir programdan diğerine fiziksel olarak geçirmek için tek bir paylaşımlı bellek mekanizması kullandı. İletiyi fiziksel olarak kopyalamak çok yavaş olur, bu nedenle Mach bir verinin bir programdan diğerine çabucak eşleştirmek için makinenin bellek yönetim birimine (MMU) güvenir. Yalnızca veriler yazılıyorsa, fiziksel kopyalanması gerekir, "yazma sırasında kopyalama" adı verilen bir işlemdir.

Sistemin oluşturduğu birçok programdan birinin çökmesini önlemek için, mesajların çekirdek tarafından geçerliliği de kontrol edildi. Limanlar, UNIX dosya sistemi kavramlarına kasten modellendi. Bu, kullanıcının varolan dosya sistemi gezinme kavramlarını kullanarak bağlantı noktalarını bulmasını ve dosya sisteminde olduğu gibi hak ve izinleri atamasına izin verdi.

Mach orijinalde klasik monolitik UNIX'in yerini alması amaçlandı ve bu nedenle birçok UNIX benzeri fikir içeriyordu. Örneğin, Mach, UNIX dosya sisteminde desenli bir izin ve güvenlik sistemi kullandı. Çekirdek, diğer işletim sistemi sunucularına ve yazılımlara göre ayrıcalıklı olduğundan, sisteme zarar verebilecek komutları hatalı veya kötü amaçlı programlar göndermek mümkündür ve bu nedenle çekirdek her iletiyi geçerlilik için kontrol etmiştir. Ek olarak, işletim sistemi işlevselliğinin birçoğu kullanıcı uzayı programlarında yer almaktı, bu nedenle çekirdek bu programları, örneğin donanım üzerinde çalışmak için ek ayrıcalıklar tanımak için bir yol olması gerektiği anlamına geliyordu.

Mach'ın daha ezoterik özelliklerinden bazıları aynı IPC mekanizmasına dayanıyordu. Örneğin, Mach çok işlemcili makineleri kolaylıkla destekleyebildi. Geleneksel bir çekirdekte, farklı işlemciler üzerinde çalışan programlar çekirdeği aynı anda arayabildikçe, onu yeniden giren veya kesilebilir kılmak için kapsamlı çalışmalar yapılmalıdır. Mach altında, işletim sisteminin bitleri, başka herhangi bir programda olduğu gibi herhangi bir işlemcide çalıştırılabilen sunucularda izole edilir. Teorik olarak Mach çekirdeği yeniden girilebilir olmalıydı, pratikte bu bir sorun değil, çünkü yanıt süreleri o kadar hızlı ki sırasıyla bekleyip hizmet edebiliyor. Mach, sadece programları değil, aynı zamanda 1980'lerin sonunda ve 1990'ların başında yoğun bir gelişme alanı olan ağ üzerinden mesajları iletecek bir sunucu içeriyordu. Hemen hemen tüm görevler için IPC kullanımı ciddi bir performans etkisine sahip olduğu ortaya çıktı. 1997 donanımındaki benchmarklar, Mach 3.0 tabanlı UNIX tek sunucu uygulamalarının yerel UNIX'ten% 50 daha yavaş olduğunu gösterdi.

Araştırmalar, bu performans vuruşunun büyük bir çoğunluğunun bir ölçütle% 73'ünün IPC'nin yükünden kaynaklandığını gösterdi. Bu, işletim sistemini sağlayan tek bir büyük sunucuya sahip bir sistem üzerinde ölçüldü; işletim sisteminin daha küçük sunuculara indirilmesi sorunu daha da kötüye götürecekti. Sunucular topluluğunun hedefinin mümkün olmadığı anlaşıldı.

Mach ve Mach benzeri mikro çekirdeklerin performansını artırmak için birçok girişimde bulunuldu, ancak 1990'ların ortalarından itibaren yoğun ilgi çoktan öldü. IPC tabanlı bir işletim sistemi kavramı ölü gibi göründü, fikrin kendisi de hatalıydı. Aslında, performans sorunlarının kesin doğası üzerine daha fazla çalışma, bir takım ilginç gerçekleri ortaya çıkardı. Birincisi, IPC'nin kendisi değildi: desteklemek için ihtiyaç duyulan bellek eşleştirmesiyle ilgili bir miktar yük vardı, ancak bu, görüşme yapmak için yalnızca küçük bir süre kaldı. Geriye kalan, zamanın% 80'i harcanmıştı, mesajlar çekirdeğin ek görevleri nedeniyle gerçekleşiyordu. Bunların başında, liman hakları kontrolü ve mesaj geçerliliği oldu. 486DX-50'de standart olarak UNIX sistem çağrısı tamamlanması ortalama 21μs (mikrosaniye) alırken, Mach IPC ile eşdeğer işlem 114μs ortalaması aldı. Bunun sadece 18μs'si donanım ile ilgili idi; Geri kalanı, mesaj üzerinde çeşitli rutinleri çalıştıran Mach çekirdeğiydi. Hiçbir şey yapmayan bir sistem çağrısı altında, BSD altında tam bir gidiş-dönüş yaklaşık 40μs gerektirirken, bir kullanıcı-alanı Mach sisteminde ise hemen hemen 500μs alacaktır.

Mach ilk kez 2.x sürümlerinde ciddi olarak kullanıldığında, performans geleneksel monolitik işletim sistemlerinden daha düşük, belki de% 25 gibi daha yüksekti. Bu maliyet, özellikle endişe verici olarak düşünülmedi, çünkü sistem ayrıca çoklu işlemci desteği ve kolay taşınabilirlikli idi. Birçoğu, bunun beklenen ve kabul edilebilir bir ödeme maliyeti olduğunu düşünüyordu. Mach 3 işletim sisteminin çoğunu kullanıcı alanına taşımaya çalışırken yük daha da yükseldi: MIPS R3000'de Mach ve Ultrix arasındaki benchmarklar bazı iş yüklerinde% 67 gibi büyük bir performans vuruşu gösterdi.

Örneğin, sistem saatinin alınması, sistem saatini tutan kullanıcı alanı sunucusuna yapılan bir IPC çağrısını içerir. Arayan ilk olarak çekirdek içine kapanıp, bir bağlam anahtarı ve bellek eşlemesine neden olur. Çekirdek daha sonra arayanın erişim haklarına sahip olduğunu ve mesajın geçerli olduğunu kontrol eder. Varsa, kullanıcı alanı sunucusundaki aramayı tamamlamak için başka bir bağlam anahtarı ve bellek eşlemesi var. Ardından, toplam dört içerik anahtarı ve bellek eşlemesi ve artı iki ileti doğrulaması ekleyerek sonuçları döndürmek için işlem tekrarlanmalıdır. Bu yük daha çok sunuculardan geçen kod yollarının olduğu daha karmaşık hizmetler ile hızla oluşur.

Performans sorunlarının tek kaynağı bu değildi. Bir diğeri, fiziksel hafıza azalıp sayfalama yapılması durumunda hafızayı düzgün bir şekilde kullanmaya çalışmanın problemleri üzerine odaklandı. Geleneksel monolitik işletim sistemlerinde yazarlar, çekirdeğin hangi kısmının hangi kişilere çağrıldığının doğrudan tecrübesine sahipti; bu da, daha önce kullanılacak kodu çağırma kodundan kaçınmak için çağrı cihazlarını ince ayarlamalarını sağladı. Mach altında bu mümkün olmadı, çünkü çekirdek işletim sisteminin neye ait olduğunu bilmiyordu. Bunun yerine, performans sorunlarına eklenen tek bir boyutta uyan tek bir çözüm kullanmaları gerekiyordu. Mach 3, daha iyi uzmanlık için kullanıcı alanı çağrı cihazlarına dayanan basit bir çağrı cihazı sağlayarak bu soruna hitap etmeye çalıştı. Ama bu çok az etkiye sahip olduğu ortaya çıktı. Pratikte, sahip olduğu tüm avantajlar, onu aramak için gereken pahalı IPC tarafından silinmişti.

Diğer performans sorunları, Mach'ın çoklu işleme sistemlere olan desteği ile ilgiliydi. 1980'lerin ortalarından 1990'lı yılların başına kadar, emtia işlemcileri yılda yaklaşık% 60 oranında performans göstermiş, ancak hafıza erişim hızı yılda yalnızca% 7 oranında büyümüştür. Bu, belleğe erişmenin maliyetinin bu dönemde muazzam bir biçimde büyüdüğü anlamına gelir ve Mach, programlar arasında bellek haritalamaya dayandığı için, herhangi bir "cache miss", IPC çağrılarını yavaşlatır.

Mach yaklaşımının avantajlarından bağımsız olarak, bu tür gerçek dünya performans vuruşları kabul edilemezdi. Diğer takımlar aynı sonuçları bulduklarında, erken Mach heyecanı hızla kayboldu. Kısa bir süre sonra, kalkınma topluluğunda birkaçı, bir işletim sisteminin temeli olarak IPC'yi kullanma konseptinin tamamının hatalı olduğu sonucuna varmış görünüyordu.

Mach 3 sistemleri için IPC yükü önemli bir sorundur. Bununla birlikte, çoklu sunucu işletim sistemi kavramı hala umut vericidir, ancak yine de biraz araştırma gerektirmektedir. Geliştiricilerin, sunucudan sunucuya çağrı yapılmayan modüllere kod ayırmak için dikkatli olmaları gerekir. Örneğin, ağ kodunun çoğunluğu tek bir sunucuya yerleştirilir, böylece normal ağ görevleri için IPC'yi en aza indirir.

Çoğu geliştirici, işletim sistemi işlevselliğini sağlayan tek bir büyük sunucunun orijinal POE konseptini sıkıştı. Geliştirmeyi kolaylaştırmak için, işletim sistemi sunucusunun kullanıcı alanında veya çekirdek alanında çalışmasına izin verdiler. Bu, kullanıcı alanlarında gelişmelerine, orijinal Mach fikrinin tüm avantajlarına sahip olmalarına ve ardından daha iyi bir performans elde etmek için hata ayıklanmış sunucuyu çekirdek alanına taşıdıklarına izin verdi. Ardından Lite, MkLinux, OSF / 1 (Digital Unix) ve NeXTSTEP / OPENSTEP / macOS gibi co-location olarak bilinen bu yöntemi kullanarak çeşitli işletim sistemleri kuruldu. ChorusOS mikrokerneli, sunucuları yerleşik mekanizmaları kullanarak çekirdek alanına yükseltmek için bunu temel sistemin bir özelliği yaptı.

Mach 4, bu kez daha radikal bir yükseltme seti ile bu sorunları çözmeye çalıştı. Özellikle, program kodunun genellikle yazılabilir olmadığı, dolayısıyla yazma sırasında kopyalama nedeniyle potansiyel isabetlerin düşük olduğu bulundu. Bu nedenle, IPC için programlar arasında hafızayı haritalamak değil, bunun yerine kullanılan program kodunu programın yerel alanına geçirmek mantıklıydı. Bu, "mekik" kavramının ortaya çıkmasına neden oldu ve performans düzelmiş gibi görünüyordu, ancak geliştiriciler yarı kullanılabilir bir durumda sistemle ilerlemişti. Mach 4 aynı zamanda çekirdeğin kendisinin bir parçası haline getiren dahili eş konum ilkellerini