WEBVTT

1
00:08.290 --> 00:09.640
Tekrar hoş geldiniz çocuklar.

2
00:10.180 --> 00:15.820
Şimdi sorduğum basit ve anlaşılır bir
soru, çok iş parçacıklı uygulamaların
eşdeğer

3
00:15.820 --> 00:20.140
tek iş parçacıklı uygulamalara kıyasla her
zaman daha üstün olup olmadığıdır.

4
00:20.650 --> 00:22.690
Sizce doğru olan nedir? Yani bunlar çok iş
parçacıklı, her zaman tek iş

5
00:23.260 --> 00:27.990
parçacıklıdan daha üstün olan mülakat
soruları mı? Ve çok iş parçacıklı
uygulamalar tek

6
00:28.390 --> 00:34.100
iş parçacıklı uygulamalara kıyasla her
zaman daha iyi performans gösterir mi?
Basit

7
00:35.200 --> 00:41.950
ve doğrudan cevap, uygulamadaki izole veri
yapılarının ve bağımsız sorumlulukların
derecesi ne

8
00:41.950 --> 00:49.000
kadar fazlaysa, uygulamaların çok iş
parçacıklı olma eğiliminin o kadar fazla
olduğudur.

9
00:49.540 --> 00:55.720
Uygulamaların veri yapılarının izole
olması, birbirlerine bağımlı olmadıkları
anlamına gelir.

10
00:55.990 --> 01:00.940
Eğer bir veri yapısını güncellersek, bu
bir sonraki veri yapısının güncellenmesini
tetiklemez.

11
01:01.210 --> 01:04.660
O zaman bu tür veri yapıları izole veri
yapıları olarak adlandırılır.

12
01:05.170 --> 01:05.590
Tamam.

13
01:05.890 --> 01:13.810
Ve uygulama mantığınız bağımsız
sorumluluklara bölünebiliyorsa, bu,
uygulamanızın bağımsız iş

14
01:13.810 --> 01:19.840
parçacıkları tarafından yürütülebileceği
ve bu türlerin bağımsız olduğu anlamına
gelir.

15
01:19.840 --> 01:22.060
Yani, birbirlerine müdahale etmezler.

16
01:22.450 --> 01:26.710
O halde böyle bir uygulama çok iş
parçacıklı olmalıdır, bu kadar basit.

17
01:28.060 --> 01:34.900
Böylece görevlere gerçekleştirmeleri için
bağımsız görevler atanabilir ve üçlüler

18
01:34.900 --> 01:36.470
birbirleriyle etkileşime girmeden izole
edilmiş veriler üzerinde çalışır.

19
01:36.490 --> 01:42.010
Müdahale etmek derken, kabilelerin
birbirleriyle herhangi bir ağırlık

20
01:42.010 --> 01:42.640
ve sinyalleşme yapmak zorunda olmadıkları
anlamına geliyor.

21
01:42.760 --> 01:49.300
Yani, üçüncü bir senkronizasyon ya da
tehdit işbirliği yoktur çünkü buna

22
01:49.300 --> 01:52.730
gerek yoktur çünkü iplikçiğin üzerinde
çalıştığı yapılar tamamen izole
edilmiştir.

23
01:53.590 --> 01:58.780
Her iş parçacığı, üzerinde işlem yapması
gereken veri yapılarının kendi kopyasına
sahiptir.

24
01:59.230 --> 02:01.990
Bu yüzden bekleyip birbirimize sinyal
vermeyi deneyeceğim.

25
02:02.620 --> 02:07.480
Yani bu, resimde görebileceğiniz gerçek
dünya örneğine benzer.

26
02:07.870 --> 02:16.210
Sol tarafta, arabalar iş parçacıklarını
temsil eder ve bu kartlar daha

27
02:16.210 --> 02:20.530
yavaş hareket eder çünkü arabalar arasında
paylaşılan kaynak olan yol sıkışıktır.

28
02:21.550 --> 02:27.790
Pekala, bir araba yavaşça hareket ediyor,
sadece yakındaki diğer bir araba ona yer
açıyor.

29
02:28.660 --> 02:29.110
Tamam.

30
02:29.350 --> 02:35.440
Dolayısıyla, Sean ve sol taraf gibi trafik
sıkışıklığına takıldığınızda,

31
02:35.740 --> 02:39.100
bir saat içinde yalnızca beş km ilerleme
eğiliminde olabilirsiniz.

32
02:39.910 --> 02:44.740
Aslında bu, Hindistan'daki Bangalore gibi
metro şehirlerinde yaygın bir senaryodur.

33
02:45.850 --> 02:48.010
Pekala, zamanının zirvesinde.

34
02:48.430 --> 02:56.710
Oysa bizim lüks hayatımızın tadını çıkaran
bu

35
02:56.920 --> 02:57.220
adam, buradaki kaynaklara özel bir erişime
sahip.

36
02:57.220 --> 02:59.230
Kaynaklar, yoldan başka bir şey yok.

37
03:00.490 --> 03:00.880
Tamam.

38
03:01.300 --> 03:06.610
Aynı kaynağa erişimde rekabet yoktur ve bu

39
03:06.610 --> 03:07.470
nedenle beş kilometreyi 10 dakikada kat
edebilir.

40
03:08.530 --> 03:14.050
Dolayısıyla, bunun sol tarafta tek bir
kaynağın çok sayıda kullanıcısı

41
03:14.050 --> 03:20.650
olduğu ve bu nedenle her kullanıcının aynı
kaynağa erişmek için

42
03:20.650 --> 03:21.190
diğerleriyle işbirliği yapmak zorunda
olduğu adil bir benzetme olduğunu
görebilirsiniz.

43
03:21.730 --> 03:26.230
Bu işbirliğini gerçekleştirmek için de bir
gecikme yaşanması gerekiyor.

44
03:26.890 --> 03:27.300
Tamam.

45
03:28.780 --> 03:34.660
Bu da basitçe, uygulamanız çok iş
parçacıklı ise, birden fazla iş

46
03:34.660 --> 03:40.900
parçacığının aynı kaynağımız için rekabet
etmesi ve rekabetin çok yüksek olması

47
03:40.900 --> 03:41.350
durumunda uygulamanızın daha iyi
performans göstermesinin gerekli olmadığı
anlamına gelir.

48
03:41.800 --> 03:47.980
Rekabet çok yüksek dediğimde, iş parçacığı
sayısının yeterince büyük

49
03:47.980 --> 03:54.310
ve kaynak sayısının yeterince düşük olduğu
anlamına gelir, bu

50
03:54.310 --> 03:54.940
durumda çok izlenen program çok kötü
performans gösterecektir.

51
03:55.900 --> 04:01.030
Programınızın enerjisinin çoğu sadece
ağırlık ve ipliklere sinyal vermek için
harcanacaktır.

52
04:01.870 --> 04:02.290
Tamam.

53
04:03.190 --> 04:08.740
Bu nedenle, bu tür senaryolarda
uygulamanızı tek iş parçacıklı olarak
uygulamak daha iyidir, bu

54
04:08.740 --> 04:13.210
tür senaryolarda tek iş parçacıklı bir
uygulamadan daha iyi bir performans elde
edecektiniz.

55
04:13.690 --> 04:19.570
Şimdi bir sonraki slayta geçerek,
uygulamanızın çok iş parçacıklı mı yoksa

56
04:19.570 --> 04:26.260
tek iş parçacıklı mı olması gerektiğine
karar vermek için uygulamanızın sahip

57
04:26.260 --> 04:27.340
olması gereken özelliklerin neler olduğunu
vurgulayalım. Diyelim ki Abby yeni bir

58
04:28.210 --> 04:33.460
uygulama tasarlamak istiyor ve tek iş
parçacıklı mı yoksa çok

59
04:33.460 --> 04:36.940
iş parçacıklı mı bir uygulama tasarlaması
gerektiği konusunda kafası karışık.

60
04:37.690 --> 04:42.910
Yanlış iplik modelini seçmenin uzun vadede
yıkıcı olacağını unutmayın.

61
04:43.540 --> 04:49.390
Uygulama için yanlış iş parçacığı modelini
seçerseniz, zamanın bir

62
04:49.390 --> 04:52.540
noktasında uygulamanızın yönetilmesinin
çok zor hale gelmesi saçma olabilir.

63
04:53.770 --> 04:55.600
Yani ileride, eğer.

64
04:56.730 --> 04:58.720
Uygulamanın boyutu çok büyük.

65
04:58.740 --> 05:03.440
Yani, uygulamanız, binlerce satıra
dağılmış yüz milyonlarca kod satırını,

66
05:03.450 --> 05:10.020
bu uygulamayı çok katmanlı olarak
uygulamaktan, bu uygulamayı çok

67
05:10.020 --> 05:12.120
iş parçacıklı bir uygulama olarak
uygulamaktan daha fazla söylüyor.

68
05:12.810 --> 05:17.550
O zaman küçük bir hata ve iş parçacığı
senkronizasyonu bile kilitlenmeye yol
açacaktır.

69
05:18.480 --> 05:23.970
Yani bu olumlu bir nokta, uygulamanızın
boyutu büyükse,

70
05:23.970 --> 05:25.620
uygulamanızı tek iş parçacıklı olarak
kodlamaya çalışın.

71
05:26.100 --> 05:29.480
Ancak elbette bu kriter tek kriter
değildir.

72
05:29.700 --> 05:34.560
Uygulamanızın boyutunun çok büyük olduğunu
ve tek iş parçacıklı gnome olarak
kodlandığını söylüyor.

73
05:34.770 --> 05:36.420
Bu, faktörlerden sadece bir tanesidir.

74
05:36.660 --> 05:38.700
Bakalım elimizde başka hangi faktörler
var.

75
05:39.540 --> 05:46.740
Ve uygulamanız orta büyüklükteyse, doğru

76
05:46.740 --> 05:47.460
senkronizasyonu uygulamak ve yönetmek
kolaydır.

77
05:47.970 --> 05:52.740
Unutmayın, senkronizasyon programlarını
takip etmek için programları yönetmek
zordur.

78
05:54.340 --> 06:02.080
Ekibinize yeni bir işe alım uzmanı aldınız
ve o sadece sinyalimizi

79
06:02.080 --> 06:04.060
beklemek için yanlış bir arama yaptı ve
başvurunuzun çıkmaza girdiğini duydu.

80
06:04.840 --> 06:05.260
Tamam.

81
06:06.550 --> 06:13.030
Dolayısıyla, orta büyüklükteki bir
uygulama bir kez daha çok iş parçacıklı
olmaya adaydır, ancak

82
06:13.030 --> 06:15.670
uygulamanızın çok iş parçacıklı olup
olmayacağına karar vermek için tek kriter
bu değildir.

83
06:15.940 --> 06:21.700
Bu, uygulamanızın çok iş parçacıklı olarak
kodlanıp kodlanmaması gerektiğini düşünmek
için sadece olumlu bir noktadır.

84
06:22.240 --> 06:28.390
Diğer bir nokta ise, eğer uygulamanız
örtüşen veri yapıları içeriyorsa, örtüşen

85
06:28.390 --> 06:34.390
veri yapılarının ne olduğunu daha önce
açıklamıştık, o zaman uygulamanız iş

86
06:34.390 --> 06:36.100
parçacıkları arasında çok fazla kilitleme
ve kilit açma ile sonuçlanacaktır.

87
06:36.820 --> 06:42.430
İş parçacıkları arasında çok fazla ağırlık
ve sinyalleşme olacaktır, bu nedenle bu

88
06:42.430 --> 06:46.120
sizi uygulamanızı tek iş parçacıklı olarak
uygulamaya itme eğiliminde olan bir
noktadır.

89
06:46.600 --> 06:53.740
Bununla birlikte, uygulamanız izole
edilmişse, veri standı ve terk

90
06:53.740 --> 06:55.120
edilmiş parçalar bu veri yapıları üzerinde
mevcut işlemleri gerçekleştirebilir.

91
06:55.420 --> 07:01.330
Bu da uygulamanızın çoklu iş parçacıklı
olarak uygulanmasını vurgulayan olumlu bir
noktadır.

92
07:02.230 --> 07:08.260
Benzer şekilde, uygulamanız mantık veya
işleme arasında net bir ayrım
göstermiyorsa, paralellik kapsamı

93
07:08.260 --> 07:13.690
olmadığı anlamına gelir, o zaman elbette
tek iş parçacıklı bir tasarıma gitmeniz
gerekir.

94
07:14.140 --> 07:21.340
Bunun tam tersi ise, uygulamanızda mantık
veya işlem sınırı

95
07:21.760 --> 07:25.240
açıkça varsa, bu uygulamanızın bağımsız
modüllere ayrılabileceği anlamına gelir.

96
07:25.570 --> 07:32.830
Daha sonra her modül bağımsız olarak
uygulanabilir, belirli bir sorumlulukla

97
07:32.830 --> 07:35.950
denenebilir ve böyle bir uygulama çok iş
parçacıklı olarak uygulanabilir.

98
07:38.500 --> 07:44.290
Diğer bir faktör de uygulamalarınızın
sıralı görevler gerçekleştirip
gerçekleştirmediğidir, eğer uygulama
mantığınız D1

99
07:44.290 --> 07:50.980
görevini, ardından veri görevini ve
ardından D3 görevini tam olarak aynı
sırada

100
07:50.980 --> 07:56.830
gerçekleştirmenizi gerektiriyorsa, bu tür
uygulamalar tek iş parçacıklı bir uygulama
olarak kodlanmalıdır.

101
07:57.250 --> 08:02.140
İş parçacıkları sırasında Görev D'yi iki
veya üç paralel olarak yürütemezsiniz.

102
08:03.040 --> 08:03.460
Tamam.

103
08:03.970 --> 08:07.450
Oysa uygulamanız mülk operatörü görevinde
uzman ise.

104
08:08.020 --> 08:13.510
Yani bu nokta ve bu nokta neredeyse
örtüşen

105
08:14.260 --> 08:19.660
noktalar aslında aynı şey olabilir mi?
Paralel atımların

106
08:19.660 --> 08:21.490
olduğu bu tür uygulamalar multithreading
olarak uygulanma eğilimindedir.

107
08:22.240 --> 08:28.480
Dolayısıyla, uygulanacak bir uygulama göz
önüne alındığında, geliştiricinin tüm

108
08:28.480 --> 08:30.640
bu cephelerde uygulama tasarımını ve
yapısını değerlendirmesi gerekir.

109
08:31.150 --> 08:37.270
Ve sonunda bir uygulamanın tek iş
parçacıklı mı yoksa

110
08:37.270 --> 08:38.770
çok iş parçacıklı mı olması gerektiğine
karar verilmesi gerekir.

111
08:39.850 --> 08:46.050
Ve unutmayın, bu kararın daha uygulamanın
ilk kod satırını yazmadan

112
08:47.200 --> 08:50.180
önce alınması gerekir ve yanlış karar bu
noktada alınır.

113
08:50.200 --> 08:53.710
Uygulamanın tüm uygulamasını çöpe
atacağız.

114
08:54.040 --> 08:59.380
Yirmi yıldan bu yana uygulamaları
uygulayan ve sürdüren şirketler var.

115
09:00.580 --> 09:01.030
Tamam.

116
09:01.420 --> 09:07.480
Dolayısıyla, uygulamalarının tek iş
parçacıklı mı yoksa çok iş

117
09:07.480 --> 09:10.960
parçacıklı mı kodlanması gerektiği kararı
yirmi yıl önce alınmıştır.

118
09:11.590 --> 09:16.390
Size pratik bir örnek ya da gerçek bir
örnek vereyim.

119
09:16.750 --> 09:20.290
Diyelim ki X şirketimiz var. Şimdi bu X
gerçek bir şirket.

120
09:20.290 --> 09:23.260
Sadece şirketin gerçek adını almak
istemiyorum.

121
09:23.770 --> 09:28.570
Ve bu X Şirketi yönlendirme protokollerini
ya da diyelim ki yönlendirme protokolünü
uygulamaya koydu.

122
09:28.570 --> 09:35.620
Diyelim ki ISIS, diyelim ki yönlendirme
protokolü veya SBF yönlendirme protokolü,
diyelim ki

123
09:35.620 --> 09:42.730
BGP vs. vs. Yani bu yönlendirme
protokolleri X Şirketi tarafından
uygulanan uygulamalardır.

124
09:43.730 --> 09:50.360
Bu uygulamalar X Şirketi tarafından yirmi
yılı aşkın bir süredir
ödüllendirilmektedir. Bu,

125
09:50.370 --> 09:56.240
şirketin aslında bu protokollerin her
birinin uygulanmasına neredeyse 1995
yılında başladığı ve

126
09:57.290 --> 10:02.780
bugün bile bu uygulamaların geliştiriciler
veya mühendisler tarafından geliştirildiği
anlamına gelmektedir.

127
10:04.400 --> 10:10.610
Şimdi, 1995 yılında, şirket bu
protokolleri tek iş parçacıklı mı yoksa
çok iş

128
10:10.610 --> 10:16.790
parçacıklı mı uygulamak istediğine ve bunu
olay döngüleri kullanarak mı yoksa C veya

129
10:16.790 --> 10:20.090
C++ veya başka bir programlama dili
kullanarak mı uygulamak istediğine karar
verdi.

130
10:20.480 --> 10:28.310
Bu karar 1995 yılında alınmıştır ve bu
karar bir kez alındıktan sonra

131
10:28.310 --> 10:32.330
değiştirilemez çünkü uygulamayı hayata
geçirmeye başladıktan sonra uygulamanın en
iyi tasarımı değiştirilemez.

132
10:32.950 --> 10:35.270
Bu çok maliyetli ya da çok zor.

133
10:36.730 --> 10:41.260
Dolayısıyla, uygulamanın temel tasarımını
değiştirmek, örneğin, uygulamanın
geliştirilmesinin üzerinden

134
10:41.260 --> 10:48.550
on yıl geçmişken uygulamayı tek iş
parçacıklıdan çok iş

135
10:48.550 --> 10:53.950
parçacıklıya dönüştürmek, şirkete yüz
milyonlarca dolara mal olacaktır, aslında

136
10:53.950 --> 10:55.360
bu şirket için yapılabilir bir iş bile
değildir.

137
10:56.120 --> 11:04.360
Diyelim ki şimdi yeni gelişen programlama
dili rust, yeni sistem

138
11:04.810 --> 11:07.900
programlamaya adapte edilmesi gereken yeni
nesil bir dil olarak görülüyor.

139
11:08.470 --> 11:13.600
Şimdi, diyelim ki şirket Protokol I'i C'de
uyguladı ve aradan yirmi yıl geçti.

140
11:14.320 --> 11:17.950
Ve şimdi bu özel assize, diyelim ki iki
milyon satır kod.

141
11:18.490 --> 11:25.420
Yani artık şirket, protokolün gözlerinin
kod tabanını tohumdan pasa değiştirmeyi
göze alamıyor.

142
11:25.900 --> 11:26.860
Bunu yapamaz.

143
11:26.870 --> 11:28.420
Bu mümkün değildir.

144
11:28.690 --> 11:36.430
Dolayısıyla, yeni bir programlama dilinin
piyasaya sürülmesi

145
11:36.430 --> 11:37.330
mevcut programlama dilini modası geçmiş
hale getirmez.

146
11:37.810 --> 11:44.740
Quora'da sık sık programlama dilinin
modasının geçip geçmediğine dair bazı

147
11:44.740 --> 11:51.130
web siteleri görüyorum, basitçe, sistem
programlama yapmak veya programlama
alanında

148
11:51.130 --> 11:52.630
ısrar etmek açısından görmeye daha yakın
bir programlama dili yok.

149
11:53.230 --> 11:58.870
Rust çok gelecek vaat eden bir dildir ve
büyük

150
11:58.870 --> 11:59.770
olasılıkla bu dil birçok yeni şirket
tarafından benimsenecektir.

151
12:00.070 --> 12:06.460
Ancak, son birkaç on yıldır şirketler
tarafından geliştirilen mevcut kod

152
12:06.760 --> 12:13.210
tabanlarımız, C gibi mevcut programlama
dillerinde uygulandıktan sonra, bu kod

153
12:13.210 --> 12:17.950
tabanlarını rust gibi yeni programlama
dillerine dönüştürmek neredeyse
imkansızdır.

154
12:18.310 --> 12:23.950
Çünkü iş açısından bakıldığında, müşteri
kendisine teslim

155
12:23.950 --> 12:27.250
edilen ürünün paslanıp paslanmadığını pek
umursamaz.

156
12:27.640 --> 12:35.830
Şirket, bir programlama dilinde uygulanan
bir kod tabanını diğerine dönüştürmek veya
bu zayıf tabanı bir

157
12:35.830 --> 12:42.970
iş parçacığı modelinden diğerine
dönüştürmek olan bu alıştırmayı yapmaktan
herhangi bir kar elde etmiyor.

158
12:43.930 --> 12:49.480
İşte bu, sizlerle paylaşmak istediğim
sektörel bir seviye.

159
12:49.930 --> 12:55.300
Aslında konudan biraz detay aldık ama yine
de iyi bir tartışma oldu.