در این مطلب، ویدئو جیمز پاول – Furious & Fast Python 7: Writing Fast Python Code | PyData Fest Amsterdam 2020 با زیرنویس فارسی را برای دانلود قرار داده ام. شما میتوانید با پرداخت 15 هزار تومان ، این ویدیو به علاوه تمامی فیلم های سایت را دانلود کنید.اکثر فیلم های سایت به زبان انگلیسی می باشند. این ویدئو دارای زیرنویس فارسی ترجمه شده توسط هوش مصنوعی می باشد که میتوانید نمونه ای از آن را در قسمت پایانی این مطلب مشاهده کنید.
مدت زمان فیلم: 1:12:13
تصاویر این ویدئو:
قسمتی از زیرنویس این فیلم:
00:00:07,359 –> 00:00:09,040
سلام به همه صبح بخیر
2
00:00:09,040 –> 00:00:12,880
همه شما بروید صبح بخیر جیمز
3
00:00:12,880 –> 00:00:16,160
چطورید حال من خیلی خوب است
4
00:00:16,160 –> 00:00:17,840
و از اینکه من را دعوت کردید بسیار متشکرم،
5
00:00:17,840 –> 00:00:19,600
ما فقط در یک لحظه شروع می کنیم،
6
00:00:19,600 –> 00:00:21,600
خوشحالم که اینجا در جشنواره pi data آمستردام هستم
7
00:00:21,600 –> 00:00:22,800
8
00:00:22,800 –> 00:00:25,279
ما واقعاً میخواستیم امسال یک پی دیتای حضوری در
9
00:00:25,279 –> 00:00:26,720
آمستردام برگزار
10
00:00:26,720 –> 00:00:28,800
کنیم، متأسفانه نتوانستیم به
11
00:00:28,800 –> 00:00:30,080
شرایط فعلی برویم،
12
00:00:30,080 –> 00:00:31,760
اما بسیار خوشحالم که
13
00:00:31,760 –> 00:00:33,200
ماتایا با تلاش سخت ماتیاس و مائوریسیو
14
00:00:33,200 –> 00:00:34,640
توانستند این رویداد را انجام دهند
15
00:00:34,640 –> 00:00:36,960
و به همین ترتیب. من فکر می کنم حتی اگر آنها نمی توانند
16
00:00:36,960 –> 00:00:38,320
صدای شما را بشنوند، امیدوارم
17
00:00:38,320 –> 00:00:40,000
کسانی از شما که در خانه تماشا می کنید و
18
00:00:40,000 –> 00:00:41,680
کمی تشویقشان کنید تا
19
00:00:41,680 –> 00:00:42,960
از آنها برای همه زحماتشان برای قرار دادن
20
00:00:42,960 –> 00:00:45,280
این رویداد در یکی از جنبه های مثبت
21
00:00:45,280 –> 00:00:47,360
آن تشکر کنم. همه
22
00:00:47,360 –> 00:00:49,440
رویدادهای داده pi دادههای آمستردام
23
00:00:49,440 –> 00:00:51,520
شاید طولانیترین رکورد شکستناپذیر
24
00:00:51,520 –> 00:00:52,719
کنفرانسها را داشته باشند و به همین
25
00:00:52,719 –> 00:00:55,120
دلیل در پایان از تمجید خود برخوردار خواهند شد، حالا
26
00:00:55,120 –> 00:00:57,280
امروز میخواهم موضوعی را به شما ارائه کنم
27
00:00:57,280 –> 00:00:58,640
که ممکن است شنیده باشید مردم درباره
28
00:00:58,640 –> 00:01:00,079
29
00:01:00,079 –> 00:01:01,359
بهینهسازی زیادی در پایتون صحبت میکنند. چگونه برای ساخت
30
00:01:01,359 –> 00:01:03,520
سریع کد پایتون این سخنرانی را انجام دادم که
31
00:01:03,520 –> 00:01:04,799
عنوان بسیار خسته کننده ای است
32
00:01:04,799 –> 00:01:07,360
سریع و خشمگین و سریع پایتون 7 فقط
33
00:01:07,360 –> 00:01:09,520
برای تأمل در مورد یک سری فیلم بسیار خسته کننده
34
00:01:09,520 –> 00:01:11,360
که احتمالاً قبلاً دیده
35
00:01:11,360 –> 00:01:13,280
اید احتمالاً در آن خوابیده اید
36
00:01:13,280 –> 00:01:14,799
و مطمئن هستم که تا به حال داشته اید. دقیقاً همین
37
00:01:14,799 –> 00:01:16,880
تجربه در هنگام تماشای گفتگوهای بهینه سازی
38
00:01:16,880 –> 00:01:17,840
39
00:01:17,840 –> 00:01:19,280
در یک لحظه من صفحه نمایش خود را با شما به اشتراک می گذارم
40
00:01:19,280 –> 00:01:20,960
و سپس شروع می کنیم
41
00:01:20,960 –> 00:01:22,400
فقط یک یادداشت این یک بحث است
42
00:01:22,400 –> 00:01:24,240
و یک بحث در سطح مبتدی است و
43
00:01:24,240 –> 00:01:25,680
متأسفانه من چیز زیادی ندارم
44
00:01:25,680 –> 00:01:27,360
مطالب کارگاهی را که اکنون برای شما ارائه خواهم کرد،
45
00:01:27,360 –> 00:01:29,119
می توانید صفحه نمایش من را در یک لحظه پشت سرم ببینید، من
46
00:01:29,119 –> 00:01:30,640
47
00:01:30,640 –> 00:01:32,159
در گوشه ای از صفحه پنهان می
48
00:01:32,159 –> 00:01:33,600
شوم تا بتوانید همه چیز را ببینید و ما
49
00:01:33,600 –> 00:01:35,119
50
00:01:35,119 –> 00:01:37,119
عنوان این گفتگو را شروع می کنیم پایتون 7 خشمگین و
51
00:01:37,119 –> 00:01:38,560
سریع است.
52
00:01:38,560 –> 00:01:40,960
ما در جشنواره پی دیتا آمستردام هستیم،
53
00:01:40,960 –> 00:01:41,680
پنجشنبه
54
00:01:41,680 –> 00:01:44,320
17 ژوئن 2020 است. خوشحالم که اکنون
55
00:01:44,320 –> 00:01:45,920
اینجا هستم و این مطالب را به همه
56
00:01:45,920 –> 00:01:46,640
شما ارائه
57
00:01:46,640 –> 00:01:49,200
می کنم، توجه داشته باشم که برای من در نیویورک ساعت 3 صبح است
58
00:01:49,200 –> 00:01:50,799
و بنابراین
59
00:01:50,799 –> 00:01:53,200
من اگر بخواهم واقعاً باید از آمدن به صحبت
60
00:01:53,200 –> 00:01:54,560
با همه شما لذت ببرم می خواهم تا دیروقت بیدار بمانم
61
00:01:54,560 –> 00:01:55,520
62
00:01:55,520 –> 00:01:58,240
تا برای شما ارائه کنم، من جیمز پاول هستم، اگر
63
00:01:58,240 –> 00:02:00,000
این سخنرانی را دوست دارید یا به
64
00:02:00,000 –> 00:02:01,600
مطالب مشابه علاقه دارید، می توانید من را
65
00:02:01,600 –> 00:02:03,680
در توییتر دنبال کنید، از این کد استفاده نکنید،
66
00:02:03,680 –> 00:02:05,439
من چندین سخنرانی در پی های مختلف انجام می دهم
67
00:02:05,439 –> 00:02:07,439
رویدادهای داده متأسفانه امسال
68
00:02:07,439 –> 00:02:08,000
ما به همان اندازه
69
00:02:08,000 –> 00:02:09,199
رویدادهای داده پی نداریم، اما به
70
00:02:09,199 –> 00:02:11,280
احتمال زیاد در
71
00:02:11,280 –> 00:02:13,360
رویداد دیگری که ماتیاس
72
00:02:13,360 –> 00:02:15,440
در اواخر امسال در آن شرکت دارد، دوباره صحبت خواهم کرد،
73
00:02:15,440 –> 00:02:17,599
همانطور که گفتم این یک بحث است نه یک کارگاه
74
00:02:17,599 –> 00:02:19,200
و در سطح مبتدی، بنابراین امیدوارم این
75
00:02:19,200 –> 00:02:20,720
صحبت به شما یک چارچوب جدید یا
76
00:02:20,720 –> 00:02:22,239
روش جدیدی برای فکر کردن درباره چیزها
77
00:02:22,239 –> 00:02:23,680
بدهد، اما ممکن است چیزی به شما نگوید که
78
00:02:23,680 –> 00:02:25,200
قبلاً ندیده اید، فقط برای
79
00:02:25,200 –> 00:02:26,239
اینکه شما را برای
80
00:02:26,239 –> 00:02:28,160
چیزی که اکنون می خواهید ببینید آماده کند.
81
00:02:28,160 –> 00:02:29,760
وقتی در مورد پایتون صحبت می کنیم
82
00:02:29,760 –> 00:02:31,040
همه می خواهند
83
00:02:31,040 –> 00:02:32,959
کد پایتون سریع بنویسند، به نظر می رسد
84
00:02:32,959 –> 00:02:34,319
واضح است که این چیزی است که شما می
85
00:02:34,319 –> 00:02:35,120
خواهید انجام
86
00:02:35,120 –> 00:02:37,280
دهید و ممکن است یک بار از خود بپرسید
87
00:02:37,280 –> 00:02:38,560
که
88
00:02:38,560 –> 00:02:40,480
چرا ما به نوشتن
89
00:02:40,480 –> 00:02:42,480
کد سریع پایتون اهمیت می دهیم؟
90
00:02:42,480 –> 00:02:44,319
من حدس می زنم مقیاس پذیر است به نوعی منطقی است زیرا
91
00:02:44,319 –> 00:02:45,920
می توانیم بگوییم که اگر در یک
92
00:02:45,920 –> 00:02:46,959
93
00:02:46,959 –> 00:02:48,480
زمینه تجاری هستیم، همیشه این فشار رقابتی
94
00:02:48,480 –> 00:02:50,239
این فشار سرمایه داری برای رشد وجود دارد
95
00:02:50,239 –> 00:02:51,840
و اگر کد ما مقیاس پذیر نباشد،
96
00:02:51,840 –> 00:02:54,080
نمی تواند رشد کند و بنابراین کسب و کار ما مقداری را پیدا می کند.
97
00:02:54,080 –> 00:02:57,120
مدل کسبوکار که میتواند
98
00:02:57,120 –> 00:02:58,560
از طریق آن پول به دست بیاورد، سعی میکند آن را مقیاسبندی کند
99
00:02:58,560 –> 00:03:00,080
که این ماهیت یک کسبوکار است
100
00:03:00,080 –> 00:03:01,920
و بنابراین مقیاسپذیری بسیار نزدیک
101
00:03:01,920 –> 00:03:03,280
به آن مدل است،
102
00:03:03,280 –> 00:03:04,720
اما نمیدانم که آیا آنقدر قانعکننده است یا نه،
103
00:03:04,720 –> 00:03:06,640
زیرا میتوانید ببینید که خودتان را میدانید.
104
00:03:06,640 –> 00:03:07,760
ممکن است کد
105
00:03:07,760 –> 00:03:09,120
عاملی نباشد که واقعاً در
106
00:03:09,120 –> 00:03:11,120
مقیاس پذیری برخی از سیستم ها مهم باشد،
107
00:03:11,120 –> 00:03:12,400
شما می توانید به خوبی بگویید زیرا
108
00:03:12,400 –> 00:03:13,920
عملکرد آن است و من می گویم این
109
00:03:13,920 –> 00:03:15,599
احتمالاً یک دلیل بسیار بد است زیرا
110
00:03:15,599 –> 00:03:17,200
این کلمه عملکرد فقط یک
111
00:03:17,200 –> 00:03:18,560
کلمه وحشتناک است لطفاً هرگز استفاده نکنید. این
112
00:03:18,560 –> 00:03:19,599
احتمالاً بدترین کلمه ای است که احتمالاً می توانید به
113
00:03:19,599 –> 00:03:21,200
آن برسید.
114
00:03:21,200 –> 00:03:23,519
چه معنایی دارد که می توانید بگویید
115
00:03:23,519 –> 00:03:25,040
شاید یکی از دلایلی که مردم
116
00:03:25,040 –> 00:03:26,560
واقعاً دوست دارند کد خود را سریع بسازند این است
117
00:03:26,560 –> 00:03:27,680
که
118
00:03:27,680 –> 00:03:29,200
اگر بگویم اوه من مقداری کد نوشتم قابل اندازه گیری است.
119
00:03:29,200 –> 00:03:30,640
خواندن آن واقعاً آسان است، واقعاً
120
00:03:30,640 –> 00:03:31,280
قابل اندازهگیری
121
00:03:31,280 –> 00:03:32,959
نیست، به نظر عینی نمیرسد، اما اگر بگویم آه،
122
00:03:32,959 –> 00:03:34,319
کد من در سه اجرا میشود
123
00:03:34,319 –> 00:03:36,319
و کد شما در پنج به خوبی اجرا میشود،
124
00:03:36,319 –> 00:03:37,840
قطعاً قابل اندازهگیری است، بنابراین فکر میکنم تا
125
00:03:37,840 –> 00:03:39,120
حد زیادی وقتی مردم در مورد
126
00:03:39,120 –> 00:03:40,560
نوشتن کد سریع صحبت میکنند، معمولا فقط
127
00:03:40,560 –> 00:03:42,319
به این دلیل که این یک چیز قابل اندازه گیری
128
00:03:42,319 –> 00:03:44,560
است که آنها می توانند روی کد خود انجام دهند و
129
00:03:44,560 –> 00:03:46,640
اغلب اوقات فاکتورهای مهمتر دیگری
130
00:03:46,640 –> 00:03:48,879
از
131
00:03:48,879 –> 00:03:50,000
نظر خوانایی کد نادیده گرفته می شود،
132
00:03:50,000 –> 00:03:51,760
توسعه پذیری کد در یک لحظه
133
00:03:51,760 –> 00:03:53,120
ما در مورد یک
134
00:03:53,120 –> 00:03:54,720
مشکل واضح صحبت خواهیم کرد. در مورد
135
00:03:54,720 –> 00:03:56,319
کد و سرعت کد
136
00:03:56,319 –> 00:03:58,159
و ما خواهیم دید که چگونه می دانید فقط به دلیل اینکه
137
00:03:58,159 –> 00:03:59,519
این یک واحد قابل اندازه گیری است
138
00:03:59,519 –> 00:04:01,120
که یک عکس فوری را به موقع اندازه گیری
139
00:04:01,120 –> 00:04:02,560
می کند، لزوماً به این معنی نیست که آن را
140
00:04:02,560 –> 00:04:03,599
معیار بسیار خوبی برای
141
00:04:03,599 –> 00:04:05,840
کیفیت کلی پایه کد شما می کند.
142
00:04:05,840 –> 00:04:07,120
اکنون متأسفانه
143
00:04:07,120 –> 00:04:08,879
صرف نظر از دلیلی که ممکن است
144
00:04:08,879 –> 00:04:11,040
بخواهید کد خود را سریع بسازید،
145
00:04:11,040 –> 00:04:13,200
پایتون کند است و به ما می گویند پایتون
146
00:04:13,200 –> 00:04:14,239
کند است و جایی
147
00:04:14,239 –> 00:04:16,160
که می دانید وقتی
148
00:04:16,160 –> 00:04:17,600
برای اولین بار پایتون را یاد می گیریم بسیار هیجان زده می شویم و سپس متوجه می شویم.
149
00:04:17,600 –> 00:04:19,358
اوه، این خیلی کند است، بسیار کندتر
150
00:04:19,358 –> 00:04:21,279
از همه ابزارهای دیگری است که من استفاده می کنم،
151
00:04:21,279 –> 00:04:24,880
اما به نظر می رسد هر چیزی که به طور جدی شبیه به
152
00:04:24,880 –> 00:04:26,800
آن است، فقط به نظر می رسد
153
00:04:26,800 –> 00:04:28,080
شکایت از سرعت پایتون
154
00:04:28,080 –> 00:04:29,520
اغلب چیزی است که
155
00:04:29,520 –> 00:04:31,040
شکایت از آن بسیار آسان است. مانند
156
00:04:31,040 –> 00:04:32,320
افرادی که دوست دارند در مورد قفل مترجم جهانی شکایت
157
00:04:32,320 –> 00:04:33,199
158
00:04:33,199 –> 00:04:34,639
کنند، به نظر می رسد که بیشتر از هر شکایت اساسی بسیار جدی، صاعقه ای برای شکایت به نظر می رسد
159
00:04:34,639 –> 00:04:36,320
160
00:04:36,320 –> 00:04:37,199
161
00:04:37,199 –> 00:04:38,400
و دلیلی که می
162
00:04:38,400 –> 00:04:40,000
توانم بگویم این است که اگر به برخی از
163
00:04:40,000 –> 00:04:41,360
سیستم های با عملکرد بسیار بالا
164
00:04:41,360 –> 00:04:43,680
مانند gpt2 نگاه کنید، آنها نوشته شده با استفاده از
165
00:04:43,680 –> 00:04:44,639
تنسورفلو یا پی
166
00:04:44,639 –> 00:04:46,320
مشعل آنها با استفاده از پیوندهای پایتون نوشته شده اند
167
00:04:46,320 –> 00:04:47,840
و بنابراین می توانید چیزهایی را ببینید
168
00:04:47,840 –> 00:04:49,440
که بسیار حساس به عملکرد هستند
169
00:04:49,440 –> 00:04:51,199
هنوز هم برخی از عناصر پایتون در
170
00:04:51,199 –> 00:04:53,199
آنها وجود دارد و بنابراین این ایده که پایتون
171
00:04:53,199 –> 00:04:54,800
کند است و این پایان داستان است
172
00:04:54,800 –> 00:04:56,000
و شما باید فقط برو و از چیزی استفاده کن
173
00:04:56,000 –> 00:04:57,680
که سریعتر است، به نظر میرسد
174
00:04:57,680 –> 00:04:59,520
چیزی بسیار مهم را از دست میدهد،
175
00:04:59,520 –> 00:05:01,360
اکنون یک سوال مهم وقتی در
176
00:05:01,360 –> 00:05:03,759
مورد کد سریع صحبت میکنیم این است که آیا واقعاً میخواهی
177
00:05:03,759 –> 00:05:05,280
سریع co بنویسی؟ آیا میخواهید به
178
00:05:05,280 –> 00:05:07,280
اندازه کافی سریع کد بنویسید، فکر میکنم اغلب اوقات وقتی
179
00:05:07,280 –> 00:05:08,880
افراد سعی میکنند عملکردی را هدف قرار دهند
180
00:05:08,880 –> 00:05:10,320
که واقعاً میخواهند این است که کدی را میخواهند
181
00:05:10,320 –> 00:05:11,919
که به اندازه کافی سریع باشد تا کار خاصی را
182
00:05:11,919 –> 00:05:12,320
انجام
183
00:05:12,320 –> 00:05:14,400
دهد، یک خرس پنهان وجود دارد، یک نوار مخفی وجود دارد
184
00:05:14,400 –> 00:05:16,479
که در حال تلاش هستند. ضربه زدن
185
00:05:16,479 –> 00:05:18,400
و عبور از آن نوار، واقعاً
186
00:05:18,400 –> 00:05:20,000
برای آنها معنی دار نیست که بیشتر از این پیش بروند
187
00:05:20,000 –> 00:05:20,960
و خواهید دید که وقتی ما
188
00:05:20,960 –> 00:05:21,600
در مورد
189
00:05:21,600 –> 00:05:23,280
مکانیسم های معمولی صحبت می کنیم که فرآیندهای معمولی ما
190
00:05:23,280 –> 00:05:24,720
توسط آن
191
00:05:24,720 –> 00:05:27,840
افراد بهینه سازی را انجام می دهند، اکنون یکی از مشکلاتی است
192
00:05:27,840 –> 00:05:29,440
که وقتی افراد داریم صحبت در مورد
193
00:05:29,440 –> 00:05:30,880
بهینه سازی این است که آنها در مورد آن به عنوان یک
194
00:05:30,880 –> 00:05:31,919
فرآیند ایستا صحبت می کنند،
195
00:05:31,919 –> 00:05:33,520
اما در واقع وقتی در مورد
196
00:05:33,520 –> 00:05:35,440
بهینه سازی کد دنیای واقعی صحبت می
197
00:05:35,440 –> 00:05:37,360
کنید، این واقعا یک فرآیند پویا است و در اینجا
198
00:05:37,360 –> 00:05:38,960
می توانید ببینید که ما کمی سخت به دوگانگی پویا استاتیک خود متمایل شده ایم.
199
00:05:38,960 –> 00:05:40,880
200
00:05:40,880 –> 00:05:41,520
201
00:05:41,520 –> 00:05:43,199
فقط برای تفکیک این اصطلاحات برای
202
00:05:43,199 –> 00:05:44,320
شما، ممکن است فکر کنید که اگر ما در
203
00:05:44,320 –> 00:05:45,759
مورد یک فرآیند استاتیک صحبت می کنیم،
204
00:05:45,759 –> 00:05:47,759
در مورد بررسی یک
205
00:05:47,759 –> 00:05:49,280
قطعه کد معین در یک زمان ثابت صحبت می
206
00:05:49,280 –> 00:05:50,479
کنیم و سعی می کنیم آن را تبدیل به یک فرآیند ثابت کنیم. aster پس
207
00:05:50,479 –> 00:05:52,240
ما داریم می گوییم کد همانطور که امروز وجود دارد،
208
00:05:52,240 –> 00:05:53,440
بیایید ببینیم آیا می توانیم روی آن تکرار کنیم و
209
00:05:53,440 –> 00:05:54,320
آن را سریعتر کنیم،
210
00:05:54,320 –> 00:05:56,400
در حالی که واقعیت مبانی کد این است
211
00:05:56,400 –> 00:05:57,919
که آنها بخشی از یک فرآیند پویا
212
00:05:57,919 –> 00:05:59,280
در واقعیت هستند که ما نمی خواهیم آن را بسازیم.
213
00:05:59,280 –> 00:06:00,479
امروز
214
00:06:00,479 –> 00:06:02,160
میخواهیم کدی
215
00:06:02,160 –> 00:06:04,000
را سریعتر بگیریم و در طول زمان آن را سریعتر کنیم،
216
00:06:04,000 –> 00:06:06,400
اگر کد ما امروز سریعتر باشد و سپس
217
00:06:06,400 –> 00:06:08,160
به کندترین کد فردا تبدیل شود
218
00:06:08,160 –> 00:06:10,080
که به معنای مشابه برای ما مطلوب
219
00:06:10,080 –> 00:06:11,520
نیست، اغلب وقتی در
220
00:06:11,520 –> 00:06:13,759
مورد مشکلات طراحی صحبت میکنیم یا در
221
00:06:13,759 –> 00:06:15,600
مورد ویژگی های
222
00:06:15,600 –> 00:06:16,880
پایه های کد صحبت می کنیم، اغلب در مورد
223
00:06:16,880 –> 00:06:18,240
آنها در یک نمای فوری صحبت می کنیم، در
224
00:06:18,240 –> 00:06:19,280
مورد آنها به صورت ایستا صحبت می
225
00:06:19,280 –> 00:06:21,440
کنیم، می گوییم اگر این
226
00:06:21,440 –> 00:06:23,199
مشکل ثابت را در مکان و زمان در نظر
227
00:06:23,199 –> 00:06:24,639
بگیریم و سعی کنیم بهترین ها را کشف کنیم.
228
00:06:24,639 –> 00:06:26,080
بهترین راه برای مدلسازی بهترین راه برای
229
00:06:26,080 –> 00:06:27,600
مدلسازی آن است، اما در واقع یک
230
00:06:27,600 –> 00:06:29,120
پایگاه کد واقعی بخشی از یک
231
00:06:29,120 –> 00:06:30,639
فرآیند پویا است، بخشی از
232
00:06:30,639 –> 00:06:31,759
فرآیند توسعه نرمافزار است
233
00:06:31,759 –> 00:06:33,120
و فرآیند توسعه نرمافزار
234
00:06:33,120 –> 00:06:35,039
اساساً پویا است، به عبارت دیگر به
235
00:06:35,039 –> 00:06:36,639
شما یک نیاز داده میشود. اصلاح در روز اول
236
00:06:36,639 –> 00:06:37,919
و به شما الزامات زیادی در
237
00:06:37,919 –> 00:06:39,759
روز دو روز سه سه ماه بعد شش
238
00:06:39,759 –> 00:06:41,360
ماه بعد یک سال بعد داده می شود،
239
00:06:41,360 –> 00:06:44,319
به طور مشابه کد سابق شما با مجموعه ای کوچکتر از موارد شروع می شود
240
00:06:44,319 –> 00:06:44,960
241
00:06:44,960 –> 00:06:46,720
که باید سه
242
00:06:46,720 –> 00:06:48,000
ماه بعد شش ماه بعد یک سال
243
00:06:48,000 –> 00:06:48,560
بعد حل کند.
244
00:06:48,560 –> 00:06:50,319
تعداد مواردی که باید
245
00:06:50,319 –> 00:06:51,840
اندازه مجموعه داده هایی را که باید
246
00:06:51,840 –> 00:06:53,039
پردازش کند بسیار متفاوت است و
247
00:06:53,039 –> 00:06:54,240
پویایی آن ها
248
00:06:54,240 –> 00:06:56,240
ممکن است به طور قابل توجهی متفاوت باشد به عنوان
249
00:06:56,240 –> 00:06:57,759
نتیجه کارهایی که ممکن است در
250
00:06:57,759 –> 00:06:58,400
روز اول انجام دهید
251
00:06:58,400 –> 00:07:00,240
تا به نوشتن آنچه فکر می کنید منجر شود.
252
00:07:00,240 –> 00:07:02,080
سریعترین کد ممکن است
253
00:07:02,080 –> 00:07:06,160
تا روز 365 یا
254
00:07:06,160 –> 00:07:08,560
سال اول سال 10 این پایه کد باقی نماند،
255
00:07:08,560 –> 00:07:09,440
256
00:07:09,440 –> 00:07:11,039
اکنون مهم است که
257
00:07:11,039 –> 00:07:13,120
این ایده بهینهسازی را
258
00:07:13,120 –> 00:07:14,319
در شرایط فرآیند توسعه نرمافزار در نظر
259
00:07:14,319 –> 00:07:15,520
بگیریم و واقعاً باید فکر
260
00:07:15,520 –> 00:07:18,080
کنیم که نرمافزار در واقع چگونه نوشته شده است.
261
00:07:18,080 –> 00:07:19,440
آنچه که ما واقعاً باید انجام دهیم
262
00:07:19,440 –> 00:07:21,280
تا به این موضوع بهتر بپردازیم این
263
00:07:21,280 –> 00:07:22,880
است که یک چارچوب بهتر ارائه دهیم، یک راه بهتر
264
00:07:22,880 –> 00:07:23,759
برای در نظر گرفتن
265
00:07:23,759 –> 00:07:25,919
معنای بهینه سازی کد چه
266
00:07:25,919 –> 00:07:27,280
معنایی برای سریع بودن کد
267
00:07:27,280 –> 00:07:28,479
و غیره آنچه در این گفتگو برای شما آماده کرده ام
268
00:07:28,479 –> 00:07:31,120
چارچوبی است
269
00:07:31,120 –> 00:07:33,840
که ممکن است به شما کمک کند سعی کنید کمی
270
00:07:33,840 –> 00:07:35,039
271
00:07:35,039 –> 00:07:36,639
در پس این بحث های بهینه سازی
272
00:07:36,639 –> 00:07:37,840
و بحث در مورد چگونگی
273
00:07:37,840 –> 00:07:39,120
ساخت سریع یک کد قرار دهید
274
00:07:39,120 –> 00:07:44,240
و من این چارچوب را m-i-s-s
275
00:07:44,240 –> 00:07:46,479
یک چارچوب می نامم. m مخفف اندازه
276
00:07:46,479 –> 00:07:48,160
گیری، i مخفف
277
00:07:48,160 –> 00:07:50,560
شهود، s مخفف ساختار، other s
278
00:07:50,560 –> 00:07:51,919
مخفف تخصص
279
00:07:51,919 –> 00:07:54,240
و a مخفف و در واقع
280
00:07:54,240 –> 00:07:55,039
281
00:07:55,039 –> 00:07:56,800
s دوم تا آخر در واقع مخفف
282
00:07:56,800 –> 00:07:58,080
stupid است زیرا این یک
283
00:07:58,080 –> 00:08:00,800
مخفف بسیار احمقانه است و در واقع این است. حتی
284
00:08:00,800 –> 00:08:02,400
یک مخفف نیست، این یک مقدار اولیه است،
285
00:08:02,400 –> 00:08:04,639
بنابراین واقعاً این چارچوب m-i-s-s-i
286
00:08:04,639 –> 00:08:06,800
است، اکنون اجازه دهید با
287
00:08:06,800 –> 00:08:08,000
حرف اول این
288
00:08:08,000 –> 00:08:10,639
اندازه گیری چارچوب شروع کنیم، بدیهی است
289
00:08:10,639 –> 00:08:12,479
که اگر بخواهیم کد خود را سریع کنیم،
290
00:08:12,479 –> 00:08:14,080
باید مقداری اندازه گیری را
291
00:08:14,080 –> 00:08:15,759
انجام دهیم، مقدار محدودی داریم. از زمان و در
292
00:08:15,759 –> 00:08:17,039
آن زمان محدود، باید تصمیم بگیریم که آن زمان را در
293
00:08:17,039 –> 00:08:17,520
294
00:08:17,520 –> 00:08:19,120
کجا صرف کنیم
295
00:08:19,120 –> 00:08:20,879
تا برخی از کدهای پایه کد خود را تغییر دهیم
296
00:08:20,879 –> 00:08:22,720
و بنابراین برای ما منطقی نیست که
297
00:08:22,720 –> 00:08:24,800
سعی کنید تک تک خطوط کد را بهینه سازی
298
00:08:24,800 –> 00:08:25,440
299
00:08:25,440 –> 00:08:27,360
کنید. منطقی است که ما اندازه گیری کنیم تا از
300
00:08:27,360 –> 00:08:28,960
آن اندازه گیری ها برای هدایت خود استفاده کنیم،
301
00:08:28,960 –> 00:08:29,759
اما این
302
00:08:29,759 –> 00:08:31,680
واقعاً به خود کد
303
00:08:31,680 –> 00:08:33,440
مربوط نمی
304
00:08:33,440 –> 00:08:35,039
شود، به عبارت دیگر به پویایی ما در فرآیند توسعه نرم افزار
305
00:08:35,039 –> 00:08:36,559
مربوط می شود.
306
00:08:36,559 –> 00:08:37,919
زمان محدود و منابع محدود
307
00:08:37,919 –> 00:08:39,519
و چگونه می توانیم به بهترین نحو از این منابع محدود بهره برداری کنیم
308
00:08:39,519 –> 00:08:40,958
زیرا
309
00:08:40,958 –> 00:08:42,799
اگر شما منابع محدودی
310
00:08:42,799 –> 00:08:43,839
نداشتید اگر تعداد بی نهایت
311
00:08:43,839 –> 00:08:45,200
برنامه نویس بر روی پایه کد شما کار می
312
00:08:45,200 –> 00:08:46,399
کردند واقعاً هیچ ارزشی برای
313
00:08:46,399 –> 00:08:47,760
اندازه گیری وجود نداشت فقط سعی می کردید
314
00:08:47,760 –> 00:08:48,320
بهینه سازی
315
00:08:48,320 –> 00:08:51,440
تک تک جنبه های آن کد اکنون
316
00:08:51,440 –> 00:08:53,360
ممکن است یک فرآیند سه مرحله ای را
317
00:08:53,360 –> 00:08:55,040
برای یک فرآیند توسعه نرم افزار شنیده باشید که
318
00:08:55,040 –> 00:08:57,120
این ایده بهینه سازی را
319
00:08:57,120 –> 00:08:58,560
نزدیک به پایان قرار می دهد، ممکن است شنیده باشید که مردم
320
00:08:58,560 –> 00:09:00,240
چیزهایی می گویند مانند درست کردن کار
321
00:09:00,240 –> 00:09:02,240
کردن آن را به سرعت در سایر موارد
322
00:09:02,240 –> 00:09:04,080
کلمات ابتدا کد را عملاً کار
323
00:09:04,080 –> 00:09:05,279
می کنند و آن را از منظر تجاری کاری انجام می دهند
324
00:09:05,279 –> 00:09:06,959
، این
325
00:09:06,959 –> 00:09:08,560
ایده خوبی است، می دانید اگر کد اصلا
326
00:09:08,560 –> 00:09:09,440
کار نمی کند،
327
00:09:09,440 –> 00:09:11,040
پس اینطور نیست
328
00:09:11,040 –> 00:09:12,800
329
00:09:12,800 –> 00:09:14,959
اگر کد درست نیست، سریع بودن آن واقعا ارزشمند
330
00:09:14,959 –> 00:09:16,640
است، ممکن است سریع بودن آن نیز ارزشمند نباشد
331
00:09:16,640 –> 00:09:18,560
، بنابراین ابتدا کد را کار
332
00:09:18,560 –> 00:09:19,920
میکنید، سپس مطمئن میشوید که کد صحیح است
333
00:09:19,920 –> 00:09:21,279
، مطمئن میشوید که کد نتایج درستی به شما میدهد
334
00:09:21,279 –> 00:09:22,720
و سپس شما بهینهسازیها را انجام میدهید،
335
00:09:22,720 –> 00:09:23,839
336
00:09:23,839 –> 00:09:25,279
این چارچوبی است که ممکن
337
00:09:25,279 –> 00:09:27,040
است با اشاره به نظرات درباره
338
00:09:27,040 –> 00:09:28,959
بهینهسازی از افرادی مانند dijkstra dijkstra دیده باشید که در مورد بهینهسازی مثل یک
339
00:09:28,959 –> 00:09:31,360
عمل بسیار ضعیف بود،
340
00:09:31,360 –> 00:09:32,240
341
00:09:32,240 –> 00:09:34,160
زیرا او
342
00:09:34,160 –> 00:09:36,560
گفت اگر کد صحیح نیست ببینید
343
00:09:36,560 –> 00:09:38,720
چه کسی اهمیت میدهد که سرعت آن چقدر است. در حال حاضر مانند یک
344
00:09:38,720 –> 00:09:40,160
فرآیند تجاری که
345
00:09:40,160 –> 00:09:41,519
همیشه در مورد نحوه
346
00:09:41,519 –> 00:09:44,160
برخورد یا نگاه کردن به کدمان صادق نیست، در عوض
347
00:09:44,160 –> 00:09:45,360
اگر واقعاً به کاری که انجام میدهیم فکر میکنیم،
348
00:09:45,360 –> 00:09:46,399
اغلب اوقات
349
00:09:46,399 –> 00:09:48,320
آن را به نوعی کار میکنیم و سپس
350
00:09:48,320 –> 00:09:50,640
آن را سریع انجام میدهیم و سپس به نوعی بررسی
351
00:09:50,640 –> 00:09:51,600
کنید که آیا درست است
352
00:09:51,600 –> 00:09:53,120
و ما هیچ یک از این فرآیندها را به درستی انجام نمیدهیم،
353
00:09:53,120 –> 00:09:55,120
بنابراین فکر میکنم چارچوب سه مرحلهای
354
00:09:55,120 –> 00:09:56,480
355
00:09:56,480 –> 00:09:58,000
برخی از واقعیتها را نادیده میگیرد که چگونه ما برای نوشتن
356
00:09:58,000 –> 00:10:00,240
کد
357
00:10:00,240 –> 00:10:01,519
پیش میرویم در عوض آنچه ممکن است انجام دهیم ht با
358
00:10:01,519 –> 00:10:02,959
برخی از اندازهگیریها شروع کنید و
359
00:10:02,959 –> 00:10:04,880
ابزارهای اندازهگیری بسیاری وجود دارد که ممکن است از آنها استفاده کنیم،
360
00:10:04,880 –> 00:10:06,640
ممکن است با
361
00:10:06,640 –> 00:10:08,240
ابزارهای اندازهگیری نمونهگیری مانند pi spy آشنا باشید
362
00:10:08,240 –> 00:10:09,680
، یکی از ابزارهای بسیار محبوب که من دیدهام
363
00:10:09,680 –> 00:10:11,839
که به نمونههای بسیار جالبی
364
00:10:11,839 –> 00:10:15,040
از بهینهسازی منجر شده است.
365
00:10:15,040 –> 00:10:16,240
ابزارهایی که ممکن است بهینهسازیهای کوچک انجام
366
00:10:16,240 –> 00:10:17,920
دهیم، تعدادی کد را اندازهگیری میکنیم،
367
00:10:17,920 –> 00:10:19,839
برخی از خطوط نقطه داغ را شناسایی میکنیم، وارد
368
00:10:19,839 –> 00:10:21,120
آن خطوط نقطه داغ میشویم، بهینهسازیهای کوچک انجام
369
00:10:21,120 –> 00:10:22,720
میدهیم، آن خطوط
370
00:10:22,720 –> 00:10:24,560
یا برخی از زیرمجموعههای آن خطوط را بازنویسی میکنیم و
371
00:10:24,560 –> 00:10:26,160
آنها را بهبود میدهیم، اما این فرآیند یک مشکل دارد
372
00:10:26,160 –> 00:10:26,880
373
00:10:26,880 –> 00:10:28,320
و بسیار مشکل مهمی است زیرا
374
00:10:28,320 –> 00:10:29,600
وقتی این کار را انجام میدهیم، به این
375
00:10:29,600 –> 00:10:31,040
کد به عنوان یک موجودیت ثابت نگاه میکنیم،
376
00:10:31,040 –> 00:10:32,560
به عنوان یک موجودیت پویا
377
00:10:32,560 –> 00:10:33,120
378
00:10:33,120 –> 00:10:35,760
نگاه نمیکنیم، اجازه دهید یک مثال اساسی برای شما بیاورم وقتی به
379
00:10:35,760 –> 00:10:37,360
یک پایه کد نگاه میکنیم که پایگاه کد تابع
380
00:10:37,360 –> 00:10:39,120
یک محیط اجرایی است. که
381
00:10:39,120 –> 00:10:40,880
محیط اجرا ممکن است در طول زمان تغییر کند،
382
00:10:40,880 –> 00:10:42,480
من یک مثال متعارف برای شما میآورم، من
383
00:10:42,480 –> 00:10:44,079
خودم نرمافزاری ندارم و
384
00:10:44,079 –> 00:10:46,000
پیشزمینهای در زمینه علوم کامپیوتر ندارم، من یک
385
00:10:46,000 –> 00:10:47,440
مهندسی برق دارم پس زمینه ineering
386
00:10:47,440 –> 00:10:48,640
و من شروع به نوشتن کد روی
387
00:10:48,640 –> 00:10:51,200
میکروکنترلرها کردم و در میکروکنترلرها
388
00:10:51,200 –> 00:10:52,480
جنبه اساسی خاصی وجود دارد
389
00:10:52,480 –> 00:10:53,440
390
00:10:53,440 –> 00:10:55,519
که به انواع کامپیوترهایی که من
391
00:10:55,519 –> 00:10:56,560
برای آنها نرم افزار می نویسم منتقل نمی شود به
392
00:10:56,560 –> 00:10:58,160
عبارت دیگر در
393
00:10:58,160 –> 00:11:00,320
میکروکنترلرها یک دوگانگی حافظه در مقابل cpu وجود داشت
394
00:11:00,320 –> 00:11:02,079
و هر بار که کدها به نوعی آهسته بود
395
00:11:02,079 –> 00:11:04,000
ما به حافظه خود تکیه دادیم و جداول جستجو را می نویسیم
396
00:11:04,000 –> 00:11:04,640
397
00:11:04,640 –> 00:11:06,160
اما این روش دیگر
398
00:11:06,160 –> 00:11:07,920
کار نمی کند و برای
399
00:11:07,920 –> 00:11:09,519
رایانه های کوچک استاندارد ما برای رایانه های رومیزی ما کار نمی کند
400
00:11:09,519 –> 00:11:10,560
و برای سرورهای
401
00:11:10,560 –> 00:11:12,640
ما اکنون به سمت Cpu که می گوییم شما کار می کند کار نمی کند.
402
00:11:12,640 –> 00:11:14,000
بدانید زمان دسترسی به حافظه
403
00:11:14,000 –> 00:11:16,079
آنقدر آهسته است که گاهی اوقات
404
00:11:16,079 –> 00:11:18,000
بهتر است محاسبات اضافی را با cpu انجام دهید
405
00:11:18,000 –> 00:11:20,160
تا هزینه جدول جستجو را بپردازید، زیرا
406
00:11:20,160 –> 00:11:21,600
407
00:11:21,600 –> 00:11:23,839
کندی دسترسی به هر چیزی که از
408
00:11:23,839 –> 00:11:25,600
حافظه نهان l1 گذشته است ارزش وقت گذاشتن را ندارد و بنابراین
409
00:11:25,600 –> 00:11:27,360
می توانید تغییرات دینامیکی اساسی را مشاهده کنید.
410
00:11:27,360 –> 00:11:28,000
411
00:11:28,000 –> 00:11:31,120
نتیجه این خواهد بود که من در سال 1992
412
00:11:31,120 –> 00:11:32,480
کدی بنویسم و سعی کنم آن را سر
413
00:11:32,480 –> 00:11:33,519
عترین در جهان کنم و از جدول جستجو استفاده کن
414
00:11:33,519 –> 00:11:34,640
415
00:11:34,640 –> 00:11:37,680
416
00:11:37,680 –> 00:11:38,959
. دیگر سریعترین در
417
00:11:38,959 –> 00:11:40,560
جهان نیست زیرا این پویایی بنیادی
418
00:11:40,560 –> 00:11:41,200
419
00:11:41,200 –> 00:11:42,640
اکنون تغییر کرده است که ممکن است یک نقطه بسیار گسترده به نظر
420
00:11:42,640 –> 00:11:43,920
برسد، بنابراین من می خواهم یک مثال ملموس تر به شما ارائه دهم، یک
421
00:11:43,920 –> 00:11:45,040
422
00:11:45,040 –> 00:11:47,279
مثال در دنیای واقعی که ممکن است آن را ببینید
423
00:11:47,279 –> 00:11:49,440
و این است که فکر می کنم فقط یک مثال است
424
00:11:49,440 –> 00:11:52,000
که در کل این کارگاه اسلش بحث مشارکت دارد
425
00:11:52,000 –> 00:11:53,600
426
00:11:53,600 –> 00:11:55,120
که در زیر است، فرض کنید ما
427
00:11:55,120 –> 00:11:57,200
مقداری کد داریم و آن کد یک مجموعه داده ایجاد می کند
428
00:11:57,200 –> 00:11:58,639
و ما تابعی داریم که
429
00:11:58,639 –> 00:11:59,920
روی آن مجموعه داده عمل می کند
430
00:11:59,920 –> 00:12:01,839
و باید آن تابع را برای هر کدام اعمال کنیم.
431
00:12:01,839 –> 00:12:03,519
اکنون عنصر این مجموعه داده را
432
00:12:03,519 –> 00:12:05,440
کنار بگذارید که در عمل
433
00:12:05,440 –> 00:12:06,800
احتمالاً از numpy برای چیزی شبیه به این استفاده می کنید،
434
00:12:06,800 –> 00:12:07,279
435
00:12:07,279 –> 00:12:08,959
اما فرض کنید این کار را در پایتون خالص انجام می
436
00:12:08,959 –> 00:12:10,399
دهیم و چند گزینه
437
00:12:10,399 –> 00:12:11,839
در یک گزینه داریم، ممکن است یک لیست را
438
00:12:11,839 –> 00:12:14,160
درک کنیم و گزینه دیگری
439
00:12:14,160 –> 00:12:14,800
ممکن است داشته باشیم.
440
00:12:14,800 –> 00:12:17,120
از نقشه ساخته شده استفاده کنید و ممکن است آن را به
441
00:12:17,120 –> 00:12:18,800
سازنده مقدار لیست
442
00:12:18,800 –> 00:12:20,560
و گزینه دیگری که ممکن است از
443
00:12:20,560 –> 00:12:22,399
نقشه داخلی استفاده کنیم و ممکن است از این
444
00:12:22,399 –> 00:12:24,240
تعمیم باز کردن بسته بندی برای
445
00:12:24,240 –> 00:12:25,760
ارسال آن برای ساخت استفاده کنیم. لیستی برای
446
00:12:25,760 –> 00:12:26,880
ساختن یک لیست از این
447
00:12:26,880 –> 00:12:28,959
و گزینه دیگر این است که ما فقط
448
00:12:28,959 –> 00:12:30,399
میتوانیم تابع را به طور کامل نادیده بگیریم و فقط آن را درون خطی
449
00:12:30,399 –> 00:12:31,440
کنیم و فقط یک
450
00:12:31,440 –> 00:12:32,800
لیست استاندارد را بدون
451
00:12:32,800 –> 00:12:35,760
هیچ فراخوانی بنویسیم که کدام یک از اینها بهترین
452
00:12:35,760 –> 00:12:37,519
است. این تنها بخش مشارکتی
453
00:12:37,519 –> 00:12:38,800
این است. تنها سوالی که از شما میپرسم،
454
00:12:38,800 –> 00:12:40,320
اما در اینجا چند
455
00:12:40,320 –> 00:12:41,680
نام برای اینها آوردهام و در کانال discord
456
00:12:41,680 –> 00:12:43,440
اگر مایلید سعی کنید با این نقشه ساخته شده، تابع را
457
00:12:43,440 –> 00:12:46,720
از سریعترین به کمسرعت
458
00:12:46,720 –> 00:12:50,000
fc به ترتیب در لیست lm درک مطلب قرار دهید.
459
00:12:50,000 –> 00:12:52,560
در این نقشه با
460
00:12:52,560 –> 00:12:54,000
دستور unpacking
461
00:12:54,000 –> 00:12:56,000
و lc درک لیست مستقیم
462
00:12:56,000 –> 00:12:57,600
به شما حدود
463
00:12:57,600 –> 00:12:59,760
15 ثانیه زمان می دهم و دلیل اینکه من فقط به
464
00:12:59,760 –> 00:13:01,040
شما 15 ثانیه می دهم این است که شما نیازی به
465
00:13:01,040 –> 00:13:02,560
نودل برای مدت طولانی ندارید
466
00:13:02,560 –> 00:13:03,839
و دلیل آن من به طولانیترین زمان نیاز دارم
467
00:13:03,839 –> 00:13:06,320
، نتیجه ممکن است شما را شگفتزده کند،
468
00:13:06,320 –> 00:13:08,240
ممکن است بتوانید سریعترین را به دست آورید، اما
469
00:13:08,240 –> 00:13:09,440
نمیتوانید
470
00:13:09,440 –> 00:13:10,160
خیلی جلوتر بروید،
471
00:13:10,160 –> 00:13:11,839
بیایید نگاهی بیندازیم اکنون
472
00:13:11,839 –> 00:13:13,760
آزمایش کردن این موضوع برای ما به طرز شگفتآوری آسان است
473
00:13:13,760 –> 00:13:15,519
و برای برخی از شما 15 ثانیه ممکن
474
00:13:15,519 –> 00:13:16,800
است زمان کافی برای امتحان کردن
475
00:13:16,800 –> 00:13:17,200
این باشد،
476
00:13:17,200 –> 00:13:18,880
میدانید که داکر هاب دارای نسخههایی از
477
00:13:18,880 –> 00:13:20,800
پایتون از 3.5 تا
478
00:13:20,800 –> 00:13:23,440
3.9 است، میتوانید یک کانتینر داکر
479
00:13:23,440 –> 00:13:24,720
را اجرا کنید، میتوانید این کد را با استفاده از ماژول زمان آن
480
00:13:24,720 –> 00:13:26,160
در کتابخانه استاندارد اجرا
481
00:13:26,160 –> 00:13:28,800
کنید و میتوانید تعدادی حلقه به آن بدهید.
482
00:13:28,800 –> 00:13:29,839
اجرا کنید و در واقع می توانید
483
00:13:29,839 –> 00:13:30,880
کدی مانند این بنویسید و این همان کاری است
484
00:13:30,880 –> 00:13:32,079
که من در آماده سازی برای این
485
00:13:32,079 –> 00:13:34,079
سخنرانی انجام دادم و انجام آن حدود 10 دقیقه طول کشید
486
00:13:34,079 –> 00:13:35,519
و می خواهم قبل از اینکه برخی از نتایج سلب مسئولیت را به شما نشان دهم یک سلب مسئولیت به شما ارائه دهم.
487
00:13:35,519 –> 00:13:36,959
488
00:13:36,959 –> 00:13:38,480
به شرح زیر،
489
00:13:38,480 –> 00:13:39,839
من آنقدر به فایلهای داکر نگاه نکردم،
490
00:13:39,839 –> 00:13:41,680
بنابراین شاید
491
00:13:41,680 –> 00:13:42,959
نسخههای مختلف پایتون
492
00:13:42,959 –> 00:13:44,560
با گزینههای کمی متفاوت ساخته میشوند،
493
00:13:44,560 –> 00:13:46,160
494
00:13:46,160 –> 00:13:47,920
من واقعاً به همه
495
00:13:47,920 –> 00:13:49,760
مواردی که میدانیم جزئیاتی از
496
00:13:49,760 –> 00:13:51,360
اتفاقاتی که هنگام اجرای پایتون در داکر میافتد توجه نکردم.
497
00:13:51,360 –> 00:13:52,800
ممکن است اخیراً اخباری را دیده
498
00:13:52,800 –> 00:13:54,320
باشیم که حالتهای امنیتی خاصی
499
00:13:54,320 –> 00:13:55,519
در داخل کانتینر داکر فعال هستند
500
00:13:55,519 –> 00:13:56,959
که باعث میشوند مفسر پایتون ما
501
00:13:56,959 –> 00:13:58,639
به میزان قابل توجهی کندتر شود
502
00:13:58,639 –> 00:14:00,160
و زمانی که خارج از کانتینر سند است.
503
00:14:00,160 –> 00:14:01,440
همه اینها را کنار بگذاریم زیرا
504
00:14:01,440 –> 00:14:02,880
برای تحلیلی که خواهیم دید واقعاً مهم نیست،
505
00:14:02,880 –> 00:14:03,839
506
00:14:03,839 –> 00:14:05,519
من همچنین می خواهم چند نکته مهم دیگر را فقط برای مرجع شما به شما ارائه دهم
507
00:14:05,519 –> 00:14:07,600
508
00:14:07,600 –> 00:14:09,440
، این را روی سطح حرفه ای
509
00:14:09,440 –> 00:14:12,160
خود اجرا کردم و فرکانس پردازنده را پین کردم و من
510
00:14:12,160 –> 00:14:13,199
از یک فرماندار ایالت اینتل استفاده می
511
00:14:13,199 –> 00:14:15,199
کنم و آن را با برق ac اجرا می کنم
512
00:14:15,199 –> 00:14:17,279
و هیچ چیز دیگری
513
00:14:17,279 –> 00:14:18,399
همزمان در حال اجرا نبود و اینها
514
00:14:18,399 –> 00:14:19,920
اخطارهای معمولی است که در مورد این نوع معیارها می بینیم
515
00:14:19,920 –> 00:14:21,040
516
00:14:21,040 –> 00:14:23,600
و مهمترین اخطار این است که من نمی کنم
517
00:14:23,600 –> 00:14:25,120
مراقب باشید، به طور جدی، ما خواهیم دید
518
00:14:25,120 –> 00:14:26,399
که این معیار مهم نیست و
519
00:14:26,399 –> 00:14:27,600
همه آن هشدارها و همه آن
520
00:14:27,600 –> 00:14:29,040
شرایط اهمیتی ندارد،
521
00:14:29,040 –> 00:14:31,360
اما من یک چیز مهم را به شما می گویم که
522
00:14:31,360 –> 00:14:33,279
در واقع اهمیت می دهم، بسیار اهمیت می دهم
523
00:14:33,279 –> 00:14:34,560
زیرا اگر من این کار را نمی کردم مراقب
524
00:14:34,560 –> 00:14:36,480
باشید که من اینجا نباشم من واقعاً اهمیت می دهم
525
00:14:36,480 –> 00:14:37,519
و واقعاً امیدوارم که از صحبت کردن تا اینجا لذت برده باشید،
526
00:14:37,519 –> 00:14:38,240
527
00:14:38,240 –> 00:14:39,760
بیایید به نتایج آن
528
00:14:39,760 –> 00:14:41,199
529
00:14:41,199 –> 00:14:42,240
530
00:14:42,240 –> 00:14:44,000
نگاهی بیندازیم.
531
00:14:44,000 –> 00:14:46,320
نتایج در پایتون
532
00:14:46,320 –> 00:14:48,480
3.5 لیست c هستند omprehension is سریعترین
533
00:14:48,480 –> 00:14:49,839
گزینه است، درک لیست خالص
534
00:14:49,839 –> 00:14:51,279
در واقع در هر نسخه از
535
00:14:51,279 –> 00:14:52,639
پایتون که آزمایش کردیم،
536
00:14:52,639 –> 00:14:54,079
درک لیست سریعترین است
537
00:14:54,079 –> 00:14:55,360
وقتی به بخش شهود می
538
00:14:55,360 –> 00:14:57,199
رسیم، خواهیم دید که چرا باید کم و بیش
539
00:14:57,199 –> 00:14:59,120
منطقی باشد، اما اگر حذف کنیم
540
00:14:59,120 –> 00:15:00,560
درک از آن و ما به
541
00:15:00,560 –> 00:15:01,760
همه گزینه های دیگر
542
00:15:01,760 –> 00:15:03,440
نگاه می کنیم آنچه می بینیم فراخوانی تابع در
543
00:15:03,440 –> 00:15:05,519
درک به همان سرعتی است که در پایتون 3.5
544
00:15:05,519 –> 00:15:09,199
و سپس در پایتون 3.6 نقشه لیست
545
00:15:09,199 –> 00:15:10,320
سریع ترین است و می توانید ببینید
546
00:15:10,320 –> 00:15:12,079
که به طور قابل توجهی سریعتر است.
547
00:15:12,079 –> 00:15:13,440
تفاوت عملکرد معنیدار در
548
00:15:13,440 –> 00:15:15,040
پایتون 3.5 آنقدرها تفاوت عملکرد معنیدار
549
00:15:15,040 –> 00:15:16,000
550
00:15:16,000 –> 00:15:18,000
نیست، اما در پایتون 3.6 اکنون
551
00:15:18,000 –> 00:15:19,360
تفاوت عملکرد نسبتاً معنیداری است،
552
00:15:19,360 –> 00:15:20,880
553
00:15:20,880 –> 00:15:22,959
در پایتون 3.7 چند درصد است، در پایتون 3.7 یکسان است اما ناگهان
554
00:15:22,959 –> 00:15:24,240
در پایتون 3.8
555
00:15:24,240 –> 00:15:26,480
باز کردن بستهبندی در نقشه سریعترین و سریعترین است
556
00:15:26,480 –> 00:15:28,399
و در پایتون 3.9 ما همین رفتار را می بینیم
557
00:15:28,399 –> 00:15:29,759
اما نویز کافی
558
00:15:29,759 –> 00:15:31,279
وجود ندارد و
559
00:15:31,279 –> 00:15:33,600
در بین پایتون
560
00:15:33,600 –> 00:15:34,880
بین این دو مورد آخر واقعا سیگنال کافی وجود ندارد گزینههای
561
00:15:34,880 –> 00:15:36,639
پایتون 3.8 و 3.9 را میبینید، اما اگر در پایتون 3.5 انتخابی داشته باشیم که تا پایتون 3.9 باقی نمیماند، میتوان به
562
00:15:36,639 –> 00:15:38,480
طور مداوم برای همه اجراها مشاهده کرد که من انجام دادم
563
00:15:38,480 –> 00:15:41,199
این کار اساساً تغییر کرد.
564
00:15:41,199 –> 00:15:43,199
565
00:15:43,199 –> 00:15:43,920
566
00:15:43,920 –> 00:15:47,040
567
00:15:47,040 –> 00:15:47,759
568
00:15:47,759 –> 00:15:50,560
خوب این
569
00:15:50,560 –> 00:15:52,000
در واقع بسیار مشکل ساز است
570
00:15:52,000 –> 00:15:53,440
، باید بفهمم کدام یک از اینها
571
00:15:53,440 –> 00:15:54,800
را برای نسخه پایتون انتخاب کنم و
572
00:15:54,800 –> 00:15:56,320
مطمئناً چهار تا از آنها را انتخاب
573
00:15:56,320 –> 00:15:57,600
نمی کنم و
574
00:15:57,600 –> 00:16:00,160
اگر اطلاعات نسخه sysdot برابر با 3.5 باشد، هفت مورد را انتخاب نمی کنم
575
00:16:00,160 –> 00:16:00,639
576
00:16:00,639 –> 00:16:02,880
اگر نسخه sysdot برابر با 3.6 باشد این یکی را انجام دهید. یکی از
577
00:16:02,880 –> 00:16:03,920
578
00:16:03,920 –> 00:16:05,519
روشهایی که بررسی آن
579
00:16:05,519 –> 00:16:07,279
سرعت عملکرد زیرین را
580
00:16:07,279 –> 00:16:09,040
کاهش میدهد، مقدار زیادی نویز
581
00:16:09,040 –> 00:16:10,720
و مکانیسم را به پایه کد من اضافه میکند،
582
00:16:10,720 –> 00:16:12,560
هیچکس هرگز این کار را انجام نمیدهد، در واقع وقتی
583
00:16:12,560 –> 00:16:14,320
افراد واقعاً بهینهسازیهای میکرو
584
00:16:14,320 –> 00:16:15,120
انجام میدهند، چه
585
00:16:15,120 –> 00:16:16,160
میکنند. به نسخه فعلی
586
00:16:16,160 –> 00:16:17,759
پایتون که از آن استفاده میکنند نگاه کنید، میبینند
587
00:16:17,759 –> 00:16:19,360
کدام سریعتر است و تمام نسخههای قبلی را حذف میکنند
588
00:16:19,360 –> 00:16:20,320
589
00:16:20,320 –> 00:16:22,480
و در نتیجه نسخهای که
590
00:16:22,480 –> 00:16:23,759
فکر میکنند سریعتر است یا خیر.
591
00:16:23,759 –> 00:16:26,399
est در طول زمان دیگر سریعترین نیست و
592
00:16:26,399 –> 00:16:27,440
شما از اندازهگیریهای آن میبینید که
593
00:16:27,440 –> 00:16:29,360
فقط یک
594
00:16:29,360 –> 00:16:31,199
ساختار بسیار ساده بسیار کوچک
595
00:16:31,199 –> 00:16:33,920
در چهار نسخه بسیار بسیار مشابه
596
00:16:33,920 –> 00:16:35,839
پایتون مشاهده میکنیم که تغییر چشمگیری در
597
00:16:35,839 –> 00:16:36,959
آنها سریعترین و
598
00:16:36,959 –> 00:16:38,240
کندترین است و وجود دارد.
599
00:16:38,240 –> 00:16:39,519
تفاوت چشمگیر بین سریعترین و
600
00:16:39,519 –> 00:16:40,720
601
00:16:40,720 –> 00:16:41,839
شیبها انتخابی که آنها
602
00:16:41,839 –> 00:16:43,199
میکردند اشتباه بود و
603
00:16:43,199 –> 00:16:44,720
هرگز نمیتوانستند تشخیص دهند،
604
00:16:44,720 –> 00:16:46,399
زیرا آنها res نداشتند
605
00:16:46,399 –> 00:16:47,759
، آنها قطعات کد قبلی را حفظ نمیکردند
606
00:16:47,759 –> 00:16:49,040
607
00:16:49,040 –> 00:16:51,120
که تا حدودی تعجبآور است که چگونه میتوانستند شما
608
00:16:51,120 –> 00:16:52,880
حتی این را در طول زمان ردیابی میکنید، منظورم این است که
609
00:16:52,880 –> 00:16:54,639
قطعاً حتی اگر فکر میکردید اوه،
610
00:16:54,639 –> 00:16:55,759
میخواهم مطمئن شوم که این همیشه سریعترین است،
611
00:16:55,759 –> 00:16:57,040
اجازه دهید هر چهار نسخه را نگه دارم،
612
00:16:57,040 –> 00:16:58,800
شاید نسخههای جدیدی بهخوبی ارائه
613
00:16:58,800 –> 00:17:00,240
شوند که چندان مهم نیست، اما چگونه
614
00:17:00,240 –> 00:17:01,600
میتوانید آن را دنبال کنید. این در طول زمان
615
00:17:01,600 –> 00:17:02,880
بسیار دشوار خواهد بود
616
00:17:02,880 –> 00:17:05,359
و می توانید به این سوال فکر کنید که
617
00:17:05,359 –> 00:17:06,640
از کدام نسخه
618
00:17:06,640 –> 00:17:08,079
پایتون ممکن است از کدام نسخه پایتون استفاده کرده باشید
619
00:17:08,079 –> 00:17:09,919
تا این را مانند شاید بنویسید و من فقط باید
620
00:17:09,919 –> 00:17:11,199
از آخرین نسخه استفاده کنم، باید تمام کدهایم
621
00:17:11,199 –> 00:17:12,319
را با سریعترین و
622
00:17:12,319 –> 00:17:13,359
با استفاده از نسخه اصلی
623
00:17:13,359 –> 00:17:15,679
پایتون 2.9 بنویسم، اما
624
00:17:15,679 –> 00:17:17,679
این امکان را شامل نمی
625
00:17:17,679 –> 00:17:20,079
شود که کاربران من از پایتون 3.5 استفاده کنند
626
00:17:20,079 –> 00:17:21,760
چگونه می توانم از این موضوع بفهمم.
627
00:17:21,760 –> 00:17:23,599
ماتریسی از گزینهها که گزینه ایدهآل است
628
00:17:23,599 –> 00:17:24,240
629
00:17:24,240 –> 00:17:26,240
چگونه میتوانید حتی این را
630
00:17:26,240 –> 00:17:27,919
سیستمبندی کنید، متأسفانه است، اما هیچ راهی واقعی برای
631
00:17:27,919 –> 00:17:29,200
ما وجود ندارد که هر نوع
632
00:17:29,200 –> 00:17:30,240
اطلاعات ساختاری را در برنامه خود
633
00:17:30,240 –> 00:17:31,919
قرار دهیم تا خود برنامه بهطور
634
00:17:31,919 –> 00:17:33,679
پویا انتخاب کند که کدام یک از این چهار به صورت ایدهآل
635
00:17:33,679 –> 00:17:34,640
سریعترین است.
636
00:17:34,640 –> 00:17:36,320
اگر ما یک کامپایلر بسیار هوشمند داشتیم،
637
00:17:36,320 –> 00:17:37,760
یک کامپایلر هوشمند
638
00:17:37,760 –> 00:17:39,200
میتوانستید به آن بگویید این
639
00:17:39,200 –> 00:17:40,640
کاری است که من میخواهم انجام دهم و میتوانستم بفهمم
640
00:17:40,640 –> 00:17:41,840
کدام یک از اینها سریعترین هستند،
641
00:17:41,840 –> 00:17:42,960
اما آن سطح از
642
00:17:42,960 –> 00:17:44,080
اطلاعات ساختاری و آن سطح از کامپایلر هوشمند
643
00:17:44,080 –> 00:17:45,840
بسیار فراتر از آن است. ما
644
00:17:45,840 –> 00:17:46,559
در پایتون دیدهایم
645
00:17:46,559 –> 00:17:47,919
و تا حد زیادی حتی بسیار
646
00:17:47,919 –> 00:17:49,760
فراتر از آن چیزی است که در اکثر زبانها دیدهایم به
647
00:17:49,760 –> 00:17:50,960
غیر از زبانهایی که دارای
648
00:17:50,960 –> 00:17:54,400
بهینهسازهای پرس و جو مانند sql هستند، در واقع
649
00:17:54,400 –> 00:17:56,880
یک سرور بیشتر مشکل اصلی این خواهد بود که اگر
650
00:17:56,880 –> 00:17:58,400
از ابزاری مانند پانداها استفاده میکردیم
651
00:17:58,400 –> 00:18:00,320
و پانداها مسیرهای سریع زیادی دارد، بنابراین
652
00:18:00,320 –> 00:18:02,080
ممکن بود سریعترین
653
00:18:02,080 –> 00:18:03,840
روش را انتخاب کنیم و سپس ناگهان جف فریبک
654
00:18:03,840 –> 00:18:05,520
یک مسیر سریع دیگر را به پانداها اضافه کرد
655
00:18:05,520 –> 00:18:06,880
و سریعترین رویکردی که ما انتخاب
656
00:18:06,880 –> 00:18:08,559
کردیم این بود. انحراف که زشتتر
657
00:18:08,559 –> 00:18:09,120
از
658
00:18:09,120 –> 00:18:11,280
رویکرد احمقانه احمقانهای بود که ما
659
00:18:11,280 –> 00:18:13,039
با استفاده از scalene یا pi spy اندازهگیری کردیم
660
00:18:13,039 –> 00:18:13,760
661
00:18:13,760 –> 00:18:15,760
، اکنون سریعتر است، زیرا آنها یک
662
00:18:15,760 –> 00:18:17,039
مسیر سریع برای این کد احمقانه اضافه کردهاند،
663
00:18:17,039 –> 00:18:18,559
یک چیز شگفتانگیز که وقتی واقعاً سعی میکنید کد پایتون را بهینه کنید، خواهید دید.
664
00:18:18,559 –> 00:18:20,320
665
00:18:20,320 –> 00:18:22,799
کد پایتون خنگ است در نهایت نسبتاً
666
00:18:22,799 –> 00:18:23,520
سریع است
667
00:18:23,520 –> 00:18:24,799
و یکی از دلایل خوب
668
00:18:24,799 –> 00:18:26,880
انجام شدن آن کد پایتون احتمالاً
669
00:18:26,880 –> 00:18:28,640
در معیارهای عملکرد بسیار ظاهر می شود و به دلیل اینکه
670
00:18:28,640 –> 00:18:30,160
معیارهای عملکرد زیادی را نشان می
671
00:18:30,160 –> 00:18:31,440
دهد احتمالاً توجه توسعه دهندگان اصلی را به خود جلب می
672
00:18:31,440 –> 00:18:32,960
کند زیرا
673
00:18:32,960 –> 00:18:34,080
توجه توسعه دهندگان اصلی را جلب می کند، آنها
674
00:18:34,080 –> 00:18:35,840
سپس می روند و آن مسیرها را بهینه می کنند
675
00:18:35,840 –> 00:18:37,679
و بنابراین شما این نوع رفتار منحرف
676
00:18:37,679 –> 00:18:38,880
را دارید که در آن
677
00:18:38,880 –> 00:18:41,120
تلاش شما برای بهینه سازی ممکن است گیج شود.
678
00:18:41,120 –> 00:18:42,080
679
00:18:42,080 –> 00:18:43,520
با تلاشهای توسعهدهندگان اصلی برای
680
00:18:43,520 –> 00:18:44,799
بهینهسازی و شما این
681
00:18:44,799 –> 00:18:45,520
رفتار منحرف را دارید که در آن
682
00:18:45,520 –> 00:18:47,200
شخصی یک مسیر سریع اضافه میکند و کد
683
00:18:47,200 –> 00:18:48,480
شما که فکر میکردید سریعترین است،
684
00:18:48,480 –> 00:18:49,520
دیگر سریعترین
685
00:18:49,520 –> 00:18:50,799
686
00:18:50,799 –> 00:18:52,400
نیست. فقط
687
00:18:52,400 –> 00:18:53,600
تستهای رگرسیون را اضافه میکنم،
688
00:18:53,600 –> 00:18:55,360
بنابراین من فقط یک تست کوچک را
689
00:18:55,360 –> 00:18:56,960
به پایه کدم اضافه میکنم و فقط تست میکنم تا ببینم
690
00:18:56,960 –> 00:18:57,440
آیا
691
00:18:57,440 –> 00:18:59,039
در طول زمان کندتر میشود یا نه و این ممکن
692
00:18:59,039 –> 00:19:00,400
است کار معنیداری باشد که ممکن است
693
00:19:00,400 –> 00:19:01,919
در واقع در این زمینه گرفتار شده باشید. نتایج آزمایش نشان
694
00:19:01,919 –> 00:19:04,000
میدهد که پایتون 3.9 به هر دلیلی
695
00:19:04,000 –> 00:19:05,200
در برخی از این
696
00:19:05,200 –> 00:19:07,280
معیارها کندتر از پایتون 3.8 است، شاید به این
697
00:19:07,280 –> 00:19:08,000
دلیل است
698
00:19:08,000 –> 00:19:09,520
که میدانید بهعنوان یک ساخت rc،
699
00:19:09,520 –> 00:19:11,200
برخی بهینهسازیها را در داکر هاب اضافه
700
00:19:11,200 –> 00:19:12,799
701
00:19:12,799 –> 00:19:15,039
نکردهاند، مطمئن نیستم اما مطمئن نیستم اما اگر به این فکر کنید که
702
00:19:15,039 –> 00:19:16,320
آن تست رگرسیون چه چیزی به شما میگوید
703
00:19:16,320 –> 00:19:17,760
، به شما نمیگوید سریعترین
704
00:19:17,760 –> 00:19:19,760
چه چیزی به شما میگوید
705
00:19:19,760 –> 00:19:22,080
آیا کد من کندتر شده است، بنابراین در عمل
706
00:19:22,080 –> 00:19:23,120
707
00:19:23,120 –> 00:19:24,880
سریعترین کد ممکن را نمینوشتید، سریعترین کد ممکن را
708
00:19:24,880 –> 00:19:27,120
مینوشتید. کد ممکن به اندازه کافی
709
00:19:27,120 –> 00:19:29,280
تست رگرسیون به طور ضمنی به من می گوید
710
00:19:29,280 –> 00:19:31,200
که چیزی که واقعاً به آن اهمیت می دادید این بود
711
00:19:31,200 –> 00:19:32,480
که کد من به اندازه کافی سریع بود
712
00:19:32,480 –> 00:19:34,400
که معیارهایی را برای رسیدن به برخی از
713
00:19:34,400 –> 00:19:35,760
پایه های عملکرد برآورده کرد
714
00:19:35,760 –> 00:19:37,520
و تا زمانی که در آن خط پایه باقی بماند
715
00:19:37,520 –> 00:19:39,679
من خوشحال هستم تا زمانی که این کار را نداشته باشد.
716
00:19:39,679 –> 00:19:40,799
از آن خط مبنا منحرف می شوید، واقعاً به این
717
00:19:40,799 –> 00:19:42,640
اهمیت نمی دادید که سریع ترین کدی که تا به حال برایتان مهم است چیست
718
00:19:42,640 –> 00:19:44,320
، آیا به اندازه کافی سریع
719
00:19:44,320 –> 00:19:46,559
مورد استفاده من است، خوب اگر
720
00:19:46,559 –> 00:19:48,320
اینطور است، آیا واقعاً مهم است که برای
721
00:19:48,320 –> 00:19:49,840
مورد استفاده شما سریع باشد، شاید
722
00:19:49,840 –> 00:19:51,200
باید برمی گشتی و واقعاً می
723
00:19:51,200 –> 00:19:52,799
فهمیدی می دانی این
724
00:19:52,799 –> 00:19:53,840
همان چیزی است که من باید
725
00:19:53,840 –> 00:19:54,960
وقت خود را صرف آن
726
00:19:54,960 –> 00:19:58,080
کنم قبل از اینکه
727
00:19:58,080 –> 00:19:59,280
در مورد این جنبه تجاری
728
00:19:59,280 –> 00:20:00,960
صحبت کنیم، می خواهم در مورد شهود صحبت کنم
729
00:20:00,960 –> 00:20:01,919
زیرا وقتی به آن نگاه می کنید به عنوان
730
00:20:01,919 –> 00:20:03,039
مثال ممکن است بگویید این یک مثال احمقانه است
731
00:20:03,039 –> 00:20:04,880
که درک لیست
732
00:20:04,880 –> 00:20:05,679
بدون فراخوانی
733
00:20:05,679 –> 00:20:08,000
تابع همیشه سریعترین است و
734
00:20:08,000 –> 00:20:09,600
همیشه سریعترین است.
735
00:20:09,600 –> 00:20:11,440
736
00:20:11,440 –> 00:20:12,640
میخواهم بگویم
737
00:20:12,640 –> 00:20:14,080
میدانید چه چیزی بین برخی از آن
738
00:20:14,080 –> 00:20:15,600
گزینههای دیگر ممکن است چندان
739
00:20:15,600 –> 00:20:16,320
معنادار نباشد،
740
00:20:16,320 –> 00:20:18,159
اما واضح است که من سریعترین گزینه را میدانم،
741
00:20:18,159 –> 00:20:19,200
من همیشه سریعترین
742
00:20:19,200 –> 00:20:20,960
گزینه را انتخاب میکنم، بنابراین این بازی که ما
743
00:20:20,960 –> 00:20:23,039
در اینجا در نسخههای مختلف پایتون بازی میکنیم، وجود
744
00:20:23,039 –> 00:20:25,120
ندارد. واقعاً بر درک فهرست خالص
745
00:20:25,120 –> 00:20:26,559
بدون
746
00:20:26,559 –> 00:20:27,679
مثال فراخوانی تابع تأثیر میگذارد
747
00:20:27,679 –> 00:20:29,039
و شهود من به درستی مرا راهنمایی میکند
748
00:20:29,039 –> 00:20:30,559
و
749
00:20:30,559 –> 00:20:31,919
در این دام نمیافتم، بنابراین بیایید کمی
750
00:20:31,919 –> 00:20:32,880
در مورد شهود صحبت کنیم،
751
00:20:32,880 –> 00:20:34,480
میتوانیم ببینیم که در همه موارد کاملاً صادق است.
752
00:20:34,480 –> 00:20:36,400
نسخههای ما از پایتون
753
00:20:36,400 –> 00:20:38,880
اکنون اگر پایتون 3.5 را مقایسه کنیم،
754
00:20:38,880 –> 00:20:39,760
قطعاً میتوانیم بفهمیم که
755
00:20:39,760 –> 00:20:41,280
درک بدون فراخوانی
756
00:20:41,280 –> 00:20:43,520
تابع قطعاً
757
00:20:43,520 –> 00:20:45,200
با حاشیه قابل توجهی سریعتر از
758
00:20:45,200 –> 00:20:46,640
هر چیز دیگری است و بنابراین
759
00:20:46,640 –> 00:20:48,000
برای ما تا حدودی مصنوعی بود
760
00:20:48,000 –> 00:20:51,360
که آن را از بررسی خود حذف کنیم
761
00:20:51,360 –> 00:20:53,200
، بیایید امتحان کنیم و بفهمیم چرا ممکن است این اتفاق
762
00:20:53,200 –> 00:20:54,559
بیفتد و کاری که ممکن است انجام دهیم این است که
763
00:20:54,559 –> 00:20:55,840
ممکن است یک قطعه بسیار ساده از
764
00:20:55,840 –> 00:20:56,640
کد پایتون
765
00:20:56,640 –> 00:20:58,320
سه تابع بنویسیم که یکی به نام fff یکی
766
00:20:58,320 –> 00:21:00,320
به نام ggg و o ne
767
00:21:00,320 –> 00:21:03,600
calls hhh fff calls ggg ggg تماس hhh hhh کاری را
768
00:21:03,600 –> 00:21:05,520
انجام نمی دهد که به آن fff می
769
00:21:05,520 –> 00:21:07,280
گویند و کاری که ممکن است انجام دهیم این است که
770
00:21:07,280 –> 00:21:08,960
ممکن است مفسر پایتون خود را زیر
771
00:21:08,960 –> 00:21:10,320
gdb اجرا کنیم و یک
772
00:21:10,320 –> 00:21:11,039
نقطه شکست شرطی
773
00:21:11,039 –> 00:21:12,799
قرار دهیم و یک عدد قرار دهیم. نقطه انفصال شرطی
774
00:21:12,799 –> 00:21:14,480
در فراخوانی تابع واقعی،
775
00:21:14,480 –> 00:21:16,559
ما به دنبال یک نوع تابع pi c
776
00:21:16,559 –> 00:21:18,400
خواهیم بود، در واقع خواهیم دید که آیا این تابع hhh است یا خیر و زمانی که آن
777
00:21:18,400 –> 00:21:19,840
تابع hhh واقعاً توسط مفسر پایتون فراخوانی می شود، سعی می کنیم یک نقطه شکست
778
00:21:19,840 –> 00:21:21,600
779
00:21:21,600 –> 00:21:23,679
780
00:21:23,679 –> 00:21:25,440
قرار دهیم. خواهیم دید که در سطح c
781
00:21:25,440 –> 00:21:27,360
و بنابراین ما یک نقطه شکست بر روی
782
00:21:27,360 –> 00:21:28,960
فراخوانی بردار شی pi قرار می دهیم که بخشی
783
00:21:28,960 –> 00:21:30,480
از مفسر پایتون ما است که
784
00:21:30,480 –> 00:21:31,760
فراخوانی های تابع را مدیریت می کند، بنابراین این تابع c
785
00:21:31,760 –> 00:21:33,600
است که فراخوانی
786
00:21:33,600 –> 00:21:34,960
توابع پایتون را کنترل می کند و بنابراین
787
00:21:34,960 –> 00:21:36,240
ترکیب با این
788
00:21:36,240 –> 00:21:38,000
نقطه انفصال شرطی و نقطه شکست در اینجا
789
00:21:38,000 –> 00:21:39,760
و کدی که در اینجا نوشته شده است،
790
00:21:39,760 –> 00:21:41,280
باید همه چیزهایی را که نیاز داریم داشته باشیم تا
791
00:21:41,280 –> 00:21:42,880
ببینیم وقتی یک تابع در پایتون فراخوانی می شود چه اتفاقی می افتد
792
00:21:42,880 –> 00:21:44,559
، اکنون به خاطر داشته باشید که
793
00:21:44,559 –> 00:21:45,760
این برنامه کار
794
00:21:45,760 –> 00:21:47,280
جالبی انجام نمی دهد. ines سه
795
00:21:47,280 –> 00:21:49,120
تابع و آنها را فراخوانی می کند
796
00:21:49,120 –> 00:21:50,640
و این که می بینید باید سه
797
00:21:50,640 –> 00:21:52,559
فراخوانی تابعی را ببینید که می دانید به
798
00:21:52,559 –> 00:21:55,120
صورت سریال انجام می شود و این چیز
799
00:21:55,120 –> 00:21:56,080
دیگری است که جالب
800
00:21:56,080 –> 00:21:57,280
801
00:21:57,280 –> 00:21:58,799
است این ردیابی پشته ای است
802
00:21:58,799 –> 00:21:59,520
که دریافت می کنید
803
00:21:59,520 –> 00:22:01,200
شما حتی نمی توانید ببینید چه چیزی روی صفحه
804
00:22:01,200 –> 00:22:02,640
است،
805
00:22:02,640 –> 00:22:05,039
قاب های پشته ای 31c مربوط به یک
806
00:22:05,039 –> 00:22:06,320
برنامه ساده پایتون ساختگی است
807
00:22:06,320 –> 00:22:09,679
که سه فراخوانی تابع
808
00:22:09,679 –> 00:22:10,240
809
00:22:10,240 –> 00:22:12,000
810
00:22:12,000 –> 00:22:13,280
811
00:22:13,280 –> 00:22:15,600
را به خوبی انجام می دهد.
812
00:22:15,600 –> 00:22:17,679
فریمهای پشتهای و اگر مقداری
813
00:22:17,679 –> 00:22:18,960
از نویز را از آن حذف کنیم و به
814
00:22:18,960 –> 00:22:20,720
یک زیربخش کوچکتر از آن نگاه کنیم،
815
00:22:20,720 –> 00:22:22,000
تقریباً
816
00:22:22,000 –> 00:22:23,520
زیربخشی از آن است که مربوط به
817
00:22:23,520 –> 00:22:25,039
یک تابع به نام است، بنابراین حدود یک
818
00:22:25,039 –> 00:22:26,640
فراخوانی تابع در پایتون
819
00:22:26,640 –> 00:22:29,520
با هفت فریم پشته در c
820
00:22:29,520 –> 00:22:31,200
به هفت تابع را در c باید
821
00:22:31,200 –> 00:22:32,159
فراخوانی کنید وکتور
822
00:22:32,159 –> 00:22:33,360
823
00:22:33,360 –> 00:22:34,480
824
00:22:34,480 –> 00:22:36,159
فراخوانی کنید.
825
00:22:36,159 –> 00:22:37,919
می توانید فراخوانی
826
00:22:37,919 –> 00:22:39,039
این را ببینید در این مورد
827
00:22:39,039 –> 00:22:41,360
فراخوانی hhhh
828
00:22:41,360 –> 00:22:43,600
از ggg است، بنابراین می توانید ببینید که کار بسیار
829
00:22:43,600 –> 00:22:45,200
زیادی وجود دارد، پخش بسیار زیادی وجود دارد،
830
00:22:45,200 –> 00:22:45,919
831
00:22:45,919 –> 00:22:47,919
یک خط پایتون با بسیاری از
832
00:22:47,919 –> 00:22:49,520
خطوط کد c مطابقت دارد و می توانید فکر کنید
833
00:22:49,520 –> 00:22:52,240
فراخوانی تابع خوب واقعاً گران هستند
834
00:22:52,240 –> 00:22:52,960
و
835
00:22:52,960 –> 00:22:54,799
شاید سرعت فراخوانی این تابع
836
00:22:54,799 –> 00:22:56,480
چیزی است که بر سرعت کلی این معیار غالب است
837
00:22:56,480 –> 00:22:57,280
838
00:22:57,280 –> 00:22:59,200
و در نتیجه اگر آن را
839
00:22:59,200 –> 00:23:00,400
به طور کامل
840
00:23:00,400 –> 00:23:03,039
حذف کنم، سرعت قابل توجهی را مشاهده خواهم کرد و
841
00:23:03,039 –> 00:23:04,400
به همین دلیل است که درک خالص
842
00:23:04,400 –> 00:23:04,880
کار می کند.
843
00:23:04,880 –> 00:23:06,799
و نمونههای دیگر هستند یا جایی که
844
00:23:06,799 –> 00:23:08,320
ترکیب خالص در همه موارد سریعتر است
845
00:23:08,320 –> 00:23:09,520
،
846
00:23:09,520 –> 00:23:11,840
نمونههای دیگر رفتارهای متفاوت دیگری دارند،
847
00:23:11,840 –> 00:23:13,360
اکنون ممکن است شما را گمراه کند زیرا
848
00:23:13,360 –> 00:23:14,880
ممکن است این شهودی باشد که
849
00:23:14,880 –> 00:23:17,039
اگر بخواهم کد پایتون من سریع باشد
850
00:23:17,039 –> 00:23:19,039
حتی اگر محیط اجرا در اطراف
851
00:23:19,039 –> 00:23:20,640
من تغییر می کند من باید از چیزهایی مانند
852
00:23:20,640 –> 00:23:21,760
فراخوانی تابع اجتناب کنم.
853
00:23:21,760 –> 00:23:23,360
854
00:23:23,360 –> 00:23:24,240
855
00:23:24,240 –> 00:23:26,000
اوه و
856
00:23:26,000 –> 00:23:28,880
من فقط باید جلو بروم و
857
00:23:28,880 –> 00:23:30,559
از این شهود برای راهنمایی نحوه نوشتن
858
00:23:30,559 –> 00:23:32,240
کدم استفاده کنم، اوه آیا یک تابع اضافی
859
00:23:32,240 –> 00:23:32,799
در اینجا فراخوانی شده
860
00:23:32,799 –> 00:23:34,080
است، بهتر است از آن استفاده نکنم، اکنون سعی می کنم تا
861
00:23:34,080 –> 00:23:36,159
آنجایی که ممکن است چیزهای زیادی را وارد
862
00:23:36,159 –> 00:23:37,360
کنم زیرا ممکن است
863
00:23:37,360 –> 00:23:38,720
شما را گمراه کند این است که فراخوانی تابع
864
00:23:38,720 –> 00:23:40,720
لزوماً کند نیست اکنون این یک
865
00:23:40,720 –> 00:23:41,520
866
00:23:41,520 –> 00:23:43,600
جمله تا حدی ضعیف است زیرا
867
00:23:43,600 –> 00:23:45,360
ممکن است بهینهسازیهای بیشتر
868
00:23:45,360 –> 00:23:46,960
این هفت فریم پشته را به
869
00:23:46,960 –> 00:23:48,480
کمتر از هفت فریم پشته کاهش
870
00:23:48,480 –> 00:23:50,480
871
00:23:50,480 –> 00:23:52,159
دهد. در یک
872
00:23:52,159 –> 00:23:53,600
فراخوانی تابع در پایتون،
873
00:23:53,600 –> 00:23:55,360
فراخوانی تابع در پایتون اکنون بسیار
874
00:23:55,360 –> 00:23:56,880
سریعتر از
875
00:23:56,880 –> 00:23:58,480
نسخه های قبلی پایتون یا پایتون
876
00:23:58,480 –> 00:24:00,080
2 است. و به
877
00:24:00,080 –> 00:24:01,440
این ترتیب که امروز کند هستند
878
00:24:01,440 –> 00:24:02,720
لزوماً به این معنی نیست که کسی نمی تواند وارد شود
879
00:24:02,720 –> 00:24:04,320
و برخی را پیدا کند. پدهای سریع دیگر برای
880
00:24:04,320 –> 00:24:05,520
سریع کردن آنها فردا
881
00:24:05,520 –> 00:24:07,039
و این فقط در مورد برخی از
882
00:24:07,039 –> 00:24:08,559
فراخوانی های تابع صحبت
883
00:24:08,559 –> 00:24:09,039
884
00:24:09,039 –> 00:24:10,880
885
00:24:10,880 –> 00:24:12,799
886
00:24:12,799 –> 00:24:14,720
می کند. قبلاً
887
00:24:14,720 –> 00:24:16,000
برای فراخوانی توابع فراخوانی شده است که در آن
888
00:24:16,000 –> 00:24:17,679
خود تابع با c نوشته شده است یا
889
00:24:17,679 –> 00:24:18,960
یک تابع داخلی یا چیزی شبیه به آن
890
00:24:18,960 –> 00:24:19,679
است
891
00:24:19,679 –> 00:24:21,279
در حال حاضر حتی اگر این امر تا حدی ضعیف است،
892
00:24:21,279 –> 00:24:23,120
زیرا در عمل به طور کلی
893
00:24:23,120 –> 00:24:24,720
امروز بله فراخوانی تابع به نوعی
894
00:24:24,720 –> 00:24:25,520
کند است
895
00:24:25,520 –> 00:24:27,520
اما a و در عمل وقتی
896
00:24:27,520 –> 00:24:29,039
بنچمارکها را انجام میدهیم، میبینیم که آنها به نوعی
897
00:24:29,039 –> 00:24:29,679
898
00:24:29,679 –> 00:24:32,880
دیگر کندی را از بین میبرند،
899
00:24:33,200 –> 00:24:34,880
اما چیزی در اینجا عجیب است
900
00:24:34,880 –> 00:24:36,799
زیرا در مثال پایتون 3.7
901
00:24:36,799 –> 00:24:38,080
ما دو فراخوانی تابع
902
00:24:38,080 –> 00:24:40,320
داریم که آن را list this value constructor
903
00:24:40,320 –> 00:24:42,400
مینامیم و نقشه را این ساخته مینامیم. -in تابع
904
00:24:42,400 –> 00:24:44,960
، اما این سریعتر از فراخوانی یک
905
00:24:44,960 –> 00:24:45,600
تابع
906
00:24:45,600 –> 00:24:48,640
نقشه و سپس فراخوانی و سپس باز کردن آن
907
00:24:48,640 –> 00:24:49,440
در یک لیست است،
908
00:24:49,440 –> 00:24:50,880
اکنون بدیهی است که برخی از این
909
00:24:50,880 –> 00:24:52,480
موارد با
910
00:24:52,480 –> 00:24:55,440
فراخوانی های متعدد به این تابع f از بین
911
00:24:55,440 –> 00:24:56,080
912
00:24:56,080 –> 00:24:57,840
می رود، اما با این حال انتظار دارید که این کار را انجام ندهید. واقعاً
913
00:24:57,840 –> 00:25:00,000
انتظار نمیرود شماره دو سریعترین
914
00:25:00,000 –> 00:25:01,360
از این دو باشد، اکنون ممکن است
915
00:25:01,360 –> 00:25:02,720
خطای اندازهگیری در اینجا وجود داشته باشد، من این را روی
916
00:25:02,720 –> 00:25:03,840
چند نمونه انجام دادم،
917
00:25:03,840 –> 00:25:05,440
اما چیزی در اینجا جالب
918
00:25:05,440 –> 00:25:07,039
است.
919
00:25:07,039 –> 00:25:09,200
به نظر می رسید فراخوانی تابع اضافی واقعاً تفاوتی ایجاد نمی کند
920
00:25:09,200 –> 00:25:10,720
و اگر به دقت نگاه کنیم
921
00:25:10,720 –> 00:25:13,279
کد بایت چیست، می دانید و در دوبار 3.7
922
00:25:13,279 –> 00:25:15,120
این خط یک تابع
923
00:25:15,120 –> 00:25:16,880
فراخوانی است و بسیاری از خطوط c را فراخوانی می کند،
924
00:25:16,880 –> 00:25:18,960
هفت فریم پشته ای از c را می شناسید. و
925
00:25:18,960 –> 00:25:20,480
خط دیگر یک لیست بیلد
926
00:25:20,480 –> 00:25:23,039
باز کردن بسته بندی در پایتون 3.9 است که کمی
927
00:25:23,039 –> 00:25:24,480
به کد بایت گسترش لیست تغییر
928
00:25:24,480 –> 00:25:27,600
می کند و در پایتون 3.9 این
929
00:25:27,600 –> 00:25:28,000
930
00:25:28,000 –> 00:25:31,360
نسخه اخیر اکنون کمی به سختی قابل اندازه گیری سریعتر است،
931
00:25:31,360 –> 00:25:32,880
اما می بینید که می دانید این
932
00:25:32,880 –> 00:25:34,480
راهنمایی oh فقط از فراخوانی تابع اجتناب کنید.
933
00:25:34,480 –> 00:25:35,840
در این مثال موفق به انجام این کار
934
00:25:35,840 –> 00:25:37,120
نشد زیرا واقعاً به
935
00:25:37,120 –> 00:25:38,559
ما نشان نمی دهد که کدام یک از
936
00:25:38,559 –> 00:25:40,000
اینها سریعتر است اکنون می توانید بگویید
937
00:25:40,000 –> 00:25:41,440
که آنها تعداد دفعات استفاده
938
00:25:41,440 –> 00:25:42,240
از
939
00:25:42,240 –> 00:25:44,159
این رفتار را در نظر نگرفته اند، اما
940
00:25:44,159 –> 00:25:46,720
هنوز چیزی تا حدودی کم است. در اینجا
941
00:25:46,720 –> 00:25:48,640
اساساً فکر میکنم راهنمایی بهتر
942
00:25:48,640 –> 00:25:50,400
از این شهود این است که پایتون به
943
00:25:50,400 –> 00:25:51,360
خودی خود کند است
944
00:25:51,360 –> 00:25:53,520
یا شاید فراخوانی کد بایت کند است
945
00:25:53,520 –> 00:25:54,559
یا شاید انجام
946
00:25:54,559 –> 00:25:56,880
کار اصلاً کند باشد اگر نیاز به انجام برخی کارها دارید.
947
00:25:56,880 –> 00:25:58,559
آهسته خواهد بود
948
00:25:58,559 –> 00:26:00,480
و شهودی که ممکن است داشته باشید که
949
00:26:00,480 –> 00:26:02,080
مربوط به این است این است که ارسال پویا
950
00:26:02,080 –> 00:26:02,640
آهسته است
951
00:26:02,640 –> 00:26:04,480
شما می دانید که هر بار که ما مجبور به فراخوانی
952
00:26:04,480 –> 00:26:06,080
انجام عملیات در پایتون هستیم، اعزام پویا انجام می دهیم
953
00:26:06,080 –> 00:26:06,960
954
00:26:06,960 –> 00:26:08,320
و بسیاری از خطوط c
955
00:26:08,320 –> 00:26:10,000
مربوط به یک خط است. از پایتون
956
00:26:10,000 –> 00:26:11,520
و اینجاست که کندی پایتون به وجود
957
00:26:11,520 –> 00:26:13,440
میآید و ممکن است قبلاً این را دیده
958
00:26:13,440 –> 00:26:14,320
باشیم وقتی
959
00:26:14,320 –> 00:26:16,720
x و y را ضرب میکنیم، این یک کد بایت ضرب دودویی به شما میدهد
960
00:26:16,720 –> 00:26:18,159
که عدد پی را
961
00:26:18,159 –> 00:26:19,360
به سطح c
962
00:26:19,360 –> 00:26:21,600
فرا میخواند که مراحل بعد، طولانی ضرب را فراخوانی میکند تا
963
00:26:21,600 –> 00:26:23,279
عملاً عمل انجام شود. ضرب اگر
964
00:26:23,279 –> 00:26:24,480
اتفاقا این چیز
965
00:26:24,480 –> 00:26:28,240
دو عدد صحیح باشد و اگر یک عدد داشته
966
00:26:28,240 –> 00:26:29,600
باشیم اگر یک جمع داشته باشیم این
967
00:26:29,600 –> 00:26:31,840
ضرب دودویی نیست اما در این مورد باینری
968
00:26:31,840 –> 00:26:34,320
باینری که عدد پی را فراخوانی می کند اضافه کنید
969
00:26:34,320 –> 00:26:35,919
که در نهایت طولانی ad را فراخوانی می کند
970
00:26:35,919 –> 00:26:37,200
و اگر اتفاقی افتاد چیزی شبیه به
971
00:26:37,200 –> 00:26:39,360
رشتهها بهجای آن همچنان باینری میشوند،
972
00:26:39,360 –> 00:26:40,640
سپس عدد پی را اضافه میکنند
973
00:26:40,640 –> 00:26:42,159
و در نهایت نوعی رشته به هم
974
00:26:42,159 –> 00:26:44,000
پیوسته یا پیوسته فهرست یا الحاق تاپل
975
00:26:44,000 –> 00:26:45,600
بر اساس آنچه من در آن وجود دارد. s
976
00:26:45,600 –> 00:26:47,120
و ممکن است بگویید این
977
00:26:47,120 –> 00:26:49,200
ارسال پویا در حال اضافه کردن خطوط بسیاری از c
978
00:26:49,200 –> 00:26:50,799
برای یک خط پایتون است و بنابراین یکی از راههایی
979
00:26:50,799 –> 00:26:52,400
که میتوانم مفسر پایتون خود را
980
00:26:52,400 –> 00:26:53,760
اساساً سریعتر کنم
981
00:26:53,760 –> 00:26:55,440
این است که این ارسال پویا را
982
00:26:55,440 –> 00:26:57,200
از بین ببرم، این منشأ همه نگرانیهای من است
983
00:26:57,200 –> 00:26:59,360
و این شهود من است، اما در واقع
984
00:26:59,360 –> 00:27:01,919
اگر به کد افزودن باینری نگاهی بیندازید،
985
00:27:01,919 –> 00:27:03,279
میبینید که شخصی قبلاً وارد
986
00:27:03,279 –> 00:27:05,679
شده و در این تخصص اضافه کرده است،
987
00:27:05,679 –> 00:27:07,520
وقتی که دو شیء پایتون را اضافه میکنید، در
988
00:27:07,520 –> 00:27:08,000
989
00:27:08,000 –> 00:27:10,159
صورتی که هر دو دقیقاً اشیاء یونیکد هستند.
990
00:27:10,159 –> 00:27:12,080
یک الحاق یونیکد را
991
00:27:12,080 –> 00:27:13,840
انجام دهید و این ارسال پویا را انجام نمی دهید
992
00:27:13,840 –> 00:27:15,840
و بنابراین ممکن است بگویید که
993
00:27:15,840 –> 00:27:17,120
شهود واقعاً خوب بود
994
00:27:17,120 –> 00:27:18,960
زیرا این شهود دقیقاً به همین دلیل است که
995
00:27:18,960 –> 00:27:20,559
کسی این خط کد را اضافه کرده است
996
00:27:20,559 –> 00:27:22,559
اما اگر کمی
997
00:27:22,559 –> 00:27:24,399
بالاتر از آن خطوط کد به بالا بروید شما این نظر را خواهید دید
998
00:27:24,399 –> 00:27:25,360
999
00:27:25,360 –> 00:27:27,919
لطفا سعی نکنید با استفاده از بایت کد بهینه سازی را در
1000
00:27:27,919 –> 00:27:28,720
plus int
1001
00:27:28,720 –> 00:27:30,640
انجام دهید، این کار نمی کند،
1002
00:27:30,640 –> 00:27:32,240
بی ارزش
1003
00:27:32,240 –> 00:27:34,640
است، اگر تا به حال فکر کرده اید که
1004
00:27:34,640 –> 00:27:36,000
ارسال پویا چنین است، در عمل هیچ کاری انجام نمی دهد. دلیل کند بودن
1005
00:27:36,000 –> 00:27:36,960
پایتون
1006
00:27:36,960 –> 00:27:38,159
و بنابراین کاری که من میخواهم انجام دهم این است که
1007
00:27:38,159 –> 00:27:39,679
سعی میکنم با
1008
00:27:39,679 –> 00:27:41,279
اضافه کردن عملیات تخصصی در
1009
00:27:41,279 –> 00:27:42,960
سطح حلقه ce val خود، ارسال پویا
1010
00:27:42,960 –> 00:27:44,640
را حذف کنم.
1011
00:27:44,640 –> 00:27:45,919
خارج
1012
00:27:45,919 –> 00:27:46,399
از
1013
00:27:46,399 –> 00:27:48,240
معیارهای میکرو مصنوعی و بنابراین
1014
00:27:48,240 –> 00:27:49,760
ارسال پویا نیست،
1015
00:27:49,760 –> 00:27:51,279
این شهودی که ما در مورد
1016
00:27:51,279 –> 00:27:52,799
کند بودن ارسال پویا داریم
1017
00:27:52,799 –> 00:27:55,440
دوباره ما را گمراه می کند، اکنون آنچه ممکن است
1018
00:27:55,440 –> 00:27:56,159
فکر کنیم این است
1019
00:27:56,159 –> 00:27:58,159
که می دانید اگر پایتون
1020
00:27:58,159 –> 00:27:59,679
بتواند نوعی بهینه سازی را انجام دهد خوب نیست.
1021
00:27:59,679 –> 00:28:00,480
ما تابعی
1022
00:28:00,480 –> 00:28:02,640
از f داریم و x را برمی گرداند و من حدس می زنم که این
1023
00:28:02,640 –> 00:28:03,840
تابع باید x را به عنوان
1024
00:28:03,840 –> 00:28:04,640
آرگومان می گرفت،
1025
00:28:04,640 –> 00:28:07,440
اما شما عذرخواهی من را
1026
00:28:07,440 –> 00:28:08,399
برای اشتباه تایپی که
1027
00:28:08,399 –> 00:28:10,240
پایتون می تواند برخی از یادداشت های بهینه سازی را انجام دهد را می پذیرد،
1028
00:28:10,240 –> 00:28:11,600
شما می توانید تا کردن مداوم انجام دهید و
1029
00:28:11,600 –> 00:28:12,320
خواهید دید که
1030
00:28:12,320 –> 00:28:14,000
در عمل کاری که پایتون انجام می دهد این است
1031
00:28:14,000 –> 00:28:15,600
که یک بعلاوه یک را به دو
1032
00:28:15,600 –> 00:28:17,440
تا می کند و بنابراین این بهینه سازی بسیار ساده را انجام می دهد
1033
00:28:17,440 –> 00:28:18,880
تا
1034
00:28:18,880 –> 00:28:22,080
اگر
1035
00:28:22,080 –> 00:28:23,360
تابع g دیگری وجود داشته
1036
00:28:23,360 –> 00:28:26,640
باشد و f a نامیده شود، یک اضافه باینری غیر ضروری را حذف کند. و یک به f اضافه کرد
1037
00:28:26,640 –> 00:28:28,480
متاسفانه کاری که ما دوست داریم پایتون
1038
00:28:28,480 –> 00:28:30,399
بتواند انجام دهد این است که
1039
00:28:30,399 –> 00:28:32,000
بین این دو مورد بهینه سازی انجام دهد
1040
00:28:32,000 –> 00:28:33,520
تا آنها را با هم ترکیب کند، اما
1041
00:28:33,520 –> 00:28:35,440
متأسفانه توابع پایتون بسیار
1042
00:28:35,440 –> 00:28:36,720
مات هستند و بنابراین
1043
00:28:36,720 –> 00:28:38,080
امکان انجام مفسر پایتون وجود ندارد.
1044
00:28:38,080 –> 00:28:39,679
این نوع
1045
00:28:39,679 –> 00:28:41,120
خطبندی و بنابراین ممکن است بگوییم
1046
00:28:41,120 –> 00:28:43,279
اوم این یک شهود دیگر است،
1047
00:28:43,279 –> 00:28:45,039
میدانید دلیل کند بودن پایتون این است
1048
00:28:45,039 –> 00:28:46,880
که ما توانایی انجام
1049
00:28:46,880 –> 00:28:48,880
عملکرد متقاطع در
1050
00:28:48,880 –> 00:28:50,799
بهینهسازیهای نوع لاینینگ را نداریم، نمیتوانیم یک تابع
1051
00:28:50,799 –> 00:28:52,399
c را به تابع دیگر وارد کنیم. تابع را ببینید و به
1052
00:28:52,399 –> 00:28:53,440
آن تابع دیگر نگاه کنید و سپس از برخی
1053
00:28:53,440 –> 00:28:54,080
اطلاعات
1054
00:28:54,080 –> 00:28:55,360
موجود در آن تابع دیگر
1055
00:28:55,360 –> 00:28:57,120
برای انجام بهینهسازی استفاده کنید و
1056
00:28:57,120 –> 00:28:58,559
این ممکن است راهنمای ما باشد
1057
00:28:58,559 –> 00:29:00,480
و ممکن است از آن راهنمایی برای جلب کردن
1058
00:29:00,480 –> 00:29:02,159
خود به ابزارهایی مانند عدد استفاده کنیم، اما برای
1059
00:29:02,159 –> 00:29:03,440
کسانی از شما که واقعاً از آن استفاده میکنید. عددی که
1060
00:29:03,440 –> 00:29:05,120
میتوانید ببینید عدد به نوعی ضربه خورده است یا از
1061
00:29:05,120 –> 00:29:07,520
دست میدهید، ابزاری عالی برای استفاده است،
1062
00:29:07,520 –> 00:29:09,200
1063
00:29:09,200 –> 00:29:11,120
زیرا اگر سریعتر به کد خود ادامه دهید، فقط یک عدد دکوراتور را به بالای کد خود اضافه میکنید.
1064
00:29:11,120 –> 00:29:12,799
با زندگی خود اگر
1065
00:29:12,799 –> 00:29:15,120
سریعتر نیست چیز دیگری را
1066
00:29:15,120 –> 00:29:16,960
بفهمید اما هنوز چیزی در اینجا کم است
1067
00:29:16,960 –> 00:29:18,399
زیرا
1068
00:29:18,399 –> 00:29:20,240
در عمل وقتی از عدد استفاده می کنیم. من مطمئن هستم که
1069
00:29:20,240 –> 00:29:21,840
برخی از شما با استفاده از number.jet امتحان
1070
00:29:21,840 –> 00:29:22,320
کرده اید و
1071
00:29:22,320 –> 00:29:24,399
هیچ افزایش سرعت واقعی روی کد اصلی ندیده اید،
1072
00:29:24,399 –> 00:29:26,320
بنابراین فقط می توانید
1073
00:29:26,320 –> 00:29:28,640
ساختار کمی به آن اضافه کنید تا بتوانید این کار
1074
00:29:28,640 –> 00:29:29,520
را انجام دهید
1075
00:29:29,520 –> 00:29:30,880
تا بتوانید این عملکردها را دیگر مات نکند،
1076
00:29:30,880 –> 00:29:32,799
بلکه انجام دهید.
1077
00:29:32,799 –> 00:29:34,399
به نظر می رسد بهینه سازی بین آنها
1078
00:29:34,399 –> 00:29:36,559
کافی نیست اکنون چیز دیگری که ممکن است
1079
00:29:36,559 –> 00:29:38,320
بگویید این است که شهود من این است که بارگذاری
1080
00:29:38,320 –> 00:29:40,240
متغیرها در پایتون کند است و کم
1081
00:29:40,240 –> 00:29:41,200
جهانی کند است
1082
00:29:41,200 –> 00:29:44,480
و بنابراین اگر مجبور باشم کد پایتون خود را بهینه کنم
1083
00:29:44,480 –> 00:29:45,760
چه کاری انجام می دهم. load
1084
00:29:45,760 –> 00:29:46,880
global ها را بگیرید و من آنها را به Load
1085
00:29:46,880 –> 00:29:48,640
Local تبدیل می کنم، بنابراین این ترفندهای کوچک
1086
00:29:48,640 –> 00:29:51,039
مانند پنهان کردن متغیرها در
1087
00:29:51,039 –> 00:29:52,080
آرگومان های کلمه کلیدی را انجام می دهم و شما این را در
1088
00:29:52,080 –> 00:29:54,480
کتابخانه استاندارد پایتون خواهید دید، ماژول بازرسی
1089
00:29:54,480 –> 00:29:55,039
1090
00:29:55,039 –> 00:29:56,799
که ماژول json در چند
1091
00:29:56,799 –> 00:29:58,960
جا انجام می دهد. و این
1092
00:29:58,960 –> 00:29:59,919
بسیار مورد بود، زمانی که شما
1093
00:29:59,919 –> 00:30:00,960
یک متغیر سراسری را بارگذاری میکنید، یک
1094
00:30:00,960 –> 00:30:02,399
جستجوی فرهنگ لغت بود و کند بود
1095
00:30:02,399 –> 00:30:03,919
و اگر به کد بایت نگاه کنید، برخی بهینهسازیها
1096
00:30:03,919 –> 00:30:05,840
برای سرعت بخشیدن به جستجوی متغیرهای جهانی اضافه شده
1097
00:30:05,840 –> 00:30:07,039
است. و
1098
00:30:07,039 –> 00:30:07,760
تعجب می کنید که چرا
1099
00:30:07,760 –> 00:30:09,760
بارگذاری محلی یا اینکه چرا بارگذاری یک
1100
00:30:09,760 –> 00:30:11,360
متغیر محلی در واقع بارگذاری سریع نامیده می شود به
1101
00:30:11,360 –> 00:30:13,120
این دلیل است که یک بهینه سازی در
1102
00:30:13,120 –> 00:30:15,039
آنجا اضافه شده است که در آن بارگذاری یک متغیر محلی
1103
00:30:15,039 –> 00:30:15,600
1104
00:30:15,600 –> 00:30:17,120
در کد بایت پایتون یک
1105
00:30:17,120 –> 00:30:19,440
جستجوی فرهنگ لغت نیست و فقط یک جستجوی cra است
1106
00:30:19,440 –> 00:30:20,559
و بنابراین قطعاً در موردی که
1107
00:30:20,559 –> 00:30:21,840
کسی به آن نگاه کرد و گفت: اوه، این
1108
00:30:21,840 –> 00:30:23,120
در واقع به نوعی کند است،
1109
00:30:23,120 –> 00:30:24,399
به طور مشابه شما ممکن است شهودی
1110
00:30:24,399 –> 00:30:25,679
در مورد جستجوی روش داشته باشید و ممکن است بگویید
1111
00:30:25,679 –> 00:30:27,120
oh جستجوی روش ها کند است هر بار که
1112
00:30:27,120 –> 00:30:28,399
من یک نقطه x
1113
00:30:28,399 –> 00:30:29,840
انجام می دهم که کند است، بنابراین اگر این کار را در یک
1114
00:30:29,840 –> 00:30:31,520
حلقه تنگ احتمالاً ایده بدی است، بنابراین
1115
00:30:31,520 –> 00:30:33,039
باید آن را از یک حلقه خارج کنم،
1116
00:30:33,039 –> 00:30:34,960
اما جستجوی روش خود
1117
00:30:34,960 –> 00:30:36,720
در نسخه های نسبتاً جدید پایتون
1118
00:30:36,720 –> 00:30:37,200
نیز بهینه شده است
1119
00:30:37,200 –> 00:30:39,039
و بنابراین برخی از این شهودها ممکن است فقط
1120
00:30:39,039 –> 00:30:41,120
در مورد یک دیدگاه خاص از
1121
00:30:41,120 –> 00:30:42,159
نحوه عملکرد پایتون
1122
00:30:42,159 –> 00:30:44,159
به موقع باشد. وقتی یاد گرفتید که شهود
1123
00:30:44,159 –> 00:30:45,440
در مورد چیزی مانند بار جهانی،
1124
00:30:45,440 –> 00:30:46,640
ممکن است به خوبی بگویید دلیل کند بودن این
1125
00:30:46,640 –> 00:30:48,240
کد پایتون حتی
1126
00:30:48,240 –> 00:30:49,679
اگر فقط len را در یک حلقه فراخوانی می کند این است که
1127
00:30:49,679 –> 00:30:51,440
هر بار t حلقه hat
1128
00:30:51,440 –> 00:30:52,880
میگوید که باید جستجو کند که متغیر lend در
1129
00:30:52,880 –> 00:30:54,480
دامنه جهانی و پایتون بسیار
1130
00:30:54,480 –> 00:30:55,919
پویا است و کسی میتوانست
1131
00:30:55,919 –> 00:30:57,360
آن متغیر lend را عوض کند، بنابراین باید
1132
00:30:57,360 –> 00:30:58,880
هر بار این جستجو را انجام دهد
1133
00:30:58,880 –> 00:31:00,080
و این کار اضافی زیادی است
1134
00:31:00,080 –> 00:31:01,120
که در حال انجام است.
1135
00:31:01,120 –> 00:31:02,720
ممکن است بگویید آیا خوب نیست اگر
1136
00:31:02,720 –> 00:31:04,640
پایتون نوعی ثبات
1137
00:31:04,640 –> 00:31:06,880
مانند جاوا اسکریپت داشته باشد و شاید اگر
1138
00:31:06,880 –> 00:31:07,919
این نوع ثبات را داشت می
1139
00:31:07,919 –> 00:31:09,679
توانستیم شروع به دور زدن کنیم، می توانستیم
1140
00:31:09,679 –> 00:31:11,120
1141
00:31:11,120 –> 00:31:12,640
خودمان را در برابر برخی از طبیعت پویای
1142
00:31:12,640 –> 00:31:13,760
پایتون محافظت کنیم. این بهینهسازیها را انجام دهید،
1143
00:31:13,760 –> 00:31:14,640
1144
00:31:14,640 –> 00:31:15,840
این چیزی است که من ندیدهام
1145
00:31:15,840 –> 00:31:17,919
افراد زیادی در تلاش برای بهبود
1146
00:31:17,919 –> 00:31:19,279
مفسر پایتون تلاش کنند
1147
00:31:19,279 –> 00:31:20,399
، چیزی است که من بسیار
1148
00:31:20,399 –> 00:31:22,480
کنجکاو هستم که ببینم چگونه کار میکند، اما
1149
00:31:22,480 –> 00:31:24,080
اگر سرعت قابل توجهی را ببینید تا حدودی متعجب خواهم شد.
1150
00:31:24,080 –> 00:31:25,760
به دلیل اینکه
1151
00:31:25,760 –> 00:31:27,360
مناطقی از پایتون که مردم دیدهاند
1152
00:31:27,360 –> 00:31:28,960
که کند هستند مانند جهانی کم،
1153
00:31:28,960 –> 00:31:30,720
قبلاً کارهایی انجام دادهاند،
1154
00:31:30,720 –> 00:31:32,799
ممکن است بگویید که این در واقع یک
1155
00:31:32,799 –> 00:31:34,640
رویکرد بهینهسازی بسیار شبیه به برخی است.
1156
00:31:34,640 –> 00:31:36,399
با توجه به اینکه در عمل از pi pi استفاده کرده
1157
00:31:36,399 –> 00:31:38,320
اید، می توانید فکر کنید ابزاری مانند pi pi مشخص می
1158
00:31:38,320 –> 00:31:40,000
کند که مسیرهای سریع و پدهای آهسته وجود دارد
1159
00:31:40,000 –> 00:31:41,519
و بنابراین اگر len واقعاً
1160
00:31:41,519 –> 00:31:42,640
مسیر سریع را تغییر ندهد، فرض می
1161
00:31:42,640 –> 00:31:43,840
کند که تغییر نمی کند، عملکرد خواهد داشت.
1162
00:31:43,840 –> 00:31:44,880
نوعی جیتینگ
1163
00:31:44,880 –> 00:31:46,399
و بر اساس آن جیتینگ، میتوانیم
1164
00:31:46,399 –> 00:31:48,320
عملیات اضافی را حذف
1165
00:31:48,320 –> 00:31:49,440
کنیم، اما اگر در مورد آن جیتینگ اشتباه
1166
00:31:49,440 –> 00:31:51,279
کنیم، مسیری آهسته را دنبال
1167
00:31:51,279 –> 00:31:52,080
میکنیم و آن را جستجو میکنیم و بنابراین
1168
00:31:52,080 –> 00:31:53,360
با عملکرد سریعتر، همان رفتار را خواهیم
1169
00:31:53,360 –> 00:31:55,600
داشت. تمرین کنید من نمی دانم
1170
00:31:55,600 –> 00:31:57,360
که pi pi را به روشی بسیار
1171
00:31:57,360 –> 00:31:59,480
شبیه به عدد
1172
00:31:59,480 –> 00:32:02,080
تضمین شده مشاهده کرده ام که عملکرد کد را تضمین می کند
1173
00:32:02,080 –> 00:32:03,440
و متأسفانه چیزی که
1174
00:32:03,440 –> 00:32:04,720
در مورد pi
1175
00:32:04,720 –> 00:32:06,880
pi می بینیم پشتیبانی از ابزارهایی مانند numpy و pandas است
1176
00:32:06,880 –> 00:32:08,559
1177
00:32:08,559 –> 00:32:10,559
که می دانید بدون آن واقعاً
1178
00:32:10,559 –> 00:32:11,919
غیر شروع کننده نیست
1179
00:32:11,919 –> 00:32:13,440
آنچه که من اساساً در اینجا می گویم
1180
00:32:13,440 –> 00:32:15,360
شهود ما واقعاً
1181
00:32:15,360 –> 00:32:16,720
این نیست که واقعاً نباید
1182
00:32:16,720 –> 00:32:18,799
در اطراف ساخته شود، این ساختار خاص است
1183
00:32:18,799 –> 00:32:19,120
1184
00:32:19,120 –> 00:32:21,039
جستجوی روش آهسته است بار آهسته جهانی است
1185
00:32:21,039 –> 00:32:22,559
فراخوانی تابع پایتون
1186
00:32:22,559 –> 00:32:24,720
به اندازه هر یک آهسته است از se
1187
00:32:24,720 –> 00:32:26,320
نوعی ساختار بندی را از دست داده است
1188
00:32:26,320 –> 00:32:27,760
و در غیاب این نوع
1189
00:32:27,760 –> 00:32:29,760
ساختار، چاره ای نداریم جز
1190
00:32:29,760 –> 00:32:31,200
اینکه این کد کند باشد،
1191
00:32:31,200 –> 00:32:32,880
این ما را به حرف بعدی
1192
00:32:32,880 –> 00:32:34,880
s the s برای ساختار می رساند و
1193
00:32:34,880 –> 00:32:36,399
اینجاست که می خواهیم
1194
00:32:36,399 –> 00:32:37,360
1195
00:32:37,360 –> 00:32:39,519
زمانی که در مورد پایتون صحبت می کنیم و در مورد
1196
00:32:39,519 –> 00:32:41,360
ساخت سریع کد پایتون
1197
00:32:41,360 –> 00:32:42,399
صحبت می کنیم، بیشترین توجه خود
1198
00:32:42,399 –> 00:32:44,159
1199
00:32:44,159 –> 00:32:45,519
را صرف
1200
00:32:45,519 –> 00:32:46,480
1201
00:32:46,480 –> 00:32:48,000
می کنیم. از
1202
00:32:48,000 –> 00:32:49,120
ژنراتورهایی که در حال انجام
1203
00:32:49,120 –> 00:32:50,080
نوعی پردازش داده هستند
1204
00:32:50,080 –> 00:32:51,679
و شما بسیار تحت تأثیر قرار نگرفتید که دیدید
1205
00:32:51,679 –> 00:32:52,799
کسی کدی نوشت که در آن
1206
00:32:52,799 –> 00:32:54,159
یک ژنراتور داشت که تعدادی
1207
00:32:54,159 –> 00:32:54,720
اعداد را مربع
1208
00:32:54,720 –> 00:32:56,720
می کرد و آن را روی طیفی از دسته ای از
1209
00:32:56,720 –> 00:32:57,760
اعداد اعمال کردند تا یک لیست بسازند
1210
00:32:57,760 –> 00:32:58,880
و وقتی واقعاً به آن نگاه کردید، گفتید که
1211
00:32:58,880 –> 00:33:01,120
می دانید چه چیزی جالب است،
1212
00:33:01,120 –> 00:33:02,640
ژنراتور به نوعی ساختار جالبی است،
1213
00:33:02,640 –> 00:33:04,799
اما می دانید که من فقط از numpy استفاده می کنم
1214
00:33:04,799 –> 00:33:06,080
و کد کوتاه تر است و خواندن آن بسیار
1215
00:33:06,080 –> 00:33:07,600
آسان تر است
1216
00:33:07,600 –> 00:33:09,760
و اگر عمل کنم معمولاً این را اندازه بگیرید،
1217
00:33:09,760 –> 00:33:11,440
کد numpy بسیار سریعتر است
1218
00:33:11,440 –> 00:33:12,640
و می دانید چه چیزی را من حتی این را اندازه گیری نکردم،
1219
00:33:12,640 –> 00:33:14,000
من فقط کل
1220
00:33:14,000 –> 00:33:15,519
بلوک را بدون تنظیمات اندازه گیری کردم، بنابراین
1221
00:33:15,519 –> 00:33:17,200
کد numpy بسیار سریعتر است
1222
00:33:17,200 –> 00:33:19,039
از جمله ساخت این
1223
00:33:19,039 –> 00:33:21,120
آرایه numpy یک میلیون عنصر
1224
00:33:21,120 –> 00:33:23,279
در موردی از نحو درک
1225
00:33:23,279 –> 00:33:25,519
با یک ژنراتور که شی محدوده
1226
00:33:25,519 –> 00:33:27,679
یک مجموعه مشخص نیست و بنابراین این
1227
00:33:27,679 –> 00:33:29,440
یک مقایسه بسیار ناعادلانه است و حتی در
1228
00:33:29,440 –> 00:33:31,519
مقایسه ناعادلانه کد numpy 200
1229
00:33:31,519 –> 00:33:32,399
برابر سریعتر است
1230
00:33:32,399 –> 00:33:33,519
و بنابراین وقتی به آن نگاه می کنید ممکن است
1231
00:33:33,519 –> 00:33:35,679
بگویید بیایید مانند
1232
00:33:35,679 –> 00:33:37,200
شروع نکن به من در مورد
1233
00:33:37,200 –> 00:33:39,039
ژنراتورها از نظر بهینه سازی بگویم، این
1234
00:33:39,039 –> 00:33:40,799
به وضوح چیزی به کد پایتون من اضافه
1235
00:33:40,799 –> 00:33:41,200
1236
00:33:41,200 –> 00:33:43,039
1237
00:33:43,039 –> 00:33:44,640
1238
00:33:44,640 –> 00:33:45,440
1239
00:33:45,440 –> 00:33:46,880
نمی کند. خواندن در مورد آن سرگرم کننده است،
1240
00:33:46,880 –> 00:33:48,480
اما آنها در واقع
1241
00:33:48,480 –> 00:33:50,159
کاری برای سریعتر کردن کد من انجام نمی دهند،
1242
00:33:50,159 –> 00:33:52,559
اما من استدلال می کنم که شما بسیار
1243
00:33:52,559 –> 00:33:53,360
اشتباه می کنید
1244
00:33:53,360 –> 00:33:54,559
و دلیل اینکه من استدلال می کنم که شما
1245
00:33:54,559 –> 00:33:55,840
بسیار در اشتباه هستید این است که اگر کد شما شبیه به نظر
1246
00:33:55,840 –> 00:33:57,600
باشد اگر شما یک ژنراتور
1247
00:33:57,600 –> 00:33:59,840
دارید یک مربع را اجرا می کنید و سپس
1248
00:33:59,840 –> 00:34:01,840
شکسته می شوید و اجرای عملیات را متوقف می کنید،
1249
00:34:01,840 –> 00:34:03,679
چیزی که باعث کند شدن کد شما می
1250
00:34:03,679 –> 00:34:05,519
شود این است که
1251
00:34:05,519 –> 00:34:07,279
اگر هیچ کاری انجام نداده باشید،
1252
00:34:07,279 –> 00:34:08,960
کد اساساً کند نبوده است.
1253
00:34:08,960 –> 00:34:11,679
این عملیات ناخواسته مشتاق هستند و
1254
00:34:11,679 –> 00:34:12,000
بنابراین
1255
00:34:12,000 –> 00:34:13,440
حتی اگر به تمام
1256
00:34:13,440 –> 00:34:14,879
مقادیری که انجام میشوند نگاه نکنید،
1257
00:34:14,879 –> 00:34:16,800
برای شما بسیار دشوار است که بگویید اوه،
1258
00:34:16,800 –> 00:34:19,040
فقط مقادیر را همانطور که من میخواهم
1259
00:34:19,040 –> 00:34:20,000
انجام دهید و در این مورد خاص،
1260
00:34:20,000 –> 00:34:21,918
این کد تولیدکننده در واقع به
1261
00:34:21,918 –> 00:34:23,599
طور قابل توجهی سریعتر است زیرا هیچ
1262
00:34:23,599 –> 00:34:24,960
کاری انجام نمی دهد
1263
00:34:24,960 –> 00:34:26,399
و اگر در مورد آن فکر کنید ممکن است
1264
00:34:26,399 –> 00:34:28,480
بگویید که بسیار مصنوعی است.
1265
00:34:28,480 –> 00:34:29,760
1266
00:34:29,760 –> 00:34:30,719
1267
00:34:30,719 –> 00:34:31,599
1268
00:34:31,599 –> 00:34:33,440
1269
00:34:33,440 –> 00:34:35,280
شما برای کنترل میزان کار در
1270
00:34:35,280 –> 00:34:35,918
حال انجام
1271
00:34:35,918 –> 00:34:37,679
و اگر بتوانید با دقت بیشتری
1272
00:34:37,679 –> 00:34:39,199
میزان کار انجام شده را کنترل کنید
1273
00:34:39,199 –> 00:34:41,280
تا با کاری که باید انجام شود مطابقت داشته باشد،
1274
00:34:41,280 –> 00:34:43,040
گاهی اوقات می توانید بهینه سازی را پیدا کنید
1275
00:34:43,040 –> 00:34:44,320
زیرا اساساً این طور است
1276
00:34:44,320 –> 00:34:44,719
که
1277
00:34:44,719 –> 00:34:46,639
در اکثر موارد انجام کارهای کمتر
1278
00:34:46,639 –> 00:34:48,239
سریعتر انجام می شود
1279
00:34:48,239 –> 00:34:50,399
که همیشه درست نیست، بنابراین
1280
00:34:50,399 –> 00:34:52,320
خیلی گمراه نشوید زیرا
1281
00:34:52,320 –> 00:34:53,359
مواردی را دیده ایم که در
1282
00:34:53,359 –> 00:34:55,599
نتیجه
1283
00:34:55,599 –> 00:34:57,119
مکانیسم های حدس و گمان پردازنده
1284
00:34:57,119 –> 00:34:59,200
یا عوامل مخدوش کننده مانند
1285
00:34:59,200 –> 00:35:01,040
پیشبینی نادرست شاخه، گاهی اوقات
1286
00:35:01,040 –> 00:35:03,200
انجام کار اضافی سریعتر
1287
00:35:03,200 –> 00:35:05,359
از رمزگذاری یک مدالیته است، به
1288
00:35:05,359 –> 00:35:06,800
عبارت دیگر تقریباً
1289
00:35:06,800 –> 00:35:08,480
مطمئناً موردی با آرایه numpy و d
1290
00:35:08,480 –> 00:35:10,560
دیدهاید که در آن دو عملیات و یک
1291
00:35:10,560 –> 00:35:11,920
شرطی را انجام دادهاید و
1292
00:35:11,920 –> 00:35:13,200
به جای اینکه کدام یک را انتخاب کنید. دو
1293
00:35:13,200 –> 00:35:14,880
عملیاتی که می خواستید با
1294
00:35:14,880 –> 00:35:16,000
نوعی مدالیته انجام دهید، در
1295
00:35:16,000 –> 00:35:17,760
غیر این صورت متوجه شدید که
1296
00:35:17,760 –> 00:35:19,520
انجام هر دوی آنها به طور همزمان سریعتر است و
1297
00:35:19,520 –> 00:35:21,040
سپس فقط یک در صفر
1298
00:35:21,040 –> 00:35:22,160
ضرب کنید و یک در یک ضرب
1299
00:35:22,160 –> 00:35:24,320
کنید و سپس آنها را با هم جمع کنید زیرا
1300
00:35:24,320 –> 00:35:25,680
آنچه می توانید فکر کنید واحدهای اجرای حدس و گمان
1301
00:35:25,680 –> 00:35:26,160
1302
00:35:26,160 –> 00:35:28,480
داخل پردازنده شما می
1303
00:35:28,480 –> 00:35:30,000
توانند هر دوی اینها را به صورت موازی انجام دهند و
1304
00:35:30,000 –> 00:35:31,119
فقط کار را دور بریزید و اگر به
1305
00:35:31,119 –> 00:35:31,680
1306
00:35:31,680 –> 00:35:33,839
specula cpu فکر می کنید در بسیاری از موارد میتوانید فکر کنید
1307
00:35:33,839 –> 00:35:35,280
که دقیقاً
1308
00:35:35,280 –> 00:35:37,520
همین اتفاق میافتد، اغلب سریعتر پیش رفتن و
1309
00:35:37,520 –> 00:35:38,720
انجام دادن کار و دور انداختن آن
1310
00:35:38,720 –> 00:35:40,480
است تا اینکه منتظر بمانید تا بفهمید آیا
1311
00:35:40,480 –> 00:35:42,079
باید آن کار را انجام دهید یا نه، بنابراین این
1312
00:35:42,079 –> 00:35:44,079
ایده برای انجام کار کمتر است. کار لزوماً
1313
00:35:44,079 –> 00:35:45,839
سریعتر یا بهتر از انجام کار بیشتر
1314
00:35:45,839 –> 00:35:47,839
است، کاملاً صحیح نیست، بلکه به چند
1315
00:35:47,839 –> 00:35:49,040
صلاحیت بیشتر
1316
00:35:49,040 –> 00:35:51,839
از آن نیاز دارد، اما در اکثر موارد
1317
00:35:51,839 –> 00:35:53,119
اگر بتوانید میزان کاری
1318
00:35:53,119 –> 00:35:54,000
را که
1319
00:35:54,000 –> 00:35:56,880
در اکثر موارد در مقیاس کلان انجام
1320
00:35:56,880 –> 00:35:58,160
می شود کنترل کنید، احتمالاً خواهید توانست
1321
00:35:58,160 –> 00:35:59,839
نوعی بهینهسازی را ببینید و این همان
1322
00:35:59,839 –> 00:36:01,200
چیزی است که ژنراتورها به شما میدهند و به همین دلیل است که
1323
00:36:01,200 –> 00:36:03,200
ژنراتورها مکانیزم قدرتمندی
1324
00:36:03,200 –> 00:36:05,680
برای بهینهسازی هستند، حتی اگر
1325
00:36:05,680 –> 00:36:06,720
تقریباً مطمئناً
1326
00:36:06,720 –> 00:36:08,240
هرگز از آنها به عنوان یک
1327
00:36:08,240 –> 00:36:09,839
موجودیت محاسباتی در کدهای numpy یا پاندا خود استفاده
1328
00:36:09,839 –> 00:36:11,280
نکردهاید و هرگز نخواهید کرد. از آنها به عنوان یک
1329
00:36:11,280 –> 00:36:12,240
1330
00:36:12,240 –> 00:36:14,079
الگوی محاسباتی به عنوان کد استفاده کنید، چیزی که از
1331
00:36:14,079 –> 00:36:16,079
آنها برای آن استفاده خواهید کرد ساختار برنامه است
1332
00:36:16,079 –> 00:36:19,119
و این مهم ترین بخش است،
133