در این مطلب، ویدئو بحث: آنتونی شاو – چرا پایتون کند است؟ با زیرنویس فارسی را برای دانلود قرار داده ام. شما میتوانید با پرداخت 15 هزار تومان ، این ویدیو به علاوه تمامی فیلم های سایت را دانلود کنید.اکثر فیلم های سایت به زبان انگلیسی می باشند. این ویدئو دارای زیرنویس فارسی ترجمه شده توسط هوش مصنوعی می باشد که میتوانید نمونه ای از آن را در قسمت پایانی این مطلب مشاهده کنید.
مدت زمان فیلم: 00:32:52
تصاویر این ویدئو:
قسمتی از زیرنویس این فیلم:
00:00:12,050 –> 00:00:15,000
سلام به همه به PyCon مجازی خوش آمدید
2
00:00:15,000 –> 00:00:17,610
و واقعا هیجان زده هستم که
3
00:00:17,610 –> 00:00:19,290
امروز می توانم این سخنرانی را انجام دهم، این موضوع در مورد اینکه چرا
4
00:00:19,290 –> 00:00:20,850
پایتون کند است،
5
00:00:20,850 –> 00:00:22,920
موضوع کاملاً بحث برانگیزی است و امیدوارم
6
00:00:22,920 –> 00:00:24,240
زمانی که من بیش از حد به برخی از حقایق اینجا گیر کردم
7
00:00:24,240 –> 00:00:26,970
و صرفاً روی
8
00:00:26,970 –> 00:00:28,410
مهندسی و مهندسی تمرکز کنم. علم به جای
9
00:00:28,410 –> 00:00:30,300
نظرات، بنابراین ما قصد داریم
10
00:00:30,300 –> 00:00:31,950
کمی بیشتر در مورد
11
00:00:31,950 –> 00:00:34,739
کامپایلر پایتون و مواردی که احتمالاً
12
00:00:34,739 –> 00:00:36,300
در آینده بهبودهایی در عملکرد وجود
13
00:00:36,300 –> 00:00:36,980
14
00:00:36,980 –> 00:00:39,630
15
00:00:39,630 –> 00:00:41,579
داشته باشد کاوش کنیم.
16
00:00:41,579 –> 00:00:43,440
و همچنین
17
00:00:43,440 –> 00:00:45,900
از سازماندهندگان پایتون بسیار سپاسگزارم که توانستند
18
00:00:45,900 –> 00:00:48,300
این وضعیت دیوانهکنندهای را
19
00:00:48,300 –> 00:00:51,240
که تاکنون در سال 2020 اتفاق افتاده است، بچرخانند، بنابراین
20
00:00:51,240 –> 00:00:53,250
بله، امیدوارم از این کار لذت ببرید و
21
00:00:53,250 –> 00:00:59,420
بیایید وارد آن شویم، بنابراین اگر بگویم پایتون
22
00:00:59,420 –> 00:01:01,860
کند است، باید مقایسه شود. به چیزی و
23
00:01:01,860 –> 00:01:03,420
برای دقیق تر بودن، در مورد Python صحبت خواهم کرد،
24
00:01:03,420 –> 00:01:06,030
منظورم این است که peyten را ببینم،
25
00:01:06,030 –> 00:01:07,770
بنابراین این نسخه پایتون است که
26
00:01:07,770 –> 00:01:10,320
یک Python dorg را دانلود کنید، نسخه ای که
27
00:01:10,320 –> 00:01:12,750
همراه با سیستم عامل مک و برنامهای
28
00:01:12,750 –> 00:01:15,270
که در فروشگاه ویندوز است، بنابراین
29
00:01:15,270 –> 00:01:17,630
اگر به یک بنچمارک فشرده cpu نگاهی بیندازیم،
30
00:01:17,630 –> 00:01:21,299
این برنامه معروف n-body است که
31
00:01:21,299 –> 00:01:23,219
مدارهای مشتری زحل
32
00:01:23,219 –> 00:01:26,909
اورانوس و نپتون را مدلسازی میکند، وظایفی که ما به
33
00:01:26,909 –> 00:01:30,869
طور منظم انجام میدهیم، بنابراین C و C python
34
00:01:30,869 –> 00:01:32,579
از زبانی که به زبان
35
00:01:32,579 –> 00:01:34,710
C
36
00:01:34,710 –> 00:01:37,499
نوشته
37
00:01:37,499 –> 00:01:39,569
38
00:01:39,569 –> 00:01:43,020
39
00:01:43,020 –> 00:01:45,659
شده است
40
00:01:45,659 –> 00:01:48,329
نامگذاری شده است. از عملکرد، بنابراین شاید
41
00:01:48,329 –> 00:01:51,299
منظورم این است که C و C Python واقعاً
42
00:01:51,299 –> 00:01:53,039
مقایسه خوبی نیستند، این قبلاً apples
43
00:01:53,039 –> 00:01:55,469
و orange است C یک زبان کامپایل شده با تایپ قوی
44
00:01:55,469 –> 00:01:57,450
است و Python یک
45
00:01:57,450 –> 00:01:59,609
زبان تفسیری با تایپ پویا است،
46
00:01:59,609 –> 00:02:03,299
اما در مورد nodejs منظورم nodejs
47
00:02:03,299 –> 00:02:05,340
در بالای زبان است. موتور جاوا اسکریپت Google v8
48
00:02:05,340 –> 00:02:07,829
در واقع مقایسه بهتری است
49
00:02:07,829 –> 00:02:10,770
زیرا به صورت پویا نیز تایپ می شود
50
00:02:10,770 –> 00:02:13,740
و همچنین تفسیر می شود، بنابراین چه
51
00:02:13,740 –> 00:02:15,540
چیزی دارد که باعث می شود در محاسبه بسیار سریعتر
52
00:02:15,540 –> 00:02:18,090
از پایتون باشد.
53
00:02:18,090 –> 00:02:21,630
مدار سیارات، بنابراین قبل از اینکه
54
00:02:21,630 –> 00:02:23,670
وارد این موضوع شوم، اجازه دهید فقط مرور کنیم که چگونه
55
00:02:23,670 –> 00:02:25,420
پایتون واقعاً کد اجرا میکند.
56
00:02:25,420 –> 00:02:27,760
57
00:02:27,760 –> 00:02:30,130
58
00:02:30,130 –> 00:02:34,030
59
00:02:34,030 –> 00:02:35,950
60
00:02:35,950 –> 00:02:39,130
درخت نحوی این
61
00:02:39,130 –> 00:02:40,930
نمایش چیزی است که پایتون را به
62
00:02:40,930 –> 00:02:43,030
پایتون تبدیل میکند، درختی است که
63
00:02:43,030 –> 00:02:45,300
64
00:02:45,300 –> 00:02:47,260
هر آنچه را که انتظار دارید در برنامه پایتون ببینید، عملیات دستورات تابع را نشان میدهد،
65
00:02:47,260 –> 00:02:49,630
بنابراین پس از
66
00:02:49,630 –> 00:02:52,209
اتمام کار تجزیه، مفسر دارای
67
00:02:52,209 –> 00:02:54,580
یک ast با توابع عملیات خود
68
00:02:54,580 –> 00:02:57,300
فضای نام کلاسها است. کد پایتون
69
00:02:57,300 –> 00:03:00,100
وظیفه کامپایلر این است
70
00:03:00,100 –> 00:03:03,310
که ast را به دستورالعمل هایی تبدیل کند که CPU
71
00:03:03,310 –> 00:03:05,230
واقعاً می تواند بفهمد شما نمی توانید
72
00:03:05,230 –> 00:03:08,560
به CPU در ast بدهید تا CPU را اجرا کند.
73
00:03:08,560 –> 00:03:10,900
74
00:03:10,900 –> 00:03:13,720
75
00:03:13,720 –> 00:03:16,660
76
00:03:16,660 –> 00:03:18,549
وظیفه در واقع به دو قسمت تقسیم می شود
77
00:03:18,549 –> 00:03:20,880
و یک کامپایلر وجود دارد
78
00:03:20,880 –> 00:03:23,200
که ast را طی می کند زیرا یک درخت است
79
00:03:23,200 –> 00:03:25,209
و ایجاد می کند چیزی به نام
80
00:03:25,209 –> 00:03:27,220
گراف جریان کنترل یا CFG
81
00:03:27,220 –> 00:03:29,350
، نمودار جریان کنترل اساساً
82
00:03:29,350 –> 00:03:31,630
نشاندهنده دنباله منطقی
83
00:03:31,630 –> 00:03:34,239
نحوه اجرای کد است، نه
84
00:03:34,239 –> 00:03:34,989
اینکه کد چیست،
85
00:03:34,989 –> 00:03:36,880
سپس اسمبلر وجود دارد که
86
00:03:36,880 –> 00:03:39,160
اساساً از نمودار جریان کنترل عبور میکند
87
00:03:39,160 –> 00:03:40,959
و سپس آن را به عبارات متوالی تبدیل میکند.
88
00:03:40,959 –> 00:03:43,420
و
89
00:03:43,420 –> 00:03:45,910
به عنوان بایت کد شناخته می شوند این
90
00:03:45,910 –> 00:03:48,190
بایت کد واقعاً سطح
91
00:03:48,190 –> 00:03:50,350
اتمی یک برنامه پایتون است و در
92
00:03:50,350 –> 00:03:53,049
واقع کمتر از آن در یک
93
00:03:53,049 –> 00:03:55,000
حلقه ارزیابی هر یک از دستورالعمل های بایت کد
94
00:03:55,000 –> 00:03:57,670
گرفته می شود و با استفاده از
95
00:03:57,670 –> 00:03:59,109
چیزی به نام قاب پشته اجرا می شود.
96
00:03:59,109 –> 00:04:02,560
قابهای پشتهای سیستم مبتنی بر نوع دادهای هستند که
97
00:04:02,560 –> 00:04:05,500
توسط بسیاری از زمانهای اجرا، نه فقط پایتون، بلکه
98
00:04:05,500 –> 00:04:07,329
فریمهای پشتهای به فراخوانی توابع
99
00:04:07,329 –> 00:04:09,069
و بازگرداندن متغیرها
100
00:04:09,069 –> 00:04:11,769
بین توابع اجازه میدهند، بنابراین فریمهای پشته
101
00:04:11,769 –> 00:04:14,079
حاوی چیزهایی مانند متغیرهای محلی آرگومانها
102
00:04:14,079 –> 00:04:15,970
و سایر اطلاعات حالتدار
103
00:04:15,970 –> 00:04:19,779
و همچنین کدهایی هستند که باید باشند. اجرا شده
104
00:04:19,779 –> 00:04:21,130
و محیطی که آنها در آن زندگی می کنند و
105
00:04:21,130 –> 00:04:22,300
همچنین رشته ای که
106
00:04:22,300 –> 00:04:24,850
قرار است در آن اجرا شوند. یک قاب پشته
107
00:04:24,850 –> 00:04:27,430
برای هر فراخوانی تابع وجود دارد و
108
00:04:27,430 –> 00:04:29,070
آنها انباشته می شوند، به همین دلیل است که آنها را فراخوانی
109
00:04:29,070 –> 00:04:31,450
کردند که به ترتیب به ترتیبی که آنها فراخوانی شده اند انباشته شوند و در
110
00:04:31,450 –> 00:04:33,160
111
00:04:33,160 –> 00:04:35,289
واقع
112
00:04:35,289 –> 00:04:37,390
هر زمان که یک استثنا کنترل نشده داشته باشید، یک فریم گیر
113
00:04:37,390 –> 00:04:38,919
کرده است. stack trace را چاپ
114
00:04:38,919 –> 00:04:40,810
می کند به همین دلیل به آن stack trace می گویند
115
00:04:40,810 –> 00:04:42,310
که از طریق پشته ردیابی می شود و به شما می گوید
116
00:04:42,310 –> 00:04:44,740
که چه فریم هایی در هنگام
117
00:04:44,740 –> 00:04:48,370
رخ دادن خطا اجرا می شوند، بنابراین خواندن تجزیه
118
00:04:48,370 –> 00:04:49,930
و کامپایل کد پایتون
119
00:04:49,930 –> 00:04:52,360
وقت گیر است، کار بسیار زیادی است و به شما
120
00:04:52,360 –> 00:04:54,909
فشار می آورد. CPU بنابراین
121
00:04:54,909 –> 00:04:57,090
کد کامپایل شده در واقع به هر حال در حافظه نهان ذخیره شده است
122
00:04:57,090 –> 00:04:59,080
و این همان چیزی است که در
123
00:04:59,080 –> 00:05:01,720
پوشه کش Thunder PI شما زندگی می کند و هر بار
124
00:05:01,720 –> 00:05:04,240
که کد را دوباره اجرا می کنید اگر کد
125
00:05:04,240 –> 00:05:06,490
تغییر نکرده بود، نسخه کش
126
00:05:06,490 –> 00:05:10,180
خوانده می شود و با استفاده از ماژول مارشال هرگونه
127
00:05:10,180 –> 00:05:12,789
بهینه سازی خوانده می شود. بالاتر از خط، بنابراین
128
00:05:12,789 –> 00:05:14,349
از نظر خواندن مکث و مواردی از این قبیل
129
00:05:14,349 –> 00:05:15,819
، هیچ تفاوتی در
130
00:05:15,819 –> 00:05:17,949
معیار ایجاد نمی کند، زیرا در
131
00:05:17,949 –> 00:05:19,840
واقع تأثیری بر سرعت اجرای کد
132
00:05:19,840 –> 00:05:22,569
ندارد. زیرا کامپایلر C Python
133
00:05:22,569 –> 00:05:25,060
چیزی است که به آن کامپایلر پیش از زمان یا IOT می
134
00:05:25,060 –> 00:05:27,990
گویند، بنابراین وقتی پایتون کد کامپایل شده را اجرا می کند، همه آن از قبل کامپایل می شود و
135
00:05:27,990 –> 00:05:32,050
136
00:05:32,050 –> 00:05:34,780
از آن مانند حلقه ارزیابی فریم مرکزی استفاده
137
00:05:34,780 –> 00:05:37,750
می کند، اگر می خواهید بروید و در فایلی به نام C eval یا C قرار
138
00:05:37,750 –> 00:05:39,419
دارد. نگاهی به آن کمی
139
00:05:39,419 –> 00:05:41,349
طول میکشد تا سرتان را به اطراف بیاندازید،
140
00:05:41,349 –> 00:05:44,380
اما این حلقه اساساً فقط یک
141
00:05:44,380 –> 00:05:46,539
حلقه for بزرگ است و تمام
142
00:05:46,539 –> 00:05:48,729
دستورالعملهای بایت کد را طی میکند و
143
00:05:48,729 –> 00:05:50,500
در داخل آن یک دستور سوئیچ عظیم دارد
144
00:05:50,500 –> 00:05:52,270
و میگوید اگر این بایت کد است انجام دهید، این همان است
145
00:05:52,270 –> 00:05:54,639
بایت کد این کار را انجام می دهد و
146
00:05:54,639 –> 00:05:56,710
مقادیری را از پشته مقادیر می گیرد که
147
00:05:56,710 –> 00:05:58,509
معمولاً متغیر هستند یا ممکن است
148
00:05:58,509 –> 00:06:01,360
چیزهای دیگری وجود داشته باشد و هر
149
00:06:01,360 –> 00:06:03,520
عملیات را در داخل حلقه انجام می دهد و
150
00:06:03,520 –> 00:06:07,690
آنها را ارزیابی می کند اما به دلیل اینکه بسیاری از C
151
00:06:07,690 –> 00:06:10,479
Python بر روی کد C کامپایل شده
152
00:06:10,479 –> 00:06:12,250
است. بسیاری از عملیات بایت کد
153
00:06:12,250 –> 00:06:14,590
در واقع فقط
154
00:06:14,590 –> 00:06:18,219
توابع C کامپایل شده را فراخوانی می کنند، بنابراین ویس
155
00:06:18,219 –> 00:06:22,090
کد C را بسیار سریعتر از C Python
156
00:06:22,090 –> 00:06:24,849
که فقط کد اجباری را به خوبی اجرا می کند، کامپایل کرد،
157
00:06:24,849 –> 00:06:26,319
فکر می کنم سرنخ به نوعی در آن حلقه است.
158
00:06:26,319 –> 00:06:28,870
بنابراین، هر چرخه اگر آن حلقهها رایگان نباشد،
159
00:06:28,870 –> 00:06:31,449
بله، در واقع عملیات ماشینی است،
160
00:06:31,449 –> 00:06:33,099
آنها باید هر یک را
161
00:06:33,099 –> 00:06:35,740
برای هر عملیات بایت کد انجام دهند و هر
162
00:06:35,740 –> 00:06:38,169
چه کار کوتاهتر باشد
163
00:06:38,169 –> 00:06:39,610
، زمان اجرای واقعی
164
00:06:39,610 –> 00:06:42,069
عملیات بایت کد را نشان میدهد و حلقههای بیشتری
165
00:06:42,069 –> 00:06:44,680
وجود دارد.
166
00:06:44,680 –> 00:06:46,509
وقتی به زمان نگاه میکنید
167
00:06:46,509 –> 00:06:48,399
یا در واقع وقتی به
168
00:06:48,399 –> 00:06:50,649
معیار نگاه میکنید اهمیت بیشتری مییابد، بنابراین
169
00:06:50,649 –> 00:06:52,540
وقتی علامت بدنه N
170
00:06:52,540 –> 00:06:55,000
را با C در مقابل cpython مقایسه میکنید،
171
00:06:55,000 –> 00:06:57,610
کاملاً کندتر است زیرا این معیار
172
00:06:57,610 –> 00:07:01,630
از حلقههای بسیار فشرده استفاده میکند و از مقدار زیادی استفاده میکند.
173
00:07:01,630 –> 00:07:03,730
عملیات حسابی بسیار کوچک و
174
00:07:03,730 –> 00:07:05,710
عملیات پیچیده ای نیستند
175
00:07:05,710 –> 00:07:07,330
، مانند این است که این عدد را به این عدد اضافه کنید،
176
00:07:07,330 –> 00:07:11,110
اما آن را مانند میلیون ها بار انجام دهید، بنابراین
177
00:07:11,110 –> 00:07:12,910
مفسر c پایتون اساساً
178
00:07:12,910 –> 00:07:14,410
فقط در یک حلقه بارها و بارها
179
00:07:14,410 –> 00:07:17,050
و بارها می چرخد و هزینه های زیادی را صرف کرده است. زم
180
00:07:17,050 –> 00:07:19,270
صرفاً در حلقه دور میشود تا
181
00:07:19,270 –> 00:07:24,040
به کد بایت بعدی برسیم، بنابراین اگر سی پایتون
182
00:07:24,040 –> 00:07:25,720
بداند که قرار است یک حلقه محکم اجرا
183
00:07:25,720 –> 00:07:27,340
کند، شرلی میتواند آن را وصل کند. در برخی از
184
00:07:27,340 –> 00:07:30,070
میانبرها یا چیزی شبیه به این است که به
185
00:07:30,070 –> 00:07:32,800
نوعی کوتاه است چرا حلقه و برای
186
00:07:32,800 –> 00:07:34,690
درک اینکه ما
187
00:07:34,690 –> 00:07:36,160
واقعاً باید به کامپایلر و نحوه
188
00:07:36,160 –> 00:07:37,930
کارکرد کامپایلر نگاه کنیم، بنابراین دو
189
00:07:37,930 –> 00:07:40,210
نوع کامپایلر وجود دارد که یک کامپایلر زودتر از
190
00:07:40,210 –> 00:07:42,970
موعد وجود دارد مانند c python یا وجود دارد.
191
00:07:42,970 –> 00:07:46,090
یک کامپایلر به موقع یا یک کامپایلر JIT JIT
192
00:07:46,090 –> 00:07:47,320
بسیار متفاوت است، زیرا
193
00:07:47,320 –> 00:07:49,090
آنها به موقع کامپایل می کنند، آنها
194
00:07:49,090 –> 00:07:51,370
کد را به موقع ارسال نمی کنند،
195
00:07:51,370 –> 00:07:53,920
آنها معمولاً کد را زودتر از موعد ارسال می کنند
196
00:07:53,920 –> 00:07:56,020
و سپس مقداری می آمدند.
197
00:07:56,020 –> 00:07:58,510
نوعی نمایش میانی
198
00:07:58,510 –> 00:08:01,030
بین تجزیه کننده و کامپایلر، بنابراین
199
00:08:01,030 –> 00:08:02,680
این یک سطح پایین تر است، این یک درخت نحو انتزاعی نیست، بلکه یک
200
00:08:02,680 –> 00:08:04,270
201
00:08:04,270 –> 00:08:07,150
سطح پایین تر از آن است و این در مرحله قبل از کامپایلر اتفاق می افتد،
202
00:08:07,150 –> 00:08:09,940
اساساً آنقدر
203
00:08:09,940 –> 00:08:12,370
مشخص نیست، یک شی کد کامپایل شده است.
204
00:08:12,370 –> 00:08:14,950
مانند Python و اما سطح آن بسیار پایین
205
00:08:14,950 –> 00:08:17,710
تر از درخت نحو انتزاعی است، بنابراین
206
00:08:17,710 –> 00:08:19,420
یکی از مزایای بزرگ
207
00:08:19,420 –> 00:08:22,570
کامپایلر JIT این است که در
208
00:08:22,570 –> 00:08:25,990
حل مشکل حلقه تنگ واقعا خوب است pi
209
00:08:25,990 –> 00:08:28,870
PI یک مثال خوب است pi PI یک
210
00:08:28,870 –> 00:08:31,990
جایگزین است. مفسر ive Python شما می توانید
211
00:08:31,990 –> 00:08:33,820
از آن برای اجرای کد پایتون موجود خود استفاده کنید،
212
00:08:33,820 –> 00:08:36,789
آن منبع باز است و
213
00:08:36,789 –> 00:08:40,479
پایتون 3.6 را در متن می فهمد، همچنین برخلاف C Python،
214
00:08:40,479 –> 00:08:44,169
pi PI در پایتون نوشته شده است، بنابراین
215
00:08:44,169 –> 00:08:46,810
کامپایلرهای C Python برای دیدن کامپایلرهای pi
216
00:08:46,810 –> 00:08:49,390
PI نوشته شده در پایتون در واقع نوشته شده
217
00:08:49,390 –> 00:08:51,220
اند. سوراخ pi PI در پایتون نوشته شده است،
218
00:08:51,220 –> 00:08:54,100
بنابراین اگر عبارت اصلی من درست بود و
219
00:08:54,100 –> 00:08:57,010
پایتون کند است، یک کامپایلر
220
00:08:57,010 –> 00:09:00,310
و مفسر پایتون که در پایتون نوشته شده است
221
00:09:00,310 –> 00:09:03,100
باید مثل خیلی کند باشد، درست
222
00:09:03,100 –> 00:09:05,500
در واقع نه، این
223
00:09:05,500 –> 00:09:08,110
برای الگوریتم بدنه n نیست، پی PI در
224
00:09:08,110 –> 00:09:09,580
واقع شش است. صد و پنجاه درصد
225
00:09:09,580 –> 00:09:13,090
سریعتر از پایتون C من گفتم من
226
00:09:13,090 –> 00:09:15,940
فقط یک مکث می کنم تا در آن غوطه ور شود،
227
00:09:15,940 –> 00:09:18,100
چند دلیل برای این وجود دارد، اما همه آنها
228
00:09:18,100 –> 00:09:21,580
به بهینه سازی مربوط می شوند، مشکلی که ما
229
00:09:21,580 –> 00:09:23,080
به آن نگاه کردیم مشکل حلقه تنگ بود
230
00:09:23,080 –> 00:09:25,990
و به دلیل استفاده از pi PI یک
231
00:09:25,990 –> 00:09:28,330
جت قادر است اساساً
232
00:09:28,330 –> 00:09:30,280
الگوریتم و جریان داده را ارزیابی کند و در
233
00:09:30,280 –> 00:09:31,600
مورد نحوه اجرای آن تصمیم گیری
234
00:09:31,600 –> 00:09:33,760
کند، می تواند ساختار اجرا
235
00:09:33,760 –> 00:09:36,580
را دقیقاً به موقع تغییر دهد نه
236
00:09:36,580 –> 00:09:39,340
اینکه همه چیز را داشته باشد. از قبل خاتمه
237
00:09:39,340 –> 00:09:41,740
یافته، ساختار اجرا به
238
00:09:41,740 –> 00:09:44,470
مجموعه مشکلاتی که داده شده است بهینه شده است، بنابراین جت
239
00:09:44,470 –> 00:09:46,810
ها در تکرار و حلقه ها واقعاً مؤثر هستند،
240
00:09:46,810 –> 00:09:49,210
بنابراین اگر بتوانند مجموعه مشکل را ارزیابی کنند
241
00:09:49,210 –> 00:09:50,620
و بگویند آه، اینجا تکرار زیادی است،
242
00:09:50,620 –> 00:09:52,840
اینها به عنوان نقاط داغ شناخته می شوند
243
00:09:52,840 –> 00:09:55,390
و کاری که کامپایلرهای JIT می توانند انجام دهند این است
244
00:09:55,390 –> 00:09:56,830
که می توانند بگویند که قطعه کد قرار است
245
00:09:56,830 –> 00:09:58,720
به مقدار زیادی اجرا شود، بنابراین
246
00:09:58,720 –> 00:10:01,450
من آن را واقعاً کارآمد می کنم و
247
00:10:01,450 –> 00:10:03,070
سرباری دارد که در
248
00:10:03,070 –> 00:10:05,650
مورد آن صحبت خواهیم کرد و کامپایلرهای JIT می
249
00:10:05,650 –> 00:10:07,750
توانند نحوه کامپایل کردن کد را تغییر دهند و می
250
00:10:07,750 –> 00:10:09,820
توانند عبارت درون خطی را تغییر دهند، بنابراین اساساً
251
00:10:09,820 –> 00:10:11,530
آنها را به هم له می کنند تا به جای
252
00:10:11,530 –> 00:10:12,640
دور زدن حلقه، در واقع
253
00:10:12,640 –> 00:10:15,400
همه چیز را در یک دنباله چسباند که می توانید
254
00:10:15,400 –> 00:10:17,710
با C Python تصور کنید اگر این ویژگی را داشته باشد،
255
00:10:17,710 –> 00:10:20,440
مثلاً سرعت آن چقدر است. این
256
00:10:20,440 –> 00:10:23,230
مشکل خاص pi PI تنها
257
00:10:23,230 –> 00:10:25,810
پایتون G نیست که در واقع شماره وجود دارد،
258
00:10:25,810 –> 00:10:28,030
یک کامپایلر JIT دیگر است که به طور خاص
259
00:10:28,030 –> 00:10:30,850
برای استفاده ناخواسته هدف قرار گرفته است، شما
260
00:10:30,850 –> 00:10:33,040
می توانید با وارد کردن یک
261
00:10:33,040 –> 00:10:35,350
تزئین کننده JIT و بسته بندی یک تابع از شماره استفاده کنید.
262
00:10:35,350 –> 00:10:37,300
با آن دکوراتور اگر در حال انجام
263
00:10:37,300 –> 00:10:39,370
حلقه های محکم یا هر نوع اعداد خردکن تکراری هستید،
264
00:10:39,370 –> 00:10:41,530
در واقع یک
265
00:10:41,530 –> 00:10:43,930
جایگزین واقعا عالی برای C Python است،
266
00:10:43,930 –> 00:10:46,660
در واقع از آن با C Python استفاده کنید، بنابراین
267
00:10:46,660 –> 00:10:49,870
بیشتر این است که جت را بپیچید و
268
00:10:49,870 –> 00:10:51,670
بخش های خاصی از مجموعه مشکل خود
269
00:10:51,670 –> 00:10:53,890
را انتخاب کنید. با استفاده از اعداد بهینه
270
00:10:53,890 –> 00:10:56,140
شوید، مخصوصاً اگر از تعداد زیادی
271
00:10:56,140 –> 00:11:00,640
numpy استفاده می کنید، بنابراین این تنها راه
272
00:11:00,640 –> 00:11:02,440
حل برای حذف سربار
273
00:11:02,440 –> 00:11:04,960
در حلقه ارزیابی نیست، زمانی که c python
274
00:11:04,960 –> 00:11:07,660
توابعی را اجرا می کند که در پسوندهای c کامپایل شده هستند،
275
00:11:07,660 –> 00:11:10,000
بنابراین این یکی از
276
00:11:10,000 –> 00:11:12,070
مزایای بزرگ c python این است که
277
00:11:12,070 –> 00:11:15,640
با کد C کامپایل شده واقعاً به خوبی کار می
278
00:11:15,640 –> 00:11:16,180
کند
279
00:11:16,180 –> 00:11:18,670
، بایت کد یک عملیات واحد است، بنابراین اگر می
280
00:11:18,670 –> 00:11:19,270
خواهید یک
281
00:11:19,270 –> 00:11:22,210
تابع c را که یک کد تک بایتی است فراخوانی کنید،
282
00:11:22,210 –> 00:11:24,640
تمام حلقه تنگ می تواند در
283
00:11:24,640 –> 00:11:27,130
سمت راست در این نمودار اتفاق بیفتد. یک
284
00:11:27,130 –> 00:11:29,590
باینری C کامپایل شده اما واقعاً به سؤال اصلی پاسخ نمی دهد
285
00:11:29,590 –> 00:11:32,320
که چرا پایتون
286
00:11:32,320 –> 00:11:34,000
کند است، در واقع فقط می گوید اگر
287
00:11:34,000 –> 00:11:35,830
همه آن را به کامپایل تابع C منتقل کنیم،
288
00:11:35,830 –> 00:11:37,660
پایتون سریعتر است، اما شما اساساً این کار را انجام داده اید.
289
00:11:37,660 –> 00:11:39,520
مشکل را با استفاده از C و نه Python حل کرد،
290
00:11:39,520 –> 00:11:40,180
291
00:11:40,180 –> 00:11:45,130
بنابراین اگر تراشهها واقعا سریع هستند،
292
00:11:45,130 –> 00:11:46,780
همه کامپایلرها را روی معیاری که
293
00:11:46,780 –> 00:11:48,160
قبلا نشان دادیم انجام دهید، همه آنها باید JIT داشته باشند،
294
00:11:48,160 –> 00:11:54,160
خوب دوباره خیر، بنابراین یک کامپایلر دیگر وجود دارد،
295
00:11:54,160 –> 00:11:58,060
بنابراین Russ C C++
296
00:11:58,060 –> 00:11:59,800
همگی زبانهایی با تایپ قوی هستند و
297
00:11:59,800 –> 00:12:01,530
تخصیص حافظه ثابت یا
298
00:12:01,530 –> 00:12:05,500
پویا یا خودکار خواهند داشت و
299
00:12:05,500 –> 00:12:08,920
به روشی متفاوت عمل میکنند که پایتون یا
300
00:12:08,920 –> 00:12:11,620
حتی یک گره یا جاوا یا C شارپ
301
00:12:11,620 –> 00:12:13,750
حافظه را تخصیص میدهد و با اشیاء کار میکند، بنابراین
302
00:12:13,750 –> 00:12:15,400
واقعاً گچ و پنیر است برای مقایسه زنگزدگی
303
00:12:15,400 –> 00:12:18,700
یا C یا C++ با Python یک
304
00:12:18,700 –> 00:12:21,400
مقایسه منصفانه در واقع بدون js نیست، بنابراین هیچ
305
00:12:21,400 –> 00:12:23,970
TAS زمان اجرای جاوا اسکریپت سمت سرور
306
00:12:23,970 –> 00:12:27,280
نیست، اما در موتور
307
00:12:27,280 –> 00:12:29,290
کرومیوم v8 موتور کروم v8 موتور جاوا اسکریپت
308
00:12:29,290 –> 00:12:30,370
است که در مرورگر کروم
309
00:12:30,370 –> 00:12:33,100
قرار دارد و همچنین برای تامین انرژی مورد استفاده قرار می گیرد. بسیاری از
310
00:12:33,100 –> 00:12:35,940
چیزهای دیگر از جمله برنامههای الکترونهای AS
311
00:12:35,940 –> 00:12:37,780
که احتمالاً روی دسکتاپ خود دارید،
312
00:12:37,780 –> 00:12:39,700
منظورم این است که اگر مثال خوبی از آن باشد، شلی است
313
00:12:39,700 –> 00:12:42,610
و اما میتوانید آن را
314
00:12:42,610 –> 00:12:43,840
در گرههای بنچمارک ببینید که واقعاً به
315
00:12:43,840 –> 00:12:46,290
شدت فایده دارند. از پایتون بهتر است، بنابراین
316
00:12:46,290 –> 00:12:48,580
جاوا اسکریپت
317
00:12:48,580 –> 00:12:50,190
از نظر زبان و
318
00:12:50,190 –> 00:12:54,130
تایپ پویا شباهت بیشتری به پایتون دارد، اما قبلاً
319
00:12:54,130 –> 00:12:57,280
اشاره کردم که چگونه کامپایلرهای JIT از یک
320
00:12:57,280 –> 00:13:00,100
نمایش میانی به عنوان پایتون C استفاده
321
00:13:00,100 –> 00:13:02,020
می کنند، همچنین یک نمایش میانی دارد
322
00:13:02,020 –> 00:13:05,290
که نمودار
323
00:13:05,290 –> 00:13:07,750
بلوک های فریم اصلی است. کد پایتون شما
324
00:13:07,750 –> 00:13:10,390
کامپایل شده است، دنباله اجرا
325
00:13:10,390 –> 00:13:12,940
در کامپایلر تعیین میشود که بلوکهای فریم را
326
00:13:12,940 –> 00:13:14,860
در یک گراف جریان کنترلی منتشر میکند که قبلاً
327
00:13:14,860 –> 00:13:16,930
در مورد آن صحبت کردم، بنابراین اگر حلقه for ساده را در نظر
328
00:13:16,930 –> 00:13:19,540
بگیریم که بخشهای زیادی دارد،
329
00:13:19,540 –> 00:13:21,340
بنابراین به همان اندازه بلوکهای فریم به پایان میرسد
330
00:13:21,340 –> 00:13:23,560
نه فقط یکی برای کل دستور حلقه for
331
00:13:23,560 –> 00:13:25,720
زیرا در داخل حلقه
332
00:13:25,720 –> 00:13:26,950
می توانید یک بلوک داشته باشید که می تواند باعث
333
00:13:26,950 –> 00:13:28,450
ایجاد کد دیگری شود که می تواند
334
00:13:28,450 –> 00:13:30,820
تمام فریم را فراخوانی کند و همچنین می توانید
335
00:13:30,820 –> 00:13:32,680
عبارات دیگری را در حلقه های for داشته باشید
336
00:13:32,680 –> 00:13:34,750
که من هرگز کاملاً متوجه نشدم چرا اما
337
00:13:34,750 –> 00:13:37,450
می توانید این کار را انجام دهید و بنابراین یک نمودار جریان کنترل
338
00:13:37,450 –> 00:13:39,250
در واقع برای یک حلقه for میتواند
339
00:13:39,250 –> 00:13:41,800
بسیار پیچیده باشد، اما سفت و سخت است،
340
00:13:41,800 –> 00:13:43,510
زیرا میگوید این نحوه اجرای کد است
341
00:13:43,510 –> 00:13:46,420
و همه موارد این کد به اسمبلر فرستاده می شود
342
00:13:46,420 –> 00:13:48,100
و سپس
343
00:13:48,100 –> 00:13:50,320
کد بایت متوالی را می ریزد، اگر می توانید
344
00:13:50,320 –> 00:13:52,350
به JIT که بعداً کامپایل می
345
00:13:52,350 –> 00:13:55,209
شود اعتماد کنید، برخی از نمایش های میانی
346
00:13:55,209 –> 00:13:57,130
که jits استفاده می کنند در واقع از
347
00:13:57,130 –> 00:13:59,440
نظر مسیر اجرا بسیار انعطاف پذیرتر هستند،
348
00:13:59,440 –> 00:14:03,100
بنابراین کد همانطور که انتظار
349
00:14:03,100 –> 00:14:04,420
دارید اجرا شود و این نکته مهمی
350
00:14:04,420 –> 00:14:06,040
نیست که به طور شگفت انگیزی در یک شاخه دیگر خاموش نمی شود،
351
00:14:06,040 –> 00:14:08,770
بلکه بیشتر به نحوه
352
00:14:08,770 –> 00:14:11,800
نگاه کامپایلر به بلوک های
353
00:14:11,800 –> 00:14:13,899
کد یا عبارات عملیات
354
00:14:13,899 –> 00:14:15,459
و همچنین مقادیری است که تشکیل می دهند.
355
00:14:15,459 –> 00:14:18,010
کد و نحوه طراحی آن تصمیم میگیرد که
356
00:14:18,010 –> 00:14:20,110
واقعاً آنها را به cpu بفرستد تا
357
00:14:20,110 –> 00:14:22,810
اجرا شوند، این در واقع برای
358
00:14:22,810 –> 00:14:24,640
اطمینان از استفاده از cpu به
359
00:14:24,640 –> 00:14:27,640
کارآمدترین روش ممکن است، بنابراین یک
360
00:14:27,640 –> 00:14:30,279
ویژگی نمایش میانی
361
00:14:30,279 –> 00:14:33,220
تخصیص واحد ثابت نامیده میشود، بنابراین
362
00:14:33,220 –> 00:14:36,520
اگر به v8 نگاه کنید. بهینهساز JIT، بنابراین
363
00:14:36,520 –> 00:14:39,430
این کامپایلر بهینهسازی نسخه 8 است
364
00:14:39,430 –> 00:14:42,100
که توربوفن نامیده میشود و کارهای بسیار
365
00:14:42,100 –> 00:14:44,440
جالبی را با
366
00:14:44,440 –> 00:14:46,690
نمایش متوسط تک انتساب استاتیک انجام میدهد، بن
367
00:14:46,690 –> 00:14:50,290
براین همه مقادیر و عملیات بنابراین در یک
368
00:14:50,290 –> 00:14:51,670
معادل پایتون که به این صورت است که شما
369
00:14:51,670 –> 00:14:54,339
همه متغیرها و همه عملیات یا تمام
370
00:14:54,339 –> 00:14:56,589
بخشهای یک دستور را میدانید، همه آن چیزها
371
00:14:56,589 –> 00:14:58,740
به گرههایی در این گراف عظیم تبدیل میشوند و
372
00:14:58,740 –> 00:15:00,970
پایتونها به نوعی چیزی مشابه با
373
00:15:00,970 –> 00:15:02,950
AST دارند، اما زمانی که واقعاً به
374
00:15:02,950 –> 00:15:04,480
اجرای آن میرسد. همه در
375
00:15:04,480 –> 00:15:07,000
بایت کد متوالی هستند و ما در واقع اگر
376
00:15:07,000 –> 00:15:09,070
آن را با گره مقایسه کنید، اساساً همه آن چیزها
377
00:15:09,070 –> 00:15:12,880
به اندازه کافی عجیب در یک گراف عظیم تبدیل به گره می شوند
378
00:15:12,880 –> 00:15:15,640
و نمودار بر
379
00:15:15,640 –> 00:15:17,529
حسب مانند اینجا تمام یال های روی
380
00:15:17,529 –> 00:15:18,930
نمودار تعیین نمی شود و در اینجا نحوه
381
00:15:18,930 –> 00:15:21,220
اجرای آن است. گراف در واقع
382
00:15:21,220 –> 00:15:24,160
از نظر وابستگی ها و جریان داده تعیین می شود،
383
00:15:24,160 –> 00:15:26,589
بنابراین کامپایلرها آن را بهینه کرده اند، در
384
00:15:26,589 –> 00:15:28,630
واقع در مورد کد داغ و کد مرده تصمیم می گیرند
385
00:15:28,630 –> 00:15:31,630
و لبه هایی را در نمودار ترسیم می کنند تا
386
00:15:31,630 –> 00:15:33,899
نحوه اجرای کاری
387
00:15:33,899 –> 00:15:37,540
را با یافتن کد مرده و
388
00:15:37,540 –> 00:15:38,709
اطمینان از اینکه
389
00:15:38,709 –> 00:15:41,650
برنامه ریزی نمی شود یا ایجاد یا یافتن کد داغ
390
00:15:41,650 –> 00:15:43,209
و اطمینان از اینکه آن به درستی برنامه ریزی می شود،
391
00:15:43,209 –> 00:15:45,310
می توانید
392
00:15:45,310 –> 00:15:46,000
بازدهی عظیمی داشته باشید،
393
00:15:46,000 –> 00:15:48,709
بنابراین این یکی از دلایل است چرا در آن
394
00:15:48,709 –> 00:15:51,110
گره بنچمارک بسیار سریعتر بود، حتی
395
00:15:51,110 –> 00:15:53,510
اگر پویا باشد، به این دلیل است که
396
00:15:53,510 –> 00:15:55,700
کامپایلر JIT می تواند
397
00:15:55,700 –> 00:15:57,230
در مورد روشی که اساساً
398
00:15:57,230 –> 00:15:58,820
بخش های خاصی از برنامه شما را بهینه می کند بسیار هوشمند
399
00:15:58,820 –> 00:16:02,029
باشد، بنابراین v8 تنها JIT نیست که
400
00:16:02,029 –> 00:16:05,570
از SSA مدرن ترین استفاده می کند. جت ها از SSA نیز استفاده می کنند،
401
00:16:05,570 –> 00:16:08,360
از جمله pi PI و اعداد جت نیز
402
00:16:08,360 –> 00:16:10,490
از آنها به عنوان یک نمایش ذخیره استفاده می کند،
403
00:16:10,490 –> 00:16:13