işlemciler Hakkı'nda merak ettiğim bir husus var 4 çekirdek 8 iş parçacıkları yani 4 reel + 4 sanal çekirdekli işlemciler xeon e5620 üzerinden gidecek olursak 2.4 ghz hızında 8 iş parçacığı olan bu model için 8 adet 2.4 ghz mi olmuş oluyor elimizde yoksa 4 adet 2.4 ghz mi Çift xeon e5620 64 gb ram 4x256 SSD li bir cihazı hepsi Windows olacak şekilde 16 sanal makineye ayırsak Nasıl bir performans bekleyebiliriz bu sanallardan ve ana makineye ne kadar bırakmak gerekir... said addicted.

Burasi biraz tatava Hocam bu islemcilerin icinde register denilen dalgalar var, yuksek seviyeli dillerdeki degiskenler gibi dusunebilirsin bunlari ancak sinirli sayida ve chip in icinde gomulu bellek alanlari. Mesela eax register i 4 byte lik bir bellek alanidir ve tek bir islemcide tektir.. Islemci de program calistirirken datalari bu register lari kullanarak manipule eder, mesela bellekteki sayilari toplamadan once bu register lara alir, toplama yapip sonucu tekrar bellege yazar vs. Bu durumda tek cekirdekli bir islemci thread leri calistirirken mesela 20 ms de bir thread ler arasinda gecis yapar, bu islem hizli oldugu icin akistaki kesintileri farketmeyiz. Bir islemci deki bu register setine context, bir thread den digerine gecerken bu context in bir yere kaydedilip , sonraki thread in context inin yuklenmesi islemine de context switch denir. Thread = konuda bahsedilen is parcacigi. Hyperthreading de olay soyle isliyor. Aslinda 4 gercek cekirdek var, yani bu islemciler ayni anda 4 islem yapabilirler. Ancak her bir cekirdek, bir degil 2 adet register setine yani context e sahip. Eger isletim sistemi islemcinin bu ozelliginin farkinda ise, ayni thread i tekrar ayni sanal cekirdekte calistirarak ya da kafasina gore bu ozellikten istifade edecek bir algoritma kullanarak context switch islemini oldukca hizlandirabilir. Yani 4 gercek 8 cekirdekli bir islemci, ayni anda 8 thread calsitiriyorsa aslinda hic context switch olmaz bile. Cunku 8 tane context var zaten. Eger sadece 4 gercek cekirdek olsaydi, diger 4 thread calisirken bir onceki threadlerin context leri kaydedilmek zorunda kalinacakti bellege. Bu context switch islemi cok kritik bir islem oldugu icin genellikle assembly ile cok optimize yazilir, cunku en siklikla calisan kod blogu orasi ve oradaki minik bir optimizasyon bile sistemin genelinde onemli etkiye sebep oluyor. Bu hyperthread ler belki islemciyi 2 kat hizlandirmaz ancak yapilan isleme gore 1.2, 1.5 kat hizlandirir, ve neredeyse ek bir maliyet getirmeden. Burasi senin soruna cevap Simdi cok mesgul yani surekli cpu kullanan bir server bile yazilirken kullanilan yontem sudur, mevcut cpu sayisinin 2 kati kadar worker thread kullan. Cunku en mesgul server bile her an mesgul olamaz cpu da, cogu zaman input bekliyor ya da baska islemlerden dolayi zaman kaybediyor, bu esnada bosta kalan cpu suresi diger threadler tarafindan kullaniliyor. Eger surekli mesgul olunmayacaksa, ki cogumuzun bilgisayari 24 saatin minimum 20 saatini cpu idle modda iken geciriyor, islemci degil ram ve disk io asil dikkat edilmesi gereken. Yani sen 4 gercek cekirdekli bir sanal makina actigin zaman, eger yogun bir is yaptirmiyorsan bunlara cpu kullanimi ana makinada bile %0-10 arasinda olacak. Ancak ram kullanimi sanal makina sayisi arttikca artacak. Daha kotusu, hatta tum testlerimize gore en kotusu disk io. Sunu hep aklinda tut, pentium 4 den beri CPU neredeyse asla bottleneck olmadi, her zaman ram ya da disk IO bottleneck oldu. Ram ve disk in de soyle bir iliskisi var, ram in az ise, tum isletim sistemleri disk i ram in uzantisi gibi kullaniyor, unix de swap windows da pagefile. sys dosyasi. Yani sen ram i doldurursan en az kullanilan ram bolgeleri diske yazilir , haliyle bir daha oralara erismek istediginde disk erisimi olur, o da inanilmaz yavas bir islem eski disklerde. SSD ler ciktiktan sonra, ram az bile olsa SSD hizli oldugu icin bilgisayar yine akar, ram kadar degil ama cildirtmaz. Ozetle eger ortada bir bottleneck yani zayif halka varsa o her zaman DISK tir, CPU uzerinden bosuna optimizasyon yapmaya calisma. Ne yapman gerektigini soyleyim. Tek bir 2TB lik SSD alma, paralel is yapmak istiyorsan 256 GB lik 8 tane SSD al ve her sanal makina kendi SSD sinde calissin, boylece storage ayni kalmisken throughput yani IO 8 katina cikmis olur. Ram in de varsa CPU dan asla korkma. Hocam bunun çıktısını al. Baş ucu kitabi olarak koy. Aç aç oku. Cidden güzel bir anlatım yapmışsın. tşk. Bu aralar fazla yogunum. Unuttugum seyler oluyorsa affola. DM vs atın.

Burasi biraz tatava Hocam bu islemcilerin icinde register denilen dalgalar var, yuksek seviyeli dillerdeki degiskenler gibi dusunebilirsin bunlari ancak sinirli sayida ve chip in icinde gomulu bellek alanlari. Mesela eax register i 4 byte lik bir bellek alanidir ve tek bir islemcide tektir.. Islemci de program calistirirken datalari bu register lari kullanarak manipule eder, mesela bellekteki sayilari toplamadan once bu register lara alir, toplama yapip sonucu tekrar bellege yazar vs. Bu durumda tek cekirdekli bir islemci thread leri calistirirken mesela 20 ms de bir thread ler arasinda gecis yapar, bu islem hizli oldugu icin akistaki kesintileri farketmeyiz. Bir islemci deki bu register setine context, bir thread den digerine gecerken bu context in bir yere kaydedilip , sonraki thread in context inin yuklenmesi islemine de context switch denir. Thread = konuda bahsedilen is parcacigi. Hyperthreading de olay soyle isliyor. Aslinda 4 gercek cekirdek var, yani bu islemciler ayni anda 4 islem yapabilirler. Ancak her bir cekirdek, bir degil 2 adet register setine yani context e sahip. Eger isletim sistemi islemcinin bu ozelliginin farkinda ise, ayni thread i tekrar ayni sanal cekirdekte calistirarak ya da kafasina gore bu ozellikten istifade edecek bir algoritma kullanarak context switch islemini oldukca hizlandirabilir. Yani 4 gercek 8 cekirdekli bir islemci, ayni anda 8 thread calsitiriyorsa aslinda hic context switch olmaz bile. Cunku 8 tane context var zaten. Eger sadece 4 gercek cekirdek olsaydi, diger 4 thread calisirken bir onceki threadlerin context leri kaydedilmek zorunda kalinacakti bellege. Bu context switch islemi cok kritik bir islem oldugu icin genellikle assembly ile cok optimize yazilir, cunku en siklikla calisan kod blogu orasi ve oradaki minik bir optimizasyon bile sistemin genelinde onemli etkiye sebep oluyor. Bu hyperthread ler belki islemciyi 2 kat hizlandirmaz ancak yapilan isleme gore 1.2, 1.5 kat hizlandirir, ve neredeyse ek bir maliyet getirmeden. Burasi senin soruna cevap Simdi cok mesgul yani surekli cpu kullanan bir server bile yazilirken kullanilan yontem sudur, mevcut cpu sayisinin 2 kati kadar worker thread kullan. Cunku en mesgul server bile her an mesgul olamaz cpu da, cogu zaman input bekliyor ya da baska islemlerden dolayi zaman kaybediyor, bu esnada bosta kalan cpu suresi diger threadler tarafindan kullaniliyor. Eger surekli mesgul olunmayacaksa, ki cogumuzun bilgisayari 24 saatin minimum 20 saatini cpu idle modda iken geciriyor, islemci degil ram ve disk io asil dikkat edilmesi gereken. Yani sen 4 gercek cekirdekli bir sanal makina actigin zaman, eger yogun bir is yaptirmiyorsan bunlara cpu kullanimi ana makinada bile %0-10 arasinda olacak. Ancak ram kullanimi sanal makina sayisi arttikca artacak. Daha kotusu, hatta tum testlerimize gore en kotusu disk io. Sunu hep aklinda tut, pentium 4 den beri CPU neredeyse asla bottleneck olmadi, her zaman ram ya da disk IO bottleneck oldu. Ram ve disk in de soyle bir iliskisi var, ram in az ise, tum isletim sistemleri disk i ram in uzantisi gibi kullaniyor, unix de swap windows da pagefile. sys dosyasi. Yani sen ram i doldurursan en az kullanilan ram bolgeleri diske yazilir , haliyle bir daha oralara erismek istediginde disk erisimi olur, o da inanilmaz yavas bir islem eski disklerde. SSD ler ciktiktan sonra, ram az bile olsa SSD hizli oldugu icin bilgisayar yine akar, ram kadar degil ama cildirtmaz. Ozetle eger ortada bir bottleneck yani zayif halka varsa o her zaman DISK tir, CPU uzerinden bosuna optimizasyon yapmaya calisma. Ne yapman gerektigini soyleyim. Tek bir 2TB lik SSD alma, paralel is yapmak istiyorsan 256 GB lik 8 tane SSD al ve her sanal makina kendi SSD sinde calissin, boylece storage ayni kalmisken throughput yani IO 8 katina cikmis olur. Ram in de varsa CPU dan asla korkma. android'te byle çalışıyor diyebiliriz. yalnız 4.4 te android ram sıkıştırma işini tekrar ram içinde tutarak yapıyordu sanırım emin değilim.

Tugberk bunu yazdı Burasi biraz tatava Hocam bu islemcilerin icinde register denilen dalgalar var, yuksek seviyeli dillerdeki degiskenler gibi dusunebilirsin bunlari ancak sinirli sayida ve chip in icinde gomulu bellek alanlari. Mesela eax register i 4 byte lik bir bellek alanidir ve tek bir islemcide tektir.. Islemci de program calistirirken datalari bu register lari kullanarak manipule eder, mesela bellekteki sayilari toplamadan once bu register lara alir, toplama yapip sonucu tekrar bellege yazar vs. Bu durumda tek cekirdekli bir islemci thread leri calistirirken mesela 20 ms de bir thread ler arasinda gecis yapar, bu islem hizli oldugu icin akistaki kesintileri farketmeyiz. Bir islemci deki bu register setine context, bir thread den digerine gecerken bu context in bir yere kaydedilip , sonraki thread in context inin yuklenmesi islemine de context switch denir. Thread = konuda bahsedilen is parcacigi. Hyperthreading de olay soyle isliyor. Aslinda 4 gercek cekirdek var, yani bu islemciler ayni anda 4 islem yapabilirler. Ancak her bir cekirdek, bir degil 2 adet register setine yani context e sahip. Eger isletim sistemi islemcinin bu ozelliginin farkinda ise, ayni thread i tekrar ayni sanal cekirdekte calistirarak ya da kafasina gore bu ozellikten istifade edecek bir algoritma kullanarak context switch islemini oldukca hizlandirabilir. Yani 4 gercek 8 cekirdekli bir islemci, ayni anda 8 thread calsitiriyorsa aslinda hic context switch olmaz bile. Cunku 8 tane context var zaten. Eger sadece 4 gercek cekirdek olsaydi, diger 4 thread calisirken bir onceki threadlerin context leri kaydedilmek zorunda kalinacakti bellege. Bu context switch islemi cok kritik bir islem oldugu icin genellikle assembly ile cok optimize yazilir, cunku en siklikla calisan kod blogu orasi ve oradaki minik bir optimizasyon bile sistemin genelinde onemli etkiye sebep oluyor. Bu hyperthread ler belki islemciyi 2 kat hizlandirmaz ancak yapilan isleme gore 1.2, 1.5 kat hizlandirir, ve neredeyse ek bir maliyet getirmeden. Burasi senin soruna cevap Simdi cok mesgul yani surekli cpu kullanan bir server bile yazilirken kullanilan yontem sudur, mevcut cpu sayisinin 2 kati kadar worker thread kullan. Cunku en mesgul server bile her an mesgul olamaz cpu da, cogu zaman input bekliyor ya da baska islemlerden dolayi zaman kaybediyor, bu esnada bosta kalan cpu suresi diger threadler tarafindan kullaniliyor. Eger surekli mesgul olunmayacaksa, ki cogumuzun bilgisayari 24 saatin minimum 20 saatini cpu idle modda iken geciriyor, islemci degil ram ve disk io asil dikkat edilmesi gereken. Yani sen 4 gercek cekirdekli bir sanal makina actigin zaman, eger yogun bir is yaptirmiyorsan bunlara cpu kullanimi ana makinada bile %0-10 arasinda olacak. Ancak ram kullanimi sanal makina sayisi arttikca artacak. Daha kotusu, hatta tum testlerimize gore en kotusu disk io. Sunu hep aklinda tut, pentium 4 den beri CPU neredeyse asla bottleneck olmadi, her zaman ram ya da disk IO bottleneck oldu. Ram ve disk in de soyle bir iliskisi var, ram in az ise, tum isletim sistemleri disk i ram in uzantisi gibi kullaniyor, unix de swap windows da pagefile. sys dosyasi. Yani sen ram i doldurursan en az kullanilan ram bolgeleri diske yazilir , haliyle bir daha oralara erismek istediginde disk erisimi olur, o da inanilmaz yavas bir islem eski disklerde. SSD ler ciktiktan sonra, ram az bile olsa SSD hizli oldugu icin bilgisayar yine akar, ram kadar degil ama cildirtmaz. Ozetle eger ortada bir bottleneck yani zayif halka varsa o her zaman DISK tir, CPU uzerinden bosuna optimizasyon yapmaya calisma. Ne yapman gerektigini soyleyim. Tek bir 2TB lik SSD alma, paralel is yapmak istiyorsan 256 GB lik 8 tane SSD al ve her sanal makina kendi SSD sinde calissin, boylece storage ayni kalmisken throughput yani IO 8 katina cikmis olur. Ram in de varsa CPU dan asla korkma. Hocam bunun çıktısını al. Baş ucu kitabi olarak koy. Aç aç oku. Cidden güzel bir anlatım yapmışsın. tşk. Hayır, bu yazıyı A0 kağıda büyük puntoyla bastırıp evin baş kşesine koy. yle güzel bir anlatım olmuş. If my calculations are correct, when this baby hits eighty-eight miles per hour... you"re gonna see some serious shit.

Burasi biraz tatava Hocam bu islemcilerin icinde register denilen dalgalar var, yuksek seviyeli dillerdeki degiskenler gibi dusunebilirsin bunlari ancak sinirli sayida ve chip in icinde gomulu bellek alanlari. Mesela eax register i 4 byte lik bir bellek alanidir ve tek bir islemcide tektir.. Islemci de program calistirirken datalari bu register lari kullanarak manipule eder, mesela bellekteki sayilari toplamadan once bu register lara alir, toplama yapip sonucu tekrar bellege yazar vs. Bu durumda tek cekirdekli bir islemci thread leri calistirirken mesela 20 ms de bir thread ler arasinda gecis yapar, bu islem hizli oldugu icin akistaki kesintileri farketmeyiz. Bir islemci deki bu register setine context, bir thread den digerine gecerken bu context in bir yere kaydedilip , sonraki thread in context inin yuklenmesi islemine de context switch denir. Thread = konuda bahsedilen is parcacigi. Hyperthreading de olay soyle isliyor. Aslinda 4 gercek cekirdek var, yani bu islemciler ayni anda 4 islem yapabilirler. Ancak her bir cekirdek, bir degil 2 adet register setine yani context e sahip. Eger isletim sistemi islemcinin bu ozelliginin farkinda ise, ayni thread i tekrar ayni sanal cekirdekte calistirarak ya da kafasina gore bu ozellikten istifade edecek bir algoritma kullanarak context switch islemini oldukca hizlandirabilir. Yani 4 gercek 8 cekirdekli bir islemci, ayni anda 8 thread calsitiriyorsa aslinda hic context switch olmaz bile. Cunku 8 tane context var zaten. Eger sadece 4 gercek cekirdek olsaydi, diger 4 thread calisirken bir onceki threadlerin context leri kaydedilmek zorunda kalinacakti bellege. Bu context switch islemi cok kritik bir islem oldugu icin genellikle assembly ile cok optimize yazilir, cunku en siklikla calisan kod blogu orasi ve oradaki minik bir optimizasyon bile sistemin genelinde onemli etkiye sebep oluyor. Bu hyperthread ler belki islemciyi 2 kat hizlandirmaz ancak yapilan isleme gore 1.2, 1.5 kat hizlandirir, ve neredeyse ek bir maliyet getirmeden. Burasi senin soruna cevap Simdi cok mesgul yani surekli cpu kullanan bir server bile yazilirken kullanilan yontem sudur, mevcut cpu sayisinin 2 kati kadar worker thread kullan. Cunku en mesgul server bile her an mesgul olamaz cpu da, cogu zaman input bekliyor ya da baska islemlerden dolayi zaman kaybediyor, bu esnada bosta kalan cpu suresi diger threadler tarafindan kullaniliyor. Eger surekli mesgul olunmayacaksa, ki cogumuzun bilgisayari 24 saatin minimum 20 saatini cpu idle modda iken geciriyor, islemci degil ram ve disk io asil dikkat edilmesi gereken. Yani sen 4 gercek cekirdekli bir sanal makina actigin zaman, eger yogun bir is yaptirmiyorsan bunlara cpu kullanimi ana makinada bile %0-10 arasinda olacak. Ancak ram kullanimi sanal makina sayisi arttikca artacak. Daha kotusu, hatta tum testlerimize gore en kotusu disk io. Sunu hep aklinda tut, pentium 4 den beri CPU neredeyse asla bottleneck olmadi, her zaman ram ya da disk IO bottleneck oldu. Ram ve disk in de soyle bir iliskisi var, ram in az ise, tum isletim sistemleri disk i ram in uzantisi gibi kullaniyor, unix de swap windows da pagefile. sys dosyasi. Yani sen ram i doldurursan en az kullanilan ram bolgeleri diske yazilir , haliyle bir daha oralara erismek istediginde disk erisimi olur, o da inanilmaz yavas bir islem eski disklerde. SSD ler ciktiktan sonra, ram az bile olsa SSD hizli oldugu icin bilgisayar yine akar, ram kadar degil ama cildirtmaz. Ozetle eger ortada bir bottleneck yani zayif halka varsa o her zaman DISK tir, CPU uzerinden bosuna optimizasyon yapmaya calisma. Ne yapman gerektigini soyleyim. Tek bir 2TB lik SSD alma, paralel is yapmak istiyorsan 256 GB lik 8 tane SSD al ve her sanal makina kendi SSD sinde calissin, boylece storage ayni kalmisken throughput yani IO 8 katina cikmis olur. Ram in de varsa CPU dan asla korkma. tuğberk hocam gene dktürmüşsün sistem programlama ve donanım bilgini. Kaç yıldır yoktun tbt'de. Seni grmek bir şeref. Bu imzayı her grdüğünüzde 4gb kotanızın 0,00000358559191226959228515625 azalmaktadır. Bilerek ve istenerek bu imza yapılmıştır. Amaç kotanızı smürmektir

@Tugberk Hocam sen ne zaman yorum atsan byle oluyorum. Sayende aydınlanıyoruz :) Jilet_Boris tarafından 07/Eyl/16 14:32 tarihinde düzenlenmiştir

Burasi biraz tatava Hocam bu islemcilerin icinde register denilen dalgalar var, yuksek seviyeli dillerdeki degiskenler gibi dusunebilirsin bunlari ancak sinirli sayida ve chip in icinde gomulu bellek alanlari. Mesela eax register i 4 byte lik bir bellek alanidir ve tek bir islemcide tektir.. Islemci de program calistirirken datalari bu register lari kullanarak manipule eder, mesela bellekteki sayilari toplamadan once bu register lara alir, toplama yapip sonucu tekrar bellege yazar vs. Bu durumda tek cekirdekli bir islemci thread leri calistirirken mesela 20 ms de bir thread ler arasinda gecis yapar, bu islem hizli oldugu icin akistaki kesintileri farketmeyiz. Bir islemci deki bu register setine context, bir thread den digerine gecerken bu context in bir yere kaydedilip , sonraki thread in context inin yuklenmesi islemine de context switch denir. Thread = konuda bahsedilen is parcacigi. Hyperthreading de olay soyle isliyor. Aslinda 4 gercek cekirdek var, yani bu islemciler ayni anda 4 islem yapabilirler. Ancak her bir cekirdek, bir degil 2 adet register setine yani context e sahip. Eger isletim sistemi islemcinin bu ozelliginin farkinda ise, ayni thread i tekrar ayni sanal cekirdekte calistirarak ya da kafasina gore bu ozellikten istifade edecek bir algoritma kullanarak context switch islemini oldukca hizlandirabilir. Yani 4 gercek 8 cekirdekli bir islemci, ayni anda 8 thread calsitiriyorsa aslinda hic context switch olmaz bile. Cunku 8 tane context var zaten. Eger sadece 4 gercek cekirdek olsaydi, diger 4 thread calisirken bir onceki threadlerin context leri kaydedilmek zorunda kalinacakti bellege. Bu context switch islemi cok kritik bir islem oldugu icin genellikle assembly ile cok optimize yazilir, cunku en siklikla calisan kod blogu orasi ve oradaki minik bir optimizasyon bile sistemin genelinde onemli etkiye sebep oluyor. Bu hyperthread ler belki islemciyi 2 kat hizlandirmaz ancak yapilan isleme gore 1.2, 1.5 kat hizlandirir, ve neredeyse ek bir maliyet getirmeden. Burasi senin soruna cevap Simdi cok mesgul yani surekli cpu kullanan bir server bile yazilirken kullanilan yontem sudur, mevcut cpu sayisinin 2 kati kadar worker thread kullan. Cunku en mesgul server bile her an mesgul olamaz cpu da, cogu zaman input bekliyor ya da baska islemlerden dolayi zaman kaybediyor, bu esnada bosta kalan cpu suresi diger threadler tarafindan kullaniliyor. Eger surekli mesgul olunmayacaksa, ki cogumuzun bilgisayari 24 saatin minimum 20 saatini cpu idle modda iken geciriyor, islemci degil ram ve disk io asil dikkat edilmesi gereken. Yani sen 4 gercek cekirdekli bir sanal makina actigin zaman, eger yogun bir is yaptirmiyorsan bunlara cpu kullanimi ana makinada bile %0-10 arasinda olacak. Ancak ram kullanimi sanal makina sayisi arttikca artacak. Daha kotusu, hatta tum testlerimize gore en kotusu disk io. Sunu hep aklinda tut, pentium 4 den beri CPU neredeyse asla bottleneck olmadi, her zaman ram ya da disk IO bottleneck oldu. Ram ve disk in de soyle bir iliskisi var, ram in az ise, tum isletim sistemleri disk i ram in uzantisi gibi kullaniyor, unix de swap windows da pagefile. sys dosyasi. Yani sen ram i doldurursan en az kullanilan ram bolgeleri diske yazilir , haliyle bir daha oralara erismek istediginde disk erisimi olur, o da inanilmaz yavas bir islem eski disklerde. SSD ler ciktiktan sonra, ram az bile olsa SSD hizli oldugu icin bilgisayar yine akar, ram kadar degil ama cildirtmaz. Ozetle eger ortada bir bottleneck yani zayif halka varsa o her zaman DISK tir, CPU uzerinden bosuna optimizasyon yapmaya calisma. Ne yapman gerektigini soyleyim. Tek bir 2TB lik SSD alma, paralel is yapmak istiyorsan 256 GB lik 8 tane SSD al ve her sanal makina kendi SSD sinde calissin, boylece storage ayni kalmisken throughput yani IO 8 katina cikmis olur. Ram in de varsa CPU dan asla korkma.

Burasi biraz tatava Hocam bu islemcilerin icinde register denilen dalgalar var, yuksek seviyeli dillerdeki degiskenler gibi dusunebilirsin bunlari ancak sinirli sayida ve chip in icinde gomulu bellek alanlari. Mesela eax register i 4 byte lik bir bellek alanidir ve tek bir islemcide tektir.. Islemci de program calistirirken datalari bu register lari kullanarak manipule eder, mesela bellekteki sayilari toplamadan once bu register lara alir, toplama yapip sonucu tekrar bellege yazar vs. Bu durumda tek cekirdekli bir islemci thread leri calistirirken mesela 20 ms de bir thread ler arasinda gecis yapar, bu islem hizli oldugu icin akistaki kesintileri farketmeyiz. Bir islemci deki bu register setine context, bir thread den digerine gecerken bu context in bir yere kaydedilip , sonraki thread in context inin yuklenmesi islemine de context switch denir. Thread = konuda bahsedilen is parcacigi. Hyperthreading de olay soyle isliyor. Aslinda 4 gercek cekirdek var, yani bu islemciler ayni anda 4 islem yapabilirler. Ancak her bir cekirdek, bir degil 2 adet register setine yani context e sahip. Eger isletim sistemi islemcinin bu ozelliginin farkinda ise, ayni thread i tekrar ayni sanal cekirdekte calistirarak ya da kafasina gore bu ozellikten istifade edecek bir algoritma kullanarak context switch islemini oldukca hizlandirabilir. Yani 4 gercek 8 cekirdekli bir islemci, ayni anda 8 thread calsitiriyorsa aslinda hic context switch olmaz bile. Cunku 8 tane context var zaten. Eger sadece 4 gercek cekirdek olsaydi, diger 4 thread calisirken bir onceki threadlerin context leri kaydedilmek zorunda kalinacakti bellege. Bu context switch islemi cok kritik bir islem oldugu icin genellikle assembly ile cok optimize yazilir, cunku en siklikla calisan kod blogu orasi ve oradaki minik bir optimizasyon bile sistemin genelinde onemli etkiye sebep oluyor. Bu hyperthread ler belki islemciyi 2 kat hizlandirmaz ancak yapilan isleme gore 1.2, 1.5 kat hizlandirir, ve neredeyse ek bir maliyet getirmeden. Burasi senin soruna cevap Simdi cok mesgul yani surekli cpu kullanan bir server bile yazilirken kullanilan yontem sudur, mevcut cpu sayisinin 2 kati kadar worker thread kullan. Cunku en mesgul server bile her an mesgul olamaz cpu da, cogu zaman input bekliyor ya da baska islemlerden dolayi zaman kaybediyor, bu esnada bosta kalan cpu suresi diger threadler tarafindan kullaniliyor. Eger surekli mesgul olunmayacaksa, ki cogumuzun bilgisayari 24 saatin minimum 20 saatini cpu idle modda iken geciriyor, islemci degil ram ve disk io asil dikkat edilmesi gereken. Yani sen 4 gercek cekirdekli bir sanal makina actigin zaman, eger yogun bir is yaptirmiyorsan bunlara cpu kullanimi ana makinada bile %0-10 arasinda olacak. Ancak ram kullanimi sanal makina sayisi arttikca artacak. Daha kotusu, hatta tum testlerimize gore en kotusu disk io. Sunu hep aklinda tut, pentium 4 den beri CPU neredeyse asla bottleneck olmadi, her zaman ram ya da disk IO bottleneck oldu. Ram ve disk in de soyle bir iliskisi var, ram in az ise, tum isletim sistemleri disk i ram in uzantisi gibi kullaniyor, unix de swap windows da pagefile. sys dosyasi. Yani sen ram i doldurursan en az kullanilan ram bolgeleri diske yazilir , haliyle bir daha oralara erismek istediginde disk erisimi olur, o da inanilmaz yavas bir islem eski disklerde. SSD ler ciktiktan sonra, ram az bile olsa SSD hizli oldugu icin bilgisayar yine akar, ram kadar degil ama cildirtmaz. Ozetle eger ortada bir bottleneck yani zayif halka varsa o her zaman DISK tir, CPU uzerinden bosuna optimizasyon yapmaya calisma. Ne yapman gerektigini soyleyim. Tek bir 2TB lik SSD alma, paralel is yapmak istiyorsan 256 GB lik 8 tane SSD al ve her sanal makina kendi SSD sinde calissin, boylece storage ayni kalmisken throughput yani IO 8 katina cikmis olur. Ram in de varsa CPU dan asla korkma. Tesekkürler hocam. .. you only have you..