Dr. Jon Bentley
Computing Science Research Center
AT&T Bell Laboratories
Murray Hill, NJ
Bir sistemin yaşamının erken dönemlerinde, hızlı hesaplamalar bir sistem tasarımcısını cazip iki alternatif arasında rasyonel bir seçim yapmaya yönlendirebilir.
Mississippi Nehri’nin Debisi
Yazılım mühendisliği üzerine ilginç bir sohbetin ortasında Bob Martin bana şunu sordu: “Mississippi Nehri bir günde ne kadar su boşaltır?”
O ana kadar yaptığı yorumları son derece derinlikli bulduğum için, gerçek tepkimi kibarca bastırdım ve “Affedersiniz?” dedim.
Soruyu tekrar ettiğinde, Bell Labs içinde büyük bir yazılım birimini yönetmenin baskısı altında açıkça çökmüş olan zavallı adama uyum sağlamaktan başka seçeneğim olmadığını fark ettim.
Yanıtım kabaca şöyleydi.
Nehri ağzına yakın bir yerde yaklaşık bir mil genişliğinde ve belki yirmi fit derinliğinde (ya da bir milin yaklaşık iki yüz ellide biri) olarak düşündüm.
Akış hızının saatte beş mil, yani günde yüz yirmi mil olduğunu varsaydım.
Çarparak:
- 1 mil × 1/250 mil × 120 mil/gün
≈ 1/2 mil³/gün
sonucuna ulaştım; bu da nehrin günde yaklaşık yarım kübik mil su boşalttığını, büyüklük mertebesi içinde gösteriyordu.
Ama peki ya sonra?
O noktada Martin masasından, AT&T’nin 1984 Yaz Olimpiyatları için geliştirdiği bilgisayar tabanlı posta sistemiyle ilgili bir teklifi aldı ve benzer bir hesaplama dizisinden geçti.
Rakamları doğrudan tekliften alındığı için daha kesin olsa da, hesaplamalar aynı derecede basitti ve çok daha açıklayıcıydı.
Bu hesaplamalar, cömert varsayımlar altında bile, önerilen sistemin yalnızca her dakikada en az yüz yirmi saniye olması durumunda çalışabileceğini gösteriyordu.
Tasarıyı bir gün önce yeniden çizim tahtasına göndermişti.
Sohbet 1983’ün başlarında gerçekleşmişti; ancak nihai sistem Olimpiyatlar sırasında sorunsuz biçimde kullanıldı.
Tahmin Yapmanın Mühendislik Tekniği
Bu, Bob Martin’in “zarf arkası” hesaplamalar olarak bilinen mühendislik tekniğini tanıtmasının harika, biraz da tuhaf bir yoluydu.
Bu fikir mühendislik okullarında standarttır ve uygulayıcı mühendislerin çoğu için günlük ekmek kapısıdır.
Ne yazık ki, bilişimde bu yaklaşım çok sık ihmal edilir.
Bu temel hatırlatmalar, zarf arkası hesaplamalar yaparken oldukça yardımcı olabilir.
İki Yanıt Birden İyidir
Peter Weinberger’e Mississippi’nin günde ne kadar su boşalttığını sorduğumda, “İçeri giren kadar,” diye yanıtladı.
Ardından Mississippi havzasının yaklaşık 1000’e 1000 mil olduğunu ve buradaki yıllık yağıştan kaynaklanan yüzey akışının yaklaşık bir fit (ya da bir milin beş binde biri) olduğunu tahmin etti.
Bu da şunu verir:
- 1000 mil × 1000 mil × 1/5000 mil/yıl
- ÷ 400 gün/yıl
≈ 1/2 mil³/gün
ya da günde yarım kübik milden biraz fazla.
Tüm hesaplamaları iki kez kontrol etmek önemlidir; hızlı yapılanlar için bu özellikle geçerlidir.
Hileli bir üçüncü kontrol olarak, bir almanak nehrin debisinin saniyede 640.000 kübik fit olduğunu bildiriyordu.
Buradan hareketle:
- 640.000 ft³/sn × 3600 sn/saat × 24 saat/gün
- ÷ (5000 ft/mil)³
≈ 1/2 mil³/gün
COMPUTERS and PEOPLE, Temmuz–Ağustos 1987
Bu iki tahminin birbirine ve özellikle almanaktaki sonuca bu kadar yakın olması, saf şansın güzel bir örneğidir.
Hızlı ve Etkili Kontroller
Polya, How To Solve It adlı eserinde “Boyutla Test Etme”ye üç sayfa ayırır ve bunu “geometrik ya da fiziksel formülleri denetlemek için iyi bilinen, hızlı ve etkili bir yöntem” olarak tanımlar.
Birinci kural, bir toplamda yer alan terimlerin boyutlarının aynı olması gerektiğidir; toplamın boyutu da aynıdır—fitleri toplayarak fit elde edebilirsiniz, ama saniyeleri poundlarla toplayamazsınız.
İkinci kural, bir çarpımın boyutunun, boyutların çarpımı olmasıdır.
Yukarıdaki örnekler her iki kurala da uyar; çarpma işlemi:
- mil × mil × mil/gün = mil³/gün
sabitler bir yana bırakıldığında doğru biçime sahiptir.
Sağduyu
Her şeyden önce sağduyuyu unutmayın: Mississippi Nehri’nin günde 100 galon su boşalttığını gösteren herhangi bir hesaptan şüphelenin.
Birkaç zarf dolusu aritmetik, bir sistem tasarımcısının cazip iki alternatif arasında rasyonel bir seçim yapmasını sağlayabilir.
Bu, Martin’in Olimpiyat posta sistemi için yaptığı hesaptan temelde farklı bir kullanımdır: onun tek bir tasarımı analiz etmesi, ölümcül bir kusuru ortaya çıkarmıştır.
Her iki durumda da, kısa bir hesaplama dizisi eldeki soruyu yanıtlamak için yeterliydi; ek hesaplar çok az aydınlatma sağlayacaktı.
Bir sistemin yaşamının erken dönemlerinde, hızlı hesaplamalar tasarımcıyı tehlikeli sulardan güvenli geçitlere yönlendirebilir.
Ve eğer bunları erken kullanmazsanız, geriye dönüp bakıldığında bir projenin başarısızlığa mahkûm olduğunu gösterebilirler.
Hesaplamalar çoğu zaman önemsizdir ve lise matematiğinden fazlasını gerektirmez.
Zor olan kısım, onları yeterince erken kullanmayı hatırlamaktır.
Herhangi bir hesaplamanın çıktısı, yalnızca girdisi kadar iyidir.
İyi verilerle, basit hesaplamalar bazen oldukça işe yarayan doğru sonuçlar verebilir.
1969’da Don Knuth bir disk sıralama paketi yazdı; ancak bunun, hesaplamalarının öngördüğünün iki katı zaman aldığını fark etti.
Özenli bir denetim kusuru ortaya çıkardı: bir yazılım hatası nedeniyle, sistemin bir yıllık diskleri tüm ömürleri boyunca ilan edilen hızlarının yalnızca yarısında çalışmıştı.
Hata giderildiğinde, sıralama paketi öngörüldüğü gibi davrandı ve diske bağımlı diğer tüm programlar da daha hızlı çalıştı.
Ancak çoğu zaman, özensiz girdiler bile doğru aralığa girmek için yeterlidir.
Burada yaklaşık yüzde yirmi, şurada yüzde elli tahmin edersiniz ve yine de bir tasarımın belirtimin yüz kat üzerinde ya da altında olduğunu görürseniz, ek doğruluğa gerek yoktur.
Ama yüzde yirmilik bir hata payına fazla güvenmeden önce, Vic Vyssotsky’nin çeşitli vesilelerle verdiği bir konuşmadan öğüdünü dikkate alın.
Tacoma Narrows Köprüsü
"Çoğunuz," diyor Vyssotsky, "muhtemelen 1940’ta bir fırtınada kendini parçalayan Tacoma Narrows Köprüsü ‘Galloping Gertie’nin fotoğraflarını hatırlıyorsunuzdur.
Aslında, Galloping Gertie’den önce yaklaşık seksen yıl boyunca asma köprüler bu şekilde kendilerini parçalayıp duruyordu.
Bu, aerodinamik kaldırma olgusudur ve kuvvetlerin doğru bir mühendislik hesabını yapmak için—ki bunlar ciddi doğrusal olmayanlıklar içerir—girdap tayfını modellemek üzere Kolmogorov’un matematiğini ve kavramlarını kullanmanız gerekir.
1950’lere kadar ya da o civarlara dek kimse bunu ayrıntılı olarak doğru biçimde nasıl yapacağını gerçekten bilmiyordu.
Peki o zaman, Brooklyn Köprüsü neden Galloping Gertie gibi kendini parçalamadı?"
Brooklyn Köprüsü
"Çünkü John Roebling, bilmediğini bilecek kadar sağduyulu biriydi.
Brooklyn Köprüsü’nün tasarımına ilişkin notları ve mektupları hâlâ mevcuttur ve bunlar, iyi bir mühendisin bilgisinin sınırlarını fark edişine dair büyüleyici bir örnektir.
Asma köprülerdeki aerodinamik kaldırma hakkında bilgisi vardı; bunu gözlemlemişti.
Ve bunu modelleyecek kadar bilgi sahibi olmadığını da biliyordu.
Bu yüzden Brooklyn Köprüsü’nün taşıt yolu üzerindeki kafes kirişin rijitliğini, bilinen statik ve dinamik yüklere dayalı normal bir hesabın gerektireceğinin altı katı olacak şekilde tasarladı.
Ayrıca, tüm köprü yapısını rijitleştirmek için taşıt yoluna doğru inen çapraz askılardan oluşan bir ağ belirledi.
Bunlara bir ara gidip bakın; neredeyse benzersizdirler.
"Roebling’e, önerdiği köprünün diğerleri gibi çöküp çökmeyeceği sorulduğunda, ‘Hayır,’ dedi, ‘çünkü bunun olmasını önlemek için gerektiğinden altı kat daha sağlam tasarladım.’"
"Roebling iyi bir mühendisti ve bilgisizliğini telafi etmek için çok büyük bir emniyet katsayısı kullanarak iyi bir köprü yaptı.""
COMPUTERS and PEOPLE, Temmuz–Ağustos 1987
Biz bunu yapıyor muyuz?
Gerçek zamanlı yazılım sistemlerimizin performansını hesaplarken, bilgisizliğimizi telafi etmek için bunları iki, dört ya da altı katsayısı ile düşürmemiz gerektiğini ileri sürüyorum.
Güvenilirlik/kullanılabilirlik taahhütleri verirken, bilgisizliğimizi telafi etmek için ulaşabileceğimizi düşündüğümüz hedeflerden on kat geri durmalıyız.
Boyut, maliyet ve takvim tahminlerinde, bilgisizliğimizi telafi etmek için iki ya da dört kat muhafazakâr olmalıyız.
John Roebling’in yaptığı gibi tasarlamalıyız; çağdaşlarının yaptığı gibi değil—bildiğim kadarıyla, Roebling’in çağdaşları tarafından Amerika Birleşik Devletleri’nde inşa edilen asma köprülerin hiçbiri hâlâ ayakta değil ve 1870’lerde ABD’de inşa edilen her tür köprünün dörtte biri, yapımlarından sonraki on yıl içinde çöktü.
"John Roebling gibi mühendisler miyiz?
Merak ediyorum."
1982’den Bir Örnek
Yukarıdaki noktaları daha somut kılmak için, 1982’nin başlarında küçük bir şirket için kurduğum bir sistemde bunları nasıl (neredeyse) kullandığımı anlatacağım.
Sistem, bin adet seksen sütunlu kayda ilişkin verileri özetlemek için günde birkaç rapor hazırlıyordu; raporların her biri yaklaşık seksen sayfaydı.
Sistemin selefi büyük bir ana bilgisayarda çalışıyordu; benim görevim, yorumlanan BASIC kullanarak benzer bir sistemi bir kişisel bilgisayarda hayata geçirmekti.
Sistemin tasarımının erken aşamalarında, kişisel bilgisayarın bu uygulamaya yeterli olduğundan emin olmak için basit hesaplamalar yaptım.
Alan analizi basitti: En büyük birkaç tablonun boyutunu hesapladım ve makinenin 48K baytının yalnızca yarısını kullandıklarını gördüm.
Zaman analizi, Şekil 1’de gösterilen iki ana aşama etrafında yoğunlaşmıştı.
Aşama 1 için zaman konusunda fazla endişelenmedim: önceki bir sistem bu görevi bir IBM System/360 Model 25 üzerinde bir dakikada yapıyordu ve kişisel bilgisayardaki mikroişlemci o eski iş atından daha güçlüydü.
Bunun yerine, Aşama 2’ye odaklandım; bunun yazıcının dakikada altmış satırlık hızıyla sınırlı olacağını düşünüyordum.
Raporun her sayfası yaklaşık otuz satır içeriyordu, dolayısıyla toplam kırk dakikalık süre sınırlar içindeydi.
Bu kısa analizden sonra şirket üç kişisel bilgisayar satın aldı ve ben tasarımı uyguladım.
Programın ilk uygulaması öğretici oldu.
BASIC programını depolamak, hesaplamamda göz ardı ettiğim yaklaşık yirmi kilobayt ana bellek gerektirdi; iki katlık emniyet payı günü kurtardı.
Kırk dakikalık yazdırma süresi tam isabetti.
Ne yazık ki, kayıtları okuma ve tabloyu kurma süresinde büyük ölçüde yanılmıştım.
Bir dakika sürmesi gerekirken on dört saat sürdü; bu da günde birkaç rapor hazırlamayı son derece zorlaştırdı.
Sorun, eski System/360 üzerindeki assembly kodunu, yorumlanan BASIC’in genellikle assembly koddan birkaç yüz kat daha yavaş çalıştığı gerçeğini göz ardı ederek kişisel bilgisayardaki yorumlanan BASIC ile karşılaştırmış olmamdı.
O noktada daha dikkatli bir kabaca hesap yaptım.
Yukarıda tanımlanan parametreleri (her biri 80 sütunlu 1000 kayıt) ve diğer parametreler için yaklaşık tahminleri (sütun başına 50 BASIC komutu ve saniyede yüz BASIC komutu) kullanmak şu sonucu verdi:
- (1000 kayıt) × (80 sütun/kayıt) × (50 komut/sütun)
- ÷ (100 komut/saniye) × (3600 saniye/saat)
≈ 11 saat
Alternatif olarak, eski makinenin bu görev için bir dakika aldığını ve bir komutu yaklaşık on mikrosaniyede yürüttüğünü biliyordum.
On milisaniyeye yavaşlama bin katlık bir çarpandır ve önceki değer olan bir dakikanın bin katı yaklaşık on yedi saattir.
Bu yaklaşımın maliyetini programı yapmadan önce bilseydim, daha hızlı bir dil kullanırdım. Bunun yerine, mevcut 600 satırlık bir programım vardı ve kodu ayarlamaktan başka seçeneğim yoktu.
Aşama 1’deki 70 satır kod, çalışma süresinin yüzde 90’ından fazlasını oluşturuyordu ve yalnızca 3 satır 11 saate karşılık geliyordu (kodun yüzde birinden azı zamanın yüzde 75’ini alıyordu!).
Aşama 2: Raporu Yazdır
Şekil 1
BASIC’teki 70 satırı, BASIC’te 110 satır ve assembly kodunda 30 satırla değiştirmek için kırk saat harcadım; bu, Aşama 1’in süresini on dört saatten iki saat yirmi dakikaya düşürdü. Bu, bu özel sistem için yeterince iyiydi; ancak önceden hızlı bir hesap yapıp daha verimli bir uygulama dili seçmiş olsaydım olabileceğinden daha fazlaydı.
Günlük Hayatta Hızlı Hesaplar
Kabaca hesaplar kullandığınızda, Einstein’ın ünlü öğüdünü mutlaka hatırlayın:
"Her şey mümkün olduğunca basit yapılmalı, ama daha basit değil."
Parametreleri tahmin ederken yaptığımız hataları ve ele aldığımız problem hakkındaki bilgisizliğimizi telafi etmek için emniyet katsayıları ekleyerek basit hesapların aşırı basit olmadığını biliyoruz.
Douglas Hofstadter’ın Mayıs 1982 tarihli Scientific American dergisindeki "Metamagical Themas" köşesinin alt başlığı "Sayı körlüğü ya da neden sayısal okuryazarsızlığın okuma yazma bilmemek kadar tehlikeli olabileceği"dir; bu yazı, 1985’te Basic Books tarafından yayımlanan Metamagical Themas adlı kitabında bir sonsözle birlikte yeniden basılmıştır. Kabaca tahminlere mükemmel bir giriş ve bunların önemini etkileyici bir biçimde ifade eden bir metindir.
Fizikçiler bu konunun fazlasıyla farkındadır. Jan Wolitzky şöyle yazmıştır:
"‘Kabaca hesap’ların, fizikçiden esinle, ‘Fermi yaklaşımları’ olarak adlandırıldığını sık sık duydum. Anlatıya göre Enrico Fermi, Robert Oppenheimer ve Manhattan Projesi’nin diğer üst düzey isimleri, ilk nükleer aygıtın birkaç bin yarda ötede patlatılmasını beklerken alçak bir patlama duvarının arkasındaydı. Fermi, flaşı gördüğünde kâğıtları küçük parçalara yırtıp havaya attı. Şok dalgası geçtikten sonra kâğıt parçalarının kat ettiği mesafeyi adımladı, hızlı bir ‘kabaca hesap’ yaptı ve bombanın patlayıcı gücü için bir değer elde etti; bu değer çok daha sonra pahalı izleme ekipmanlarıyla doğrulandı."
Bir okur, bir reklamda bir satış temsilcisinin bir yılda yeni bir arabayla 100.000 mil sürdüğünün söylendiğini duyduğunu ve ardından oğlundan bu iddianın geçerliliğini incelemesini istediğini anlattı. İşte hızlı bir yanıt: yılda 2.000 çalışma saati vardır (haftada 40 saatten 50 hafta) ve bir satış temsilcisi saatte ortalama 50 mil yapabilir; bu, fiilen satış yaparken geçirilen zamanı göz ardı eder, ama çarpım iddiaya eşittir. Dolayısıyla ifade, inanılabilirliğin üst sınırındadır.
Günlük yaşam, hızlı hesaplar konusundaki becerilerimizi geliştirmek için bize pek çok fırsat sunar. Örneğin, geçen yıl restoranlarda yemek yiyerek ne kadar para harcadınız? Bir keresinde bir New Yorklunun, kendisi ve eşinin her ay taksilere, kiraya harcadıklarından daha fazla para harcadığını hızla hesapladığını dehşetle duymuştum. Ve Kaliforniyalı okurlar için (taksinin ne olduğunu bilmeyebilirler), bir bahçe hortumuyla bir yüzme havuzunu doldurmak ne kadar sürer?
Istakoz Toplama
Birçok okur, hızlı hesapların erken yaşta öğretilmesinin yerinde olduğunu belirtti. Stevens Institute of Technology’den Roger Pinkham şöyle yazdı:
Ben bir öğretmenim ve dinleyen herkese ‘kabaca hesap’ları öğretmeye çalıştım. Olağanüstü derecede başarısız oldum. Thomas gibi kuşkucu bir zihniyet gerektiriyor gibi görünüyor.
Babam bunu bana zorla benimsetti. Maine kıyılarından geliyorum ve küçük bir çocukken babamla arkadaşı Homer Potter arasındaki bir konuşmaya tanık olmuştum. Homer, Connecticut’tan iki hanımın günde 200 pound ıstakoz çektiğini iddia ediyordu. Babam, “Bir bakalım. On beş dakikada bir sepet çekersen ve sepet başına üç yasal ıstakoz aldığını varsayarsak, bu saatte 12 ya da günde yaklaşık 100 eder. Buna inanmıyorum!” dedi.
“Ama doğru!” diye yemin etti Homer. “Hiçbir şeye inanmıyorsun!”
Babam inanmadı ve konu kapandı. İki hafta sonra Homer, “Biliyor musun Fred, o iki hanım günde sadece 20 pound çekiyordu,” dedi.
Aşırı derecede nazik olan babam homurdandı: “İşte buna inanırım.”
Çocukların Yaşam Boyu Meraklılığı
Birkaç başka okur da bu tutumun çocuklara öğretilmesini tartıştı; şu bakış açısından (lütfen 26. sayfaya bakın).