- incident.io, geliştirici dizüstülerini M3'e geçirip geçirmemeye karar vermek için hissiyata değil Go derleme sürelerine baktı ve yerel geliştirme geri bildirim döngüsüne dair gerçek veriler topladı
- Mevcut Go hot reloader ile ihtiyaç duyulan değerleri elde etmek zor olduğundan kendi aracını geliştirdi ve platform, bellek, güç durumu, derleme aşaması, tetikleyici dosya ve toplam süre gibi derleme olaylarını veri ambarına aktardı
- Yaklaşık 25 bin derleme içinden başarısız, iptal edilmiş ve pil gücüyle yapılan derlemeleri eledikten sonra 12.525 başarılı derlemeyi analiz etti; AC güçle yapılan derlemelerin pilde yapılanlardan istatistiksel olarak daha hızlı olduğunu doğruladı
- Sonuç olarak M1 kullanıcılarının derlemenin tamamlanmasını beklerken sık sık neredeyse 2 dakika kaybettiği, M2'nin M1'e göre büyük bir iyileşme, M3'ün ise M2'ye göre kademeli bir iyileşme sunduğu görüldü
- Toplam derleme süresinde bellek farkı belirgin değildi ancak linker süresinde 32~36GB sistemler avantajlıydı; bu nedenle incident.io, M1 cihazlarını varsayılan 36GB M3 Pro ile değiştirmeye karar verdi
Yükseltme kararının ölçütü geliştirici geri bildirim döngüsü
- incident.io'daki tüm geliştiriciler geliştirme işleri için MacBook kullanıyor
- Apple, Ekim 2023'te M3 MacBook Pro'yu duyurduktan sonra CTO Pete, yükseltme değerinin verilerle kanıtlanması halinde cihazların değiştirileceğini söyledi
- Ekip, M3 yükseltmesine karar verebilmek için üç şey hazırladı
- Özel bir Go hot reloader
- Geliştirici dizüstülerinden derleme telemetrisi toplama
- Verileri analiz etmek için OpenAI'nin en güncel modeli ve code interpreter kullanımı
- Geliştirici üretkenliğini doğrudan nicelleştirmek zor olsa da incident.io, hızlı geri bildirim döngülerinin geliştirici verimliliği için kritik olduğunu düşünüyor
- Yerel geliştirmede sık tekrarlanan geri bildirim döngüleri şunlar
- Go monolitini derleme
- API istemcileri ve arayüzler gibi kod üretimi
- Frontend ve mobil uygulamada hot reload
- incident.io geliştiricileri, tüm incident.io ortamını dizüstülerinde yerel olarak çalıştırıyor ve kod değişikliğinden çalıştırmaya kadar 30 saniyenin altında bir geri bildirim döngüsü koruyor
- Go uygulamasının kod tabanı neredeyse 1 milyon satıra yaklaştığı için, sık yaşanan ve maliyeti yüksek olan Go derleme süresi MacBook performansını karşılaştırmak için ölçüt olarak seçildi
Derleme telemetrisi nasıl toplandı
- incident.io, ilk GitHub deposu oluşturulduğu zamandan beri Go hot reloader olarak codegangsta/gin kullanıyordu
- Alternatif hot reloader'lar da değerlendirildi ancak derleme süresi analizi için gerekli telemetrileri sağlayan bir araç bulunamadı
- Her derlemede toplanmak istenen veriler şunlardı
- Sistem düzeyi: M1/M2/M3 platformu, toplam bellek vb.
- Çalışma zamanı metrikleri: OS, bellek kullanımı, güç kaynağı, pil seviyesi vb.
- Derleme telemetrisi: toplam süre, Go derleme aşamaları, derlemeyi tetikleyen dosyalar vb.
- Hazır bir alternatif olmadığından
main.goile başlayan kendi aracını geliştirdi ve gereken değerleri çıkarmak için Mac'teki çeşitli ikili araçların çıktısını çalıştırıp ayrıştırdımemory_pressuredockersysctlpmset
- İlgili kod Gist olarak yayımlandı
- Sistem ve çalışma zamanı toplayıcıları oluşturulduktan sonra Go derleme komutu sarmalanarak linker, compiler gibi aşamaların süreleri ve derlemeyi tetikleyen dosyalar toplandı
- Son hot reloader, mevcut
make runhedefi içinden çalıştı ve bu değişiklik mühendislik ekibi için görünmez oldu - Her derleme bittiğinde telemetri olayı bir HTTP uç noktasına gönderildi ve Fivetran webhook alıcısıyla veri ambarına aktarıldı
OpenAI Assistant ile analiz akışı
- Birkaç hafta boyunca yeterli veri kümesi toplandıktan sonra BigQuery'den
select * except(payload) from developer__build_eventssonucu CSV olarak dışa aktarıldı - OpenAI Assistants içine amacın açıklandığı bir prompt ve CSV dosyası verildi
- Deneysel
gpt-4-1106-previewmodeli ve code interpreter etkinleştirilerek veri analizi yapıldı - Derleme süreleri aynı sistemde bile oldukça değişkendi ve Go compiler önbelleğinin etkisi büyüktü; bu yüzden yalnızca platform bazlı ortalamaları karşılaştırmak adil değildi
- Önbelleği olmayan bir M3 Max, önbelleği olan eski bir Intel MacBook'tan daha yavaş görünebilirdi
- Analiz, basit ortalama karşılaştırması yerine derleme koşullarını düzenleyip platform, bellek ve güç durumuna göre ayırarak yürütüldü
Veri temizleme ve adil karşılaştırma koşulları
- Tüm veri kümesi yaklaşık 25 bin derlemeden oluşuyordu ve günün farklı saatlerinde, farklı dizüstülerde ve farklı koşullarda toplanmıştı
- Platformlar arasında adil bir karşılaştırma için şu derlemeler hariç tutuldu
- Başarısız veya iptal edilen derlemeler: tamamlanmamış işler olduklarından derleme hızı karşılaştırması için uygun değildi
- Pil gücüyle yapılan derlemeler: OS X, pil ömrünü korumak için performansı sınırlayabiliyor
- Başarısız derlemeler çıkarıldıktan sonra başarılı derleme sayısı 12.525 oldu
- AC güç ile pil gücü arasındaki derleme performansı farkı, özellikle M1 Pro ve M2 Max üzerinden karşılaştırıldı
- İstatistiksel testte AC güçte yapılan derlemelerin ortalama süresi daha düşüktü ve p-value yaklaşık 0.0014 çıktı
- Sonraki analizlerde yalnızca başarılı AC güç derlemeleri kullanıldı
Go derleme süresi neden dalgalanıyor
- incident.io'nun Go monoliti, derleme performansını sürekli izledikleri bir hedef; donanım satın almak kadar derleme sürecinin kendisini azaltmak ve ayarlamak da önemli
- Go projeleri birçok paketten oluşuyor ve Go compiler, yalnızca değiştiğine karar verdiği paketleri yeniden derlemek için önbellek kullanıyor
- incident.io uygulaması, geniş bir bağımlılık grafiğine ve az sayıda temel modüle sahip olacak şekilde tasarlanmış; böylece çoğu değişiklik tüm grafiğin yeniden derlenmesine yol açmıyor
- Derleme türleri kabaca dört gruba ayrılıyor
- Anında tamamlanan, 3 saniyenin altı: Go compiler ile ilgisiz değişiklikler; önbellekteki ikili dosya kullanılabiliyor
- Hızlı derleme, 30 saniyenin altı: az bağımlı tek paket değişikliği; önbelleğin çoğu yeniden kullanılıyor ve sürenin büyük kısmı link işleminde geçiyor
- Orta derleme, 30 saniye ile 1 dakika arası: alt paket bağımlılıkları olan bir özellik paketinde değişiklik yapıldı ancak büyük kısmı yeniden kullanılabiliyor
- Yavaş derleme, 1 dakikanın üstü: temel
domainpaketine bir tür ekleniyor ve uygulamadaki tüm paketlerin yeniden derlenmesi gerekiyor
- Platform karşılaştırması bu derleme karakteri farklarını dikkate almalı; tüm derlemeleri tek potada eritmek elma ile armudu karşılaştırmak olurdu
M1, M2 ve M3 karşılaştırma sonuçları
- Önce yalnızca başarılı AC güç derlemeleri üzerinden M1 Pro ile M2 Max karşılaştırıldı
- M2 Max, derleme hızında M1 Pro'nun belirgin biçimde önündeydi ancak iki cihaz arasında yalnızca yonga seti değil, bellek yapılandırması da farklıydı
- Başarılı derleme olaylarının platform ve belleğe göre dağılımı şöyleydi
- Apple M1 Pro 16GB: 5.235
- Apple M2 Pro 16GB: 1.927
- Apple M2 Max 32GB: 3.842
- Apple M3 Pro 18GB: 321
- Apple M3 Pro 36GB: 899
- Apple M3 Max 36GB: 301
- M1 Pro 16GB ile M2 Max 32GB karşılaştırması, bellek farkı nedeniyle tamamen adil değildi
- M2 Pro 16GB ile M2 Max 32GB karşılaştırıldığında, 32GB belleğin toplam derleme süresine etkisinin küçük olduğu görüldü
- M2 Pro ile M2 Max genel olarak aynı yongayı kullanıyor; Max tarafında ek olarak 2 enerji verimliliği çekirdeği bulunuyor
- Bu çekirdeklerin performans çekirdeklerinin yaklaşık beşte biri düzeyinde olduğu düşünüldüğünden, Go programı derlemede katkılarının sınırlı olduğu değerlendirildi
- M3 değerlendirmesi için şu üç cihaz satın alındı
- M3 Pro 12 çekirdek, 6 performans çekirdeği + 6 enerji verimliliği çekirdeği, 18GB
- M3 Pro 12 çekirdek, 6 performans çekirdeği + 6 enerji verimliliği çekirdeği, 36GB
- M3 Max 14 çekirdek, 10 performans çekirdeği + 4 enerji verimliliği çekirdeği, 36GB
- M3 Pro 18GB ile 36GB'ın derleme süresi grafikleri benzerdi ancak M3 verisi diğer platformlara göre daha azdı
- 3 saniyenin altındaki çok hızlı derlemeler hariç tutulup M3 Pro ile M3 Max karşılaştırıldığında, M3 Max'in temel M3 Pro'ya göre %60 daha yüksek fiyatını haklı çıkaracak kadar belirgin bir iyileşme göstermediği görüldü
- Genel değerlendirme şöyleydi
- M1 dizüstü kullananlar, derlemenin tamamlanmasını beklerken sık sık neredeyse 2 dakika kaybediyor
- M2, M1'e göre büyük bir yükseltme
- M3, M2'ye göre kademeli bir iyileşme
- M1 kullanıcıları temel M3 Pro'ya yükseltilecek
- M2 kullanıcılarının yükseltmeye ihtiyacı yok
Bellek farkı linker süresinde daha net ortaya çıkıyor
- Toplam derleme süresi karşılaştırmasında, 16~18GB'den 32~36GB'a çıkmanın anlamlı bir iyileşme sağladığı çok net görünmedi
- Beklentinin aksine bellek etkisi grafikte belirginleşmeyince, derleme aşamaları içindeki linker süresi ayrıca analiz edildi
- Telemetri olaylarında link ve compile aşamalarının süreleri bulunuyordu;
build_stages.link.duration_secondsüzerindenlinker_timesütunu oluşturularak analiz yapıldı linker_time, platform ve bellek yapılandırmasına göre karşılaştırılınca farklı bir desen ortaya çıktı- 32~36GB belleğe sahip M1, M2 ve M3 cihazlar, link işlemini neredeyse her zaman 20 saniyenin altında tamamlıyordu
- 18GB ve altı belleğe sahip cihazlarda link süresinin 20 saniyeyi aşması sık görülüyordu
- Ek bellek, toplam derleme süresinde daha az belirgin olsa da linker aşamasında faydalı olduğu doğrulandı
- Geliştirme makinelerinden Docker'ı kaldırma seçeneği de değerlendiriliyor; düşük bellekli cihazlarda Docker olmadan sistemin kullanabildiği bellek artırılarak link süreleri iyileştirilebilir
- Mobil uygulama geliştirmede simülatörler çok fazla sistem belleği kullandığı için, bellek yükseltmesi geleceğe dönük bir maliyet olarak da mantıklı görüldü
Nihai karar ve yan etkiler
- incident.io, M1 cihazlarını 36GB bellekli temel M3 Pro ile yükseltmeye karar verdi
- M2 cihazların performansı zaten yeterince iyi göründüğünden şimdilik yükseltilmeyecek
- Dizüstü satın alma kararının ötesinde, geliştirme ortamı ve araçları hakkında da daha derin bir anlayış elde edildi
- Ekip şu sonuçlara ulaştı
- Geliştirici makine performansını ölçmek için iyi bir benchmark olarak Go derleme süresini belirledi
- Gerekli metrikleri izleyen kendi Go hot reloader aracını geliştirdi ve başka kullanılabilirlik iyileştirmeleri de elde etti
- Go derlemelerinin neden hızlandığını veya yavaşladığını daha iyi anladı
- OpenAI Assistants ile benzer veri analizi problemlerinin ele alınabileceğini doğruladı
- Apple yonga serileri arasındaki iyileşmeleri Go geliştiricisi bakış açısından nicel olarak ortaya koydu
- Belleğin önemli olduğu, ancak bunun toplam derleme süresinden ziyade linker süresinde daha net görüldüğü sonucuna vardı
1 yorum
Hacker News yorumları
Harika bir yazı; verileri toplama ve analiz etme biçiminin çeşitliliği de güzel. Ama her dizüstünü yan yana koyup aynı senaryoda zaman ölçümlü build çalıştırmak çok daha kolay ve doğru olurdu gibi geliyor
Tam build, son değişiklikler için artımlı build, belirli bir modülün yeniden derlenmesini gerektiren artımlı build gibi birkaç şeyi karşılaştırmak ya da son 100 Git commit'ini sırayla uygulayıp artımlı build sürelerini ölçen bir script'i bir gün içinde yazmak mümkün olurdu
Şirket genelindeki istatistikleri toplamak ciddi yanlılık yaratabilir. Örneğin yeni başlayanların M3, eski çalışanların M1 kullanma olasılığı daha yüksek olabilir; yeni başlayanlar daha çok küçük değişiklik yaparken deneyimliler kodun derinlerinde ya da karmaşık alanlarda çalışıp build sürelerinin uzamasına neden olabilir
Bu yüzden analizin kendisi etkileyici olsa da, örneklemdeki yerleşik yanlılıklar düşünüldüğünde şirket genelinde veri toplama mimarisi kurmadan önce her dizüstünde son commit'leri benchmark eden basit yöntemle başlamak daha doğru olurdu diye düşünüyorum
Bu verileri toplamamın nedeni cihazlar arası karşılaştırma da vardı ama asıl olarak geliştirici build sürelerine dair geçmiş veri biriktirmek, build performansını sürekli ölçmek ve regresyonları yakalamaktı
Build sürelerinin arttığını gördüğümüzde, build'i hızlandırmak için kod tabanı yapısını sık sık ayarlıyoruz
M3, M1'e göre build'i %30 daha hızlı yapabilir ama ağ build'i 15 kat daha hızlı. Geliştiricilere M3 vermek yerine ağ build'ine yatırım yapmak gerekip gerekmediği tartılabilirdi
Bağımsız örneklenmemiş verilere t-testi uygulanmış; birden fazla veri noktası farklı kişilerden gelmiş ve herkesin işi farklı olduğundan hesaplama gereksinimleri de değişebilir, dolayısıyla karıştırıcı etkenler oluşur. Bu, t-testinin temel varsayımlarını ihlal eder ama kod yorumlayıcı buna değinmemiş
Bunun yerine dizüstü sahibi, kıdem süresi gibi etkenleri rastgele etkiler olarak koyan bir doğrusal karma etkiler modeli kullanılabilirdi
Yine de verinin kendisi ilginç; özellikle RAM kısmı keyifliydi. Önbellek güçlüdür ve RAM'in fazla olması insanların düşündüğünden daha büyük kazanç sağlar. Genelde ihtiyaçtan fazla RAM'i olan MacBook'larda boştaki RAM'in çoğu önbellekle doldurulmuş olur
Yaklaşık bir hafta toplarsanız gerçek iş yükünün bir kesitini elde edebilir, o build'leri her donanım sınıfında tekrar çalıştırabilir ve daha sonra yeni donanımda da yeniden kullanabilirsiniz
Bir bilim insanı olarak bilgisayar programcılarının verilerle çalışma biçimini ilginç buluyorum
Güzel grafikler çizilmiş, analiz ChatGPT ile çok hızlı otomatikleştirilmiş ve ChatGPT oldukça makul görünen bir t-testi üretmiş
Ama bellek ve çip türüne göre değişim vardı; buna rağmen doğrusal regresyon düşünülmemiş ve karşılaştırması zor histogramlar çizilmiş. Basit ortalama ve hata çubukları eklenebilir ya da örtüşmeyi veya kaymayı görmeyi kolaylaştıran kümülatif dağılım fonksiyonu (CDF) kullanılabilirdi
Genellikle veriyi araçların gösterdiği biçimde ele alırsınız; bu da analiz, performans analizi ve gözlemlenebilirlik yazılım paketleriyle epey örtüşür
Ortalama bir yazılım mühendisinin CDF bilmesini beklemek, 3D grafiklerde kuaterniyonları ya da shader yazmanın temellerini bilmesini beklemeye benzer
Ya da kantil regresyon da mümkün. M3 > M2 > M1 hipotezi varsa, sıralı medyanlar için kullanılan bilinen Jonckheere–Terpstra testi bu tür sözde analiz için tam uygun olabilirdi
Örnek için bu sayfanın son grafiğine bakabilirsiniz: https://ggplot2.tidyverse.org/reference/stat_ecdf.html
Sağlam bir analiz, ancak kişisel deneyimime dayanarak bir konuda uyarmak isterim
2 bin çalışanlı orta ölçekli bir yazılım şirketinde geliştirici üretkenliğini artırmaya çalıştık ve yeni dizüstü bilgisayarlar almak yerine geliştirme yığınını AWS instance'larına taşıma seçeneğini araştırdık
Sonuçta yaklaşık 4 geliştiricinin tam zamanlı çalıştığı yıllar süren bir projeye dönüştü ve geriye dönüp bakınca maliyetine değecek bir faydası olmadı. Tamamen yerel bir geliştirme deneyimini bulutta yeniden üretmek hâlâ çok zor
Bu yüzden dizüstü bilgisayarları yükseltmenin daha iyi olduğunu düşünüyorum
Kod dizüstü bilgisayarda duruyor, ancak Docker build'i veya K8s dağıtımı olmadan uzak servislerle gerçek zamanlı senkronize oluyor; gerçekten yerelmiş gibi hissettiriyor
Özellikle kod yazarken entegrasyon testleri ve üstünü hemen çalıştırabildiğimiz için commit-push-pray döngüsünden kaçınabiliyoruz
Bunun için Garden(https://docs.garden.io) kullanıyoruz. Garden kullansanız da kullanmasanız da, doğru araçlar varsa iç geliştirme döngüsünde bulutun gücünden yararlanmak oldukça harika olabilir
Deneyimi daha ayrıntılı yazdığım yazı: https://thenewstack.io/one-year-of-remote-kubernetes-develop...
Yalnızca yerel sürümde mümkün olmayan pek çok şey de mümkün oldu. Örneğin birden fazla branch arasında geçiş yaparken yerel dosyaları değiştirmek yerine makine değiştirince iş değiştirme gecikmesi çok daha düşük oluyor
Bir şey yapmak için 200'den fazla parçayı ayağa kaldırmanız gerekiyorsa, yalnızca birkaç tanesiyle etkileşen tek bir parça üzerinde çalışmak bile zorlaşıyor
128+ çekirdekli, 256+ thread'li sunucuların olduğu bir çağda, çoğu yazılım için yeniden monolitin daha iyi olduğu düşüncesine kayıyorum
Düpedüz para ve zaman israfı. Tüm sistem çağrılarını satıcıların saçma yazılımlarıyla hook'layınca, çok sayıda alt süreç çalıştıran Unix tarzı toolchain'ler için bunun kötü olduğunu görebiliyorsunuz
Google, Meta gibi büyük teknoloji şirketlerinde yazılım mühendislerinin büyük çoğunluğunun geliştirme ortamı bulutta
Yerelden çok daha iyi bir geliştirme deneyimi
iOS geliştirme açısından maliyeti de hesaba katarak kişisel olarak yaptığım araştırmanın sonucu şuydu
M2 Pro iyi, ancak 10 çekirdekli M1 Pro'ya kıyasla iyileşme çok büyük değil. XcodeBenchmark'a göre 136 saniyeye karşı 120 saniye: https://github.com/devMEremenko/XcodeBenchmark
M3 Pro, M3 Max'ten ayrıştırılıp satılabilmesi için zayıflatılmış gibi hissettiriyor; yalnızca 6 performans çekirdeği olduğu için pratikte M2 Pro'ya benziyor
Sonunda az kullanılmış 10 çekirdekli M1 Pro aldım ve çok memnunum. Temel M3 Pro fiyatının yarısından da azına performansın %85'ini elde ettim; ayrıca genelde CPU'nun farkı hissedebilmek için en az %33-50 daha hızlı olması gerektiğini de hesaba kattım
M2 Pro'dan çok daha verimli ve performansı da biraz daha iyi. Bir dizüstü bilgisayarda istediğim şey de bu; bellek bant genişliği pek işime yaramıyor
Bu yazıda görülen fark kadar büyük bir fark yoktu. Dile veya projeye göre değişebilir, ama aynı derleme komutunu yan yana benchmark ettiğimde bu kadar büyük bir fark görmedim
Derleme toolchain'i farklı olduğu için şaşırtıcı değil; Go toolchain'inde de ek belleğin linker performansına yardımcı olması gibi, belirli özelliklerin build aşamalarında farklı etki ettiğini görebiliyorsunuz
M3 performansının tuhaf biçimde kısıtlandığına dair tepkileri de birkaç kez gördüm; umarım M4 sonrası modellerde bu devam etmez
120Hz de güzel olurdu ama Air dizüstü bilgisayarlara geleceğini sanmıyorum
Chromium ve Node.js’in eski çekirdek katkıcılarından, şu anda da gRPC Core/C++ çekirdek katkıcısıyım; derleme süresi yüzünden hiç ciddi biçimde dertlendiğimi hatırlamıyorum
Çalışırken ilgili birim testlerini yeniden çalıştırmak için yapılan artımlı derleme olan “etkileşimli derleme” var; bir de çalıştırıp kahve almaya ya da e-posta okumaya gittiğiniz etkileşimsiz derlemeler var. Donanım değişimiyle etkileşimsiz bir derlemenin etkileşimliye dönüştüğünü hiç görmedim
Kişisel makinem 5 yıldan eski bir Intel i7 ve 16 GB belleğe sahip; WSL’de Node.js’i linklemek için daha fazla belleğe ihtiyacım olduğunu fark edip 16 GB daha ekledim
İş dizüstüm Touch Bar’lı bir Intel MacBook Pro ve üretkenlik üzerinde büyük etkisi olduğunu düşünmüyorum. Önemli olan ekran boyutu ve kalitesi ile depolama hızı. CPU gelişiminden çok, artımlı derleme hızı ve dağıtık derleme desteği gibi derleme sisteminin etkisi daha büyük. Kişisel projelerimde Bazel kullanıyorum
Derleme ve linkleme aslında fiilen anında bitmeli; bir derleme aşaması olduğunu hissettirmeyecek kadar hızlı olmalı
Tüm program optimizasyonu gibi tekniklerin bulunduğu release derlemelerinin uzun sürmesi sorun değil; ama tipik derle/debug/test döngüsü anlık olabilir. Sistem dillerinin derlenmesi, legacy nedenlerle inanılması güç derecede yavaş; ama böyle olmak zorunda değil
BUILD dosyalarıyla uğraşmaya çok zaman harcayınca, sıradan bir Makefile’dan gerçekten daha değerli olup olmadığını sorguladım. Bu 3 yıl önceydi; açık ekosistem şimdi daha iyi hâle gelmiş olabilir
Depolama hızından emin değilim; bizim derlemelerimizin hepsi güçlü bir uzaktan geliştirme makinesinde çalışıyor
Yazıdaki gibi yapay zeka ile veri analizi yapmak isteyenler için, veriyi R ya da Stata gibi araçlara koyup doğrudan sorgulamanın çok daha kolay olduğunu düşünüyorum
Komutlar daha kısa ve kesin; en önemlisi de yeniden üretilebilirlik daha yüksek
Veri analizindeki en zor iş, veriyi ve onu üreten mekanizmayı anlamaktır. Bunun için problem alanına ait bir nedensel modele ihtiyaç vardır
Yapay zeka, o alandaki başka verilerle önceden eğitilmemişse işe yarar bir nedensel model oluşturabilir mi bilmiyorum. O model olmadan veriyi makul biçimde yorumlamak imkânsız; ayrıca mevcut yapay zeka modellerinin karıştırıcı değişkenleri, aşırı uç değer etkisini ve ilginç etki düzenleyici değişkenleri tespit edip edemediğini de merak ediyorum
Ben yaptığımda Python ve pandas’tı; analizde kullanılan kodu göstermesini isteyebilirsiniz
Fark, veriyi R/Python’a koyup “xyzzzy nasıl yapılır” diye arayarak kodu kendiniz yazmakla ChatGPT kullanmak arasında
“Tüm geliştiriciler incident.io ortamının tamamını dizüstünde yerel olarak çalıştırıyor ve kod değişikliğinden çalıştırmaya kadar 30 saniyenin altında geri bildirim döngüsü elde ediyor” kısmı bana en büyük başarı gibi görünüyor
Bir startup’a kısa süreli yardım ettiğim durumlar hariç, şirketin tüm geliştirme/yerel örneğini tek bir makinede çalıştırabildiğim bir şirkette bulunmadım
Her zaman erişilemeyen bir şey olurdu ve mutlaka tuzaklar çıkardı
İnsanların böyle berbat bir geliştirici deneyimine neden daha fazla öfkelenmediğini bilmiyorum. Günümüz üniversite çıkışlıları neyi kaçırdıklarının farkında değil gibi
O dünyayı yaşamamış biri bunun ne kadar daha iyi olduğunu anlayamıyor ve türlü türlü gerekçelerle rasyonalize ediyor
Ancak geçen yıl Snowflake ekledik; gerçekten bir sorunu çözüyor ama o kısım üzerinde yinelemeli geliştirme yapmak acı verici
Desteklenmesi gereken servis sayısına göre doğrusal, desteklenmesi gereken mühendis sayısına göre de doğrusal. Ayrıca pek uymayan çeşitli kullanım senaryoları ortaya çıkıyor; bir noktada altyapı ekibi özellik çıkarma hızının darboğazı hâline geliyor ve insanlar kendi farklı yöntemlerini kullanmaya başlıyor
O Pandora’nın kutusu açılınca geri çevirmek fiilen imkânsız. Yine de geliştirme döngüsünü saatler/günlerden dakikalara indirmek, dakikaları %25 azaltmaktan çok daha önemli
Şimdiye kadar iyi gidiyor
Yazının yazarı olarak, paylaştığın için teşekkürler
Go derleme profilini çıkarma, hot reloader geliştirme, derleme veri kümesini yapay zeka ile analiz etme gibi birçok konu var
Sonuç olarak M1’i M3 Pro’ya yükseltmeye değdi; testlerde Max büyük fark yaratmadı. M2, M3’e oldukça yakın olduğu için bizim için yükseltmeye değmedi
Sorularınız varsa yanıtlayabilirim
Bu maliyetin geri ödeme süresini nasıl etkilediğini de merak ediyorum
Yoksa işin çok hızlı bitmesi nedeniyle gerçek kullanımda fark yaratmaması da mümkün olabilir
Fikir ilginç, ancak veri analizi kalitesi oldukça düşük görünüyor ve gerçekten düşündüğümüz şeyi öğrenip öğrenmediğimizden emin değilim.
Özellikle M1 Pro'dan M2 Pro'ya geçildiğinde 20 saniyenin altındaki derlemelerin neden bu kadar dramatik biçimde arttığını anlamak zor. Kod derleme işlerinde ikisi arasındaki gerçek performans farkı yaklaşık %20-25.
M3 makinelerde M2 makinelere göre 20 saniyenin altında daha az derleme olması ya da çekirdek sayısı yarı yarıya olan M3 Pro'da M3 Max'e göre 20 saniyenin altında daha fazla derleme olması da pek mantıklı değil.
Farklı dizüstü bilgisayar türlerine sahip kişilerin genelde farklı işler yapması gibi geliştirici davranışı farklarının bu farkları yaratmış olması daha olası.
Üstünkörü okuyunca edindiğim birkaç gözleme göre Go derleyicisi ek çekirdeklerden pek yararlanmıyor gibi; verileri birleştirme yöntemi temelden sorunlu, karşılaştırma biçimi de histogram ile aralıklara bölünmüş yoğunluk grafiğini karıştırıyor ve y ekseni aralıkları da farklı olduğu için tutarlılık eksik.
Mac, pilde olduğu için CPU performansını kısmaz. Pille derleme gerçekten daha yavaşsa, yalnızca grafikten emin olmak zor ama bunun nedeni muhtemelen “Düşük Güç” ayarının açık olmasıdır.
Biraz konu dışı ama diğer şirketlerin uç nokta yönetimi ve güvenlik yazılımlarını geliştirici üretkenliğiyle nasıl dengelediğini merak ediyorum.
Bizim şirkette geliştirici dizüstülerinde hem Mac hem Windows tarafında arka planda 5'ten fazla servis çalışıyor. Bunlara uç nokta yönetimi, yetki yükseltme müdahalesi, TLS müdahalesi ve denetimi, kötü amaçlı yazılım koruması ve VPN istemcisi dahil.
Bu kombinasyon performansı ciddi biçimde etkiliyor. Makinede ne yaparsanız yapın bu servisler CPU ve girdi/çıktı performansını tüketiyor; geliştiriciler de rastgele donma ve takılmalardan şikâyet ediyor.
Fidye yazılımlarının ve fikri mülkiyet hırsızlığının artışı düşünüldüğünde güvenliğin gerekli olduğunu anlıyorum, ancak geliştirici üretkenliğini daha az etkileyerek güvenlik sağlayan daha iyi bir yol bulan şirketler var mı merak ediyorum.