Уақытты қалай үнемдейді?

Мен C# -де жұмыс істеймін. Дегенмен, ағындардың қандай аспектілері іс жүзінде өнімділікті арттыратынын түсінбеймін.

Бір ғана негізгі процессор бар сценарийді қарастырыңыз. Тапсырмаңызды бірнеше ағынға бөліп, бірдей процесс контекстін (ортақ ресурс) пайдаланады және олар бір уақытта іске қосылады. Жіп тек уақытты бөлісе отырып, олардың жұмыс уақыты (айналым уақытын) қалай пайда болады?

22
Қолданбаңыз процессордан басқа нәрсе күтіп тұруы мүмкін - мысалы, желі арқылы тасымалданатын деректер немесе қатты дискіден файлды жүктеу. Бұл жағдайда, бұл сіздің қосымшада негізгі жіпке тыйым салудың орнына, бұл басқа жіпте болуы мүмкін.
қосылды автор John Sibly, көзі
Қолданбаңыз процессордан басқа нәрсе күтіп тұруы мүмкін - мысалы, желі арқылы тасымалданатын деректер немесе қатты дискіден файлды жүктеу. Бұл жағдайда, бұл сіздің қосымшада негізгі жіпке тыйым салудың орнына, бұл басқа жіпте болуы мүмкін.
қосылды автор John Sibly, көзі
жіптер көп жағдайда жұмыс істейді
қосылды автор Jonesopolis, көзі
«Жіптер уақытты бөлісіп жатқанда, олардың жұмыс уақыты (айналдыру уақыты) бір реттік үрдістен қаншалықты аз болады?». Жөндеу уақыты ұзағырақ . Қосымша ағындардан хабарлаудың күтілуін күтуде (мысалы, синхронды IO жасаған кезде), бірақ басқа да тақырыптар жасау арқылы сіз өзіңіздің OS/жұмыс уақытыңыз үшін қосымша жұмыс жасай бастаған кезде басқа жұмыс ағыны ұйықтап жатқанда жұмыс істеуге мүмкіндік береді.
қосылды автор spender, көзі
«Жіптер уақытты бөлісіп жатқанда, олардың жұмыс уақыты (айналдыру уақыты) бір реттік үрдістен қаншалықты аз болады?». Жөндеу уақыты ұзағырақ . Қосымша ағындардан хабарлаудың күтілуін күтуде (мысалы, синхронды IO жасаған кезде), бірақ басқа да тақырыптар жасау арқылы сіз өзіңіздің OS/жұмыс уақытыңыз үшін қосымша жұмыс жасай бастаған кезде басқа жұмыс ағыны ұйықтап жатқанда жұмыс істеуге мүмкіндік береді.
қосылды автор spender, көзі
Басқа сценарийді жалғыз ядролы процессорда қарастырайық: веб-сайттан үлкен файл жүктеп жатырсыз. Операция біраз уақытты алады және процессорды толығымен пайдаланбайды. Жіп басқа міндеттерді орындау үшін қосалқы процессордың уақытын пайдалануға мүмкіндік береді.
қосылды автор Kevin Gosse, көзі
Басқа сценарийді жалғыз ядролы процессорда қарастырайық: веб-сайттан үлкен файл жүктеп жатырсыз. Операция біраз уақытты алады және процессорды толығымен пайдаланбайды. Жіп басқа міндеттерді орындау үшін қосалқы процессордың уақытын пайдалануға мүмкіндік береді.
қосылды автор Kevin Gosse, көзі
Бұл мәселе сізді қызықтыруы мүмкін: unix.stackexchange.com/questions/80424/…
қосылды автор Eric Lippert, көзі
Осындай ойланып көрейік, егер сіз «X» -ді сынап көрген болсаңыз, оны өзіңіз жасай аласыз ба? Немесе сіз және бірнеше адам мұны істеген болса, әлдеқайда тезірек болар ма еді?
қосылды автор Brian, көзі
Осындай ойланып көрейік, егер сіз «X» -ді сынап көрген болсаңыз, оны өзіңіз жасай аласыз ба? Немесе сіз және бірнеше адам мұны істеген болса, әлдеқайда тезірек болар ма еді?
қосылды автор Brian, көзі
Көптеген сценарийлердің бірі - Клиентке маңызды емес нәрселер, Шақыруды басу үшін растау үшін клиентке хабар жіберу секілді болуы мүмкін. Жай пошта сервисіне жіп жіберіп, клиенттің жауап беруіне мүмкіндік беріңіз. Неге клиент SMTP серверін өңдеуге/жіберуге (басқа I/O) электрондық поштаны күтіп тұруы керек, оны веб-парақпен ойнатыңыз. Single Core үшін де қолданылады.
қосылды автор Sumit Kapadia, көзі

11 жауаптар

Бір негізгі CPU-де сіз артықшылығы асинхронды арқылы өтеді. Ағындарды пайдалану - бұл жетудің бір жолы (бірден-бір жолы емес).

Тамақты дайындау үдерісін елестетіп көріңіз. Сіз неғұрлым тезірек деп ойлайсыз:

  1. Суды қайнатуды бастаңыз. Аяқтауды күтіңіз.
  2. Кей кеспені қосыңыз. Оларды пісіруді аяқтауын күтіңіз.
  3. Кейбір көкөністерді жуу/дайындау.
  4. Көкөністерді қуырыңыз.
  5. Пластина қойыңыз және қызмет етіңіз.

Немесе орнына:

  1. Суды қайнатуды бастау.
  2. Су қайнаған кезде кейбір көкөністерді жуу/дайындау.
  3. Қайнаған кастрюльге кейбір кеспелерді қосыңыз.
  4. кеспе пісірілген кезде көкөністерді қуырыңыз.
  5. Пластина қойыңыз және қызмет етіңіз.

Менің тәжірибемнен екіншісі тезірек.

Жалпы идея мынада, көптеген жағдайларда бағдарламалау кезінде сізде біраз уақыт жұмыс істейтін болады, бірақ ол процессордың жұмысын қажет етпейді. Жалпы мысал - IO. Кейбір ақпаратты алу үшін сұрауды дерекқорға жібергенде, бұл сұрауды қайтаруды күту кезінде басқа нәрселер болу үшін ортақ. Мүмкін сіз бірнеше сұраным жібере аласыз, содан кейін оларды күтіп, күтуді күтіп, содан кейін келесі күтіп, күту және тағы басқаларды күте аласыз (кейде сіз соңғы жасауыңыз керек).

Енді сіз жасаған жұмысыңыз процессормен байланыстырылған жұмыс болса, онда сіз шынымен де синхронды емес, жұмысыңыздың параллельді түрде орындалуы мүмкін процессордың бірнеше ядросы бар болса, онда сіз шын мәнісінде тек артықшылықтарға ие боласыз. Мысалы, графикамен байланысты жұмыс көп (көбейту матрицасы, қарапайым мысал беру үшін) көбінесе негізгі математика лот жасауды қамтиды. Егер сізде бірнеше ядролар бар болса, бұл операциялар жиі өте жақсы деңгейде. Егер сізде бірнеше ядро ​​(немесе өте аз және қарапайым ядралардың лоттары бар тиімді процессор болып табылатын GPU) болса, онда ағындарды пайдалануда көп нәрсе жоқ.

28
қосылды
Мен бұл ағындарды асинхронға жетудің қарапайым тәсілі деп есептеймін (олар салыстырмалы түрде жоғары бағаға қарамастан), себебі олар баламадан (қоңырау шалудан) әлдеқайда қарапайым болады. Бұл айырмашылықты C# 5.0 немесе Go сияқты кішірейтуге тырысатын кейбір тілдер бар.
қосылды автор svick, көзі
@ Servy - Жақсы мысал, егер сіз бір пеш плитасы бар және параллель емес пешке тәуелді тапсырма жасасаңыз сценарийді жақсы түсіндіреді. Сіз бұл мәселені анық түсіндіргенмен, рахмет.
қосылды автор Sumit Kapadia, көзі

Бір негізгі CPU-де сіз артықшылығы асинхронды арқылы өтеді. Ағындарды пайдалану - бұл жетудің бір жолы (бірден-бір жолы емес).

Тамақты дайындау үдерісін елестетіп көріңіз. Сіз неғұрлым тезірек деп ойлайсыз:

  1. Суды қайнатуды бастаңыз. Аяқтауды күтіңіз.
  2. Кей кеспені қосыңыз. Оларды пісіруді аяқтауын күтіңіз.
  3. Кейбір көкөністерді жуу/дайындау.
  4. Көкөністерді қуырыңыз.
  5. Пластина қойыңыз және қызмет етіңіз.

Немесе орнына:

  1. Суды қайнатуды бастау.
  2. Су қайнаған кезде кейбір көкөністерді жуу/дайындау.
  3. Қайнаған кастрюльге кейбір кеспелерді қосыңыз.
  4. кеспе пісірілген кезде көкөністерді қуырыңыз.
  5. Пластина қойыңыз және қызмет етіңіз.

Менің тәжірибемнен екіншісі тезірек.

Жалпы идея мынада, көптеген жағдайларда бағдарламалау кезінде сізде біраз уақыт жұмыс істейтін болады, бірақ ол процессордың жұмысын қажет етпейді. Жалпы мысал - IO. Кейбір ақпаратты алу үшін сұрауды дерекқорға жібергенде, бұл сұрауды қайтаруды күту кезінде басқа нәрселер болу үшін ортақ. Мүмкін сіз бірнеше сұраным жібере аласыз, содан кейін оларды күтіп, күтуді күтіп, содан кейін келесі күтіп, күту және тағы басқаларды күте аласыз (кейде сіз соңғы жасауыңыз керек).

Енді сіз жасаған жұмысыңыз процессормен байланыстырылған жұмыс болса, онда сіз шынымен де синхронды емес, жұмысыңыздың параллельді түрде орындалуы мүмкін процессордың бірнеше ядросы бар болса, онда сіз шын мәнісінде тек артықшылықтарға ие боласыз. Мысалы, графикамен байланысты жұмыс көп (көбейту матрицасы, қарапайым мысал беру үшін) көбінесе негізгі математика лот жасауды қамтиды. Егер сізде бірнеше ядролар бар болса, бұл операциялар жиі өте жақсы деңгейде. Егер сізде бірнеше ядро ​​(немесе өте аз және қарапайым ядралардың лоттары бар тиімді процессор болып табылатын GPU) болса, онда ағындарды пайдалануда көп нәрсе жоқ.

28
қосылды
Мен бұл ағындарды асинхронға жетудің қарапайым тәсілі деп есептеймін (олар салыстырмалы түрде жоғары бағаға қарамастан), себебі олар баламадан (қоңырау шалудан) әлдеқайда қарапайым болады. Бұл айырмашылықты C# 5.0 немесе Go сияқты кішірейтуге тырысатын кейбір тілдер бар.
қосылды автор svick, көзі
@ Servy - Жақсы мысал, егер сіз бір пеш плитасы бар және параллель емес пешке тәуелді тапсырма жасасаңыз сценарийді жақсы түсіндіреді. Сіз бұл мәселені анық түсіндіргенмен, рахмет.
қосылды автор Sumit Kapadia, көзі

Тек бір ядро ​​процессоры бар сценарийді қарастырыңыз. Тапсырмаңызды бірнеше ағынға бөліп, бірдей процесс контекстін (ортақ ресурс) пайдаланады және олар бір уақытта іске қосылады. Жіптер тек уақытты бөлісе отырып, олардың жұмыс уақыты (айналым уақытын) бір реттік үрдістен төменірек қалай болады?

Мұнда кез-келген жылдамдыққа қатысты күмәндану дұрыс.

Ең алдымен, Servy және басқалар жауаптарына назар аударады, егер тапсырмалар процессормен байланысты емес болса, онда процессоры дискіні күтіп тұрғанда, не болмаса желіге қайта оралу үшін, басқа жұмысын жасай алады.

Бірақ, сізде екі процессормен байланысты тапсырмалар, бір процессор және екі ағын немесе бір жіп бар деп қарастырайық. Бір жолақты сценарийде бұл келесідей:

  • Тапсырма жұмысының 100% орындаңыз 1. 1000 мс қабылдайтын болсын
  • Тапсырма жұмысының 100% -ын орындаңыз. 2. 1000 мс қабылдайтын болсын.

Жалпы уақыты: екі секунд. Барлық жұмыс орындары: екі. Тапсырысты күтіп тұрған клиент 1 секунд ішінде жұмысын алды. Жұмыс күтіп отырған клиент екі секунд күтіп тұрды.

Енді бізде екі жіп және бір процессор болса, ол келесідей болады:

  • Тапсырма жұмысының 10% -ын 100 мс-қа дейін орындаңыз.
  • Жұмыс 2 жұмысының 10% -ын, 100 мс-ны жасаңыз.
  • Тапсырма жұмысының 10% -ын орындаңыз
  • Жұмыстың 10% -ын орындаңыз 2 ...

Again, total time two seconds, but this time the client that was waiting for job 1 got their job done in 1.9 seconds, nearly 100% slower than the one-thread scenario!

Мәселен, мұнда әңгіме туралы мораль, бұл сіз дұрыс деп айтуға болады. Егер келесі шарттар орындалса:

  • Тапсырмалар CPU-ке байланысты
  • Процессорларға қарағанда көп жіптер бар
  • Жұмыс тек соңғы нәтиже үшін пайдалы

Содан кейін басқа тақырыптарды қосу тек сізді төмендетеді .

Бұл сценарийге арналған міндеттер параллель кітапханасы сияқты кітапханалар; олар көп ағындарды қосқанда түсінуге тырысады, бұл жағдайды нашарлатады, және олар тек көптеген процестерді жоспарлауға тырысады, себебі оларға қызмет көрсету үшін процессорлар бар.

Енді, егер қандай да бір шарттардың бірі емес болса, онда қосымша тақырыптарды қосу жақсы идея.

  • Егер тапсырмалар CPU байланысы болмаса, онда қосымша ағындарды қосу процессордың жұмысы желіде немесе дискіде күту режимінде болғанда жұмыс істеуге мүмкіндік береді.

  • Егер бос процессорлар болса, қосымша процестерді қосу осы CPU-ді жоспарлауға мүмкіндік береді.

  • Егер ішінара есептелетін нәтижелер пайдалы болса, онда қосымша тақырыптарды қосу жағдайды жақсартады, себебі клиенттерге ішінара есептелген нәтижелерді тұтыну үшін көп мүмкіндіктер бар. Екінші сценарийде, мысалы екеуі де тапсырмалары әрбір 200 миллисекундта, яғни fair ішінара нәтиже алады.

25
қосылды

Тек бір ядро ​​процессоры бар сценарийді қарастырыңыз. Тапсырмаңызды бірнеше ағынға бөліп, бірдей процесс контекстін (ортақ ресурс) пайдаланады және олар бір уақытта іске қосылады. Жіптер тек уақытты бөлісе отырып, олардың жұмыс уақыты (айналым уақытын) бір реттік үрдістен төменірек қалай болады?

Мұнда кез-келген жылдамдыққа қатысты күмәндану дұрыс.

Ең алдымен, Servy және басқалар жауаптарына назар аударады, егер тапсырмалар процессормен байланысты емес болса, онда процессоры дискіні күтіп тұрғанда, не болмаса желіге қайта оралу үшін, басқа жұмысын жасай алады.

Бірақ, сізде екі процессормен байланысты тапсырмалар, бір процессор және екі ағын немесе бір жіп бар деп қарастырайық. Бір жолақты сценарийде бұл келесідей:

  • Тапсырма жұмысының 100% орындаңыз 1. 1000 мс қабылдайтын болсын
  • Тапсырма жұмысының 100% -ын орындаңыз. 2. 1000 мс қабылдайтын болсын.

Жалпы уақыты: екі секунд. Барлық жұмыс орындары: екі. Тапсырысты күтіп тұрған клиент 1 секунд ішінде жұмысын алды. Жұмыс күтіп отырған клиент екі секунд күтіп тұрды.

Енді бізде екі жіп және бір процессор болса, ол келесідей болады:

  • Тапсырма жұмысының 10% -ын 100 мс-қа дейін орындаңыз.
  • Жұмыс 2 жұмысының 10% -ын, 100 мс-ны жасаңыз.
  • Тапсырма жұмысының 10% -ын орындаңыз
  • Жұмыстың 10% -ын орындаңыз 2 ...

Again, total time two seconds, but this time the client that was waiting for job 1 got their job done in 1.9 seconds, nearly 100% slower than the one-thread scenario!

Мәселен, мұнда әңгіме туралы мораль, бұл сіз дұрыс деп айтуға болады. Егер келесі шарттар орындалса:

  • Тапсырмалар CPU-ке байланысты
  • Процессорларға қарағанда көп жіптер бар
  • Жұмыс тек соңғы нәтиже үшін пайдалы

Содан кейін басқа тақырыптарды қосу тек сізді төмендетеді .

Бұл сценарийге арналған міндеттер параллель кітапханасы сияқты кітапханалар; олар көп ағындарды қосқанда түсінуге тырысады, бұл жағдайды нашарлатады, және олар тек көптеген процестерді жоспарлауға тырысады, себебі оларға қызмет көрсету үшін процессорлар бар.

Енді, егер қандай да бір шарттардың бірі емес болса, онда қосымша тақырыптарды қосу жақсы идея.

  • Егер тапсырмалар CPU байланысы болмаса, онда қосымша ағындарды қосу процессордың жұмысы желіде немесе дискіде күту режимінде болғанда жұмыс істеуге мүмкіндік береді.

  • Егер бос процессорлар болса, қосымша процестерді қосу осы CPU-ді жоспарлауға мүмкіндік береді.

  • Егер ішінара есептелетін нәтижелер пайдалы болса, онда қосымша тақырыптарды қосу жағдайды жақсартады, себебі клиенттерге ішінара есептелген нәтижелерді тұтыну үшін көп мүмкіндіктер бар. Екінші сценарийде, мысалы екеуі де тапсырмалары әрбір 200 миллисекундта, яғни fair ішінара нәтиже алады.

25
қосылды

Түсініктемелердің көпшілігі дұрыс, бірақ мен екі центімді де шығарып тастаймын (және бұл жерде пікірлерді келтіріңіз):

Jonesy: "threading is most efficient in multi core environments" -> Yes, but this is a single core cpu...so I'll come back to this.

KooKiz және Джон Сиби: Олар екеуі де I/O туралы айтады. Сіздің құрылғыңыз толығымен қуаттың 100% уақытында шағылыспайды. Уақытты талап ететін басқа да көптеген нәрселер бар, және осы оқиғалар кезінде сіздің процессор үзіліс жасайды.

(Сілтеме: I/O желілік беру, қатты диск/RAM оқуы, SQL сұрауы және т.б. болуы мүмкін. Процессорға жаңа деректерді әкелетін немесе жүктеуден алынған деректерді CPU-дан)

Бұл үзілістер - бұл сіздің CPU-іңіз басқа нәрселерді жасай алатын уақыт. Егер сізде бірыңғай ядро ​​бар болса (біз қазіргі уақытта гипершедирлеуді елемейміз) және бір реттік қосымшаны пайдалансаңыз, ол бақытты болуы мүмкін. Алайда ол үнемі жұмыс істемейді. Процессордың жоспарлауы оны циклге немесе екіге береді, содан кейін басқа нәрсеге ауысыңыз, содан кейін біраз уақыттан кейін сіздің бағдарламаңызға қайта оралыңыз, оған бірнеше циклді беріңіз, қозғаңыз және т. Б. Бұл «ILLUSION» нәрселерді бірден «бір ядролық CPU-да.

Енді, бұл кәдімгі бағдарлама емес, кэшке тікелей құндылықтарды жазатын кейбір ақылсыз кіші бағдарлама емес, бағдарламаңыз RAM-те деректерді сақтайды ... CPU кэшіне қарағанда салыстырмалы түрде баяу сақтау құралы. Осының арқасында жүктеу мәндері уақытты талап етеді.

Осы уақыт ішінде сіздің процессорыңыз ештеңе істемейді. Мұнда тіпті бір ядрода көп ағынды қосымшаларда жылдамдықты көруге болады. Екінші процессор CPU циклдарын толтырады, мұнда CPU басқаша бола бермейді.

2: 1 жылдамдықты көретіндігіңіз екіталай. Егер сіздің 2-шағылысқан бағдарламаңыз жылдамдықты 10-20% арттырса, онда бұл әлдеқайда ықтимал. Есте ұстаңыз, бұл «басқа» (кез келген нүктесінде кез келген нүктеде жұмыс істемейтін I/O) жұмыс істейтін болады, алайда бірінші ағымдық енгізу/шығару функциясы іске қосылғанда ғана шынымен толық қуатпен жұмыс істейтін болады.

Дегенмен, көбінесе WORSE уақытын көре аласыз. Себебі, сіздің процессорыңыз процеңіздегі ағындар арасында ауысуды көп уақытты жұмсау керек (есіңізде болсын, біз бір уақытта тек бір нәрсені іске қосамыз!). Бұл үстеме деп аталады. Екінші жіп ол жасай алатын қарағанда көбірек үстеме болады, сондықтан процесс жалпы баяулайды.

Мультикорлы машинада сізде екі физикалық орындаушы бар ... Екінші жіп жұмыс істеу үшін барлық жаңа ядроды білдіреді. Бұл дегеніміз, орындау уақытына дейін басқа да көптеген нәрселермен бәсекелесудің қажеті жоқ. Сондықтан біз мұнда айтарлықтай жылдамдықты аламыз.

Содан кейін, әрине, сізде кластер бойынша орындалатын көп процестер бар, бірақ біз оны басқа уақытта сақтаймыз.

3
қосылды
Жедел жадты оқып шығуға арналған I/O деп қарастыруға болады ма? Білуімше, оқылымды күту кезінде контекстік қосқышты (HyperThreading қоспағанда) мағынасы жоқ, тезірек жеткілікті, бірақ сіз оны елемегеніңізді айттыңыз.
қосылды автор svick, көзі
@svick: Әдеттегі тұтынушы RAM 7-10 ms-де жұмыс істейді? осы уақыт аралығында көптеген циклдар болуы мүмкін. Мен контекстік ауысудың бар-жоғын білмеймін, бірақ мен де күмәнданатын боламын. askldjd.wordpress.com/2011/02 сілтемесіне сай/20/ұзындығы-бір-кванттық-кванттық , бұл белгілі бір CPU үшін кванттық шамамен 5 мс ... 13 миллион цикл цикл. Осы сандарды ескере отырып, RAM IO деп санайды, себебі айнымалы мәнді алу үшін 2 немесе одан да көп толық кванттардан бас тартуға болады.
қосылды автор Russell Uhl, көзі
@svick: Кешіріңіз, сіз дұрыссыз. Тіпті, сіз 13 мың циклды жоғалтып жатырсыз. Бұл жағдайда, егер ол қолайлы жоғалту деп саналса немесе жоқ екендігін білмесем, сондықтан I/O саналады
қосылды автор Russell Uhl, көзі

Түсініктемелердің көпшілігі дұрыс, бірақ мен екі центімді де шығарып тастаймын (және бұл жерде пікірлерді келтіріңіз):

Jonesy: "threading is most efficient in multi core environments" -> Yes, but this is a single core cpu...so I'll come back to this.

KooKiz және Джон Сиби: Олар екеуі де I/O туралы айтады. Сіздің құрылғыңыз толығымен қуаттың 100% уақытында шағылыспайды. Уақытты талап ететін басқа да көптеген нәрселер бар, және осы оқиғалар кезінде сіздің процессор үзіліс жасайды.

(Сілтеме: I/O желілік беру, қатты диск/RAM оқуы, SQL сұрауы және т.б. болуы мүмкін. Процессорға жаңа деректерді әкелетін немесе жүктеуден алынған деректерді CPU-дан)

Бұл үзілістер - бұл сіздің CPU-іңіз басқа нәрселерді жасай алатын уақыт. Егер сізде бірыңғай ядро ​​бар болса (біз қазіргі уақытта гипершедирлеуді елемейміз) және бір реттік қосымшаны пайдалансаңыз, ол бақытты болуы мүмкін. Алайда ол үнемі жұмыс істемейді. Процессордың жоспарлауы оны циклге немесе екіге береді, содан кейін басқа нәрсеге ауысыңыз, содан кейін біраз уақыттан кейін сіздің бағдарламаңызға қайта оралыңыз, оған бірнеше циклді беріңіз, қозғаңыз және т. Б. Бұл «ILLUSION» нәрселерді бірден «бір ядролық CPU-да.

Енді, бұл кәдімгі бағдарлама емес, кэшке тікелей құндылықтарды жазатын кейбір ақылсыз кіші бағдарлама емес, бағдарламаңыз RAM-те деректерді сақтайды ... CPU кэшіне қарағанда салыстырмалы түрде баяу сақтау құралы. Осының арқасында жүктеу мәндері уақытты талап етеді.

Осы уақыт ішінде сіздің процессорыңыз ештеңе істемейді. Мұнда тіпті бір ядрода көп ағынды қосымшаларда жылдамдықты көруге болады. Екінші процессор CPU циклдарын толтырады, мұнда CPU басқаша бола бермейді.

2: 1 жылдамдықты көретіндігіңіз екіталай. Егер сіздің 2-шағылысқан бағдарламаңыз жылдамдықты 10-20% арттырса, онда бұл әлдеқайда ықтимал. Есте ұстаңыз, бұл «басқа» (кез келген нүктесінде кез келген нүктеде жұмыс істемейтін I/O) жұмыс істейтін болады, алайда бірінші ағымдық енгізу/шығару функциясы іске қосылғанда ғана шынымен толық қуатпен жұмыс істейтін болады.

Дегенмен, көбінесе WORSE уақытын көре аласыз. Себебі, сіздің процессорыңыз процеңіздегі ағындар арасында ауысуды көп уақытты жұмсау керек (есіңізде болсын, біз бір уақытта тек бір нәрсені іске қосамыз!). Бұл үстеме деп аталады. Екінші жіп ол жасай алатын қарағанда көбірек үстеме болады, сондықтан процесс жалпы баяулайды.

Мультикорлы машинада сізде екі физикалық орындаушы бар ... Екінші жіп жұмыс істеу үшін барлық жаңа ядроды білдіреді. Бұл дегеніміз, орындау уақытына дейін басқа да көптеген нәрселермен бәсекелесудің қажеті жоқ. Сондықтан біз мұнда айтарлықтай жылдамдықты аламыз.

Содан кейін, әрине, сізде кластер бойынша орындалатын көп процестер бар, бірақ біз оны басқа уақытта сақтаймыз.

3
қосылды
Жедел жадты оқып шығуға арналған I/O деп қарастыруға болады ма? Білуімше, оқылымды күту кезінде контекстік қосқышты (HyperThreading қоспағанда) мағынасы жоқ, тезірек жеткілікті, бірақ сіз оны елемегеніңізді айттыңыз.
қосылды автор svick, көзі
@svick: Әдеттегі тұтынушы RAM 7-10 ms-де жұмыс істейді? осы уақыт аралығында көптеген циклдар болуы мүмкін. Мен контекстік ауысудың бар-жоғын білмеймін, бірақ мен де күмәнданатын боламын. askldjd.wordpress.com/2011/02 сілтемесіне сай/20/ұзындығы-бір-кванттық-кванттық , бұл белгілі бір CPU үшін кванттық шамамен 5 мс ... 13 миллион цикл цикл. Осы сандарды ескере отырып, RAM IO деп санайды, себебі айнымалы мәнді алу үшін 2 немесе одан да көп толық кванттардан бас тартуға болады.
қосылды автор Russell Uhl, көзі
@svick: Кешіріңіз, сіз дұрыссыз. Тіпті, сіз 13 мың циклды жоғалтып жатырсыз. Бұл жағдайда, егер ол қолайлы жоғалту деп саналса немесе жоқ екендігін білмесем, сондықтан I/O саналады
қосылды автор Russell Uhl, көзі

Есептеу бір мезгілде басқару элементіне бөлінсе, бұл күрделі жөндеу уақыттарын өзгертеді.

1-мысал: оны нашарлататын жіптер

Мысалы, әрқайсысы 10 минутты алатын екі есепті орындағымыз келеді.

Егер біз осы жүйелі түрде (көп мағыналы емес) жоспарласақ, онда 10 минуттан кейін біз бір есептен нәтиже аламыз, ал тағы 10 минут ішінде біз басқа есептен нәтиже аламыз.

Есептеулердің уақытын бөліп алсақ, онда 20 минут күтуге тура келеді, оның өтуі екі кенеттен нәтиже береді.

2-мысал: оны жақсартатын жіптер

Мысалы, біз екі есепті жүзеге асырғымыз келеді делік. Біреуі бір минут, ал қалған 59 минут, бірақ біз оны білмейміз . (Есіңізде болсын, біз кодты түсінбеген жоспарлаушыбыз.)

Егер біз екі тапсырманы бір-бірден іске қоссақ, онда 59 минуттық жұмыс жоспарланған. Сондықтан бір нәтиже үшін 59 минут күтуіміз керек, ал екінші нәтиже үшін тағы бір минут. Негізінен екі нәтиже үшін сағаттық күтім.

Егер біз бақытты болсақ, біз алдымен қысқа жұмыс істей бастаймыз және бірінші нәтижені 1 минутқа, екіншісі 59 минуттан кейін орындаймыз: орташа жөндеу уақыты әлдеқайда жақсы.

Бірақ, біз жіптермен жұмыс жасайтын уақыт аралығын қарастырайық. Содан кейін біз бірінші жұмыс нәтижесін 2 минут, ал екіншісі 58 минуттан кейін аламыз. Бұл екінші сценарий сияқты жақсы, бірақ қандай жұмыс қысқа болады деп болжаудың қажеті жоқ.

Тазаланған процессорларға арналған тапсырмаларды орындау үшін уақытты кесуге уақыт бөлу арқылы үлкен тапсырманы толық көлемде кешіктіретін патологиялық жағдайларды болдырмауға көмектеседі.

2
қосылды

Есептеу бір мезгілде басқару элементіне бөлінсе, бұл күрделі жөндеу уақыттарын өзгертеді.

1-мысал: оны нашарлататын жіптер

Мысалы, әрқайсысы 10 минутты алатын екі есепті орындағымыз келеді.

Егер біз осы жүйелі түрде (көп мағыналы емес) жоспарласақ, онда 10 минуттан кейін біз бір есептен нәтиже аламыз, ал тағы 10 минут ішінде біз басқа есептен нәтиже аламыз.

Есептеулердің уақытын бөліп алсақ, онда 20 минут күтуге тура келеді, оның өтуі екі кенеттен нәтиже береді.

2-мысал: оны жақсартатын жіптер

Мысалы, біз екі есепті жүзеге асырғымыз келеді делік. Біреуі бір минут, ал қалған 59 минут, бірақ біз оны білмейміз . (Есіңізде болсын, біз кодты түсінбеген жоспарлаушыбыз.)

Егер біз екі тапсырманы бір-бірден іске қоссақ, онда 59 минуттық жұмыс жоспарланған. Сондықтан бір нәтиже үшін 59 минут күтуіміз керек, ал екінші нәтиже үшін тағы бір минут. Негізінен екі нәтиже үшін сағаттық күтім.

Егер біз бақытты болсақ, біз алдымен қысқа жұмыс істей бастаймыз және бірінші нәтижені 1 минутқа, екіншісі 59 минуттан кейін орындаймыз: орташа жөндеу уақыты әлдеқайда жақсы.

Бірақ, біз жіптермен жұмыс жасайтын уақыт аралығын қарастырайық. Содан кейін біз бірінші жұмыс нәтижесін 2 минут, ал екіншісі 58 минуттан кейін аламыз. Бұл екінші сценарий сияқты жақсы, бірақ қандай жұмыс қысқа болады деп болжаудың қажеті жоқ.

Тазаланған процессорларға арналған тапсырмаларды орындау үшін уақытты кесуге уақыт бөлу арқылы үлкен тапсырманы толық көлемде кешіктіретін патологиялық жағдайларды болдырмауға көмектеседі.

2
қосылды

Жалғыз ядролы процессордағы бірнеше ағындарды пайдалану жалпы <�процессорлық уақыт деңгейін жақсартпайды. Шындығында, ол контекстті ауыстыру бағасы .

Бірақ процессордың жалпы уақыты - әңгіменің тек жартысы ғана ...

Сұйықтық UI

Сонымен қатар, сұйықтық пайдаланушы интерфейсі үшін өте маңызды асинхронды жетудің бір жолы болып табылады. Мысалы, қымбат процессорға байланысты өңдеуді жасасаңыз және UI-ді бірдей ағынмен өңдесеңіз, сіздің бағдарламаңыз өңдеуді аяқтағанға дейін (пайдаланушы көзқарасынан) уақытша «тоқтатуға» дейін пайда болады. Бірақ, өңдеуді өңдік ағынға бассаңыз, пайдаланушы интерфейсі пайдаланушының енгізуіне жауап беруді және/немесе прогресті пайдаланушыға хабарлауды жалғастыра алады.

Процессорға жатпайтын өңдеу

Бұған қоса, барлық өңдеулер процессорға байланысты емес. Егер файлды оқып, дерекқорға қатынасу немесе веб-қызметке қоңырау шалу сияқты нәрсе жасасаңыз, сыртқы ресурсты күту кезінде ағын бұғатталады (және процессор толығымен азайған). Егер қандай да бір жұмыс істеу керек басқа да ағындар болса, олар алғашқы жіп бұғатталған кезде CPU циклдарын қолдана алады.

TPL

C # жағдайында, сіз Тапсырма параллельді кітапханасын бір мезгілде қолданғыңыз келуі мүмкін (және «асинхронды» үшін ), төмен деңгейлі ағындарды өзіңіз басқаруға тырысыңыз емес. Әдепкі бойынша, Тапсырма s жоспарланады тым көп ағындарға (және контекстік қосқыштарға) қауіп төндірмеуі мүмкін.

Қосымша ақпарат алу үшін Microsoft .NET бірге параллельді бағдарламалау »бөлімін қараңыз.

0
қосылды

Жалғыз ядролы процессордағы бірнеше ағындарды пайдалану жалпы <�процессорлық уақыт деңгейін жақсартпайды. Шындығында, ол контекстті ауыстыру бағасы .

Бірақ процессордың жалпы уақыты - әңгіменің тек жартысы ғана ...

Сұйықтық UI

Сонымен қатар, сұйықтық пайдаланушы интерфейсі үшін өте маңызды асинхронды жетудің бір жолы болып табылады. Мысалы, қымбат процессорға байланысты өңдеуді жасасаңыз және UI-ді бірдей ағынмен өңдесеңіз, сіздің бағдарламаңыз өңдеуді аяқтағанға дейін (пайдаланушы көзқарасынан) уақытша «тоқтатуға» дейін пайда болады. Бірақ, өңдеуді өңдік ағынға бассаңыз, пайдаланушы интерфейсі пайдаланушының енгізуіне жауап беруді және/немесе прогресті пайдаланушыға хабарлауды жалғастыра алады.

Процессорға жатпайтын өңдеу

Бұған қоса, барлық өңдеулер процессорға байланысты емес. Егер файлды оқып, дерекқорға қатынасу немесе веб-қызметке қоңырау шалу сияқты нәрсе жасасаңыз, сыртқы ресурсты күту кезінде ағын бұғатталады (және процессор толығымен азайған). Егер қандай да бір жұмыс істеу керек басқа да ағындар болса, олар алғашқы жіп бұғатталған кезде CPU циклдарын қолдана алады.

TPL

C # жағдайында, сіз Тапсырма параллельді кітапханасын бір мезгілде қолданғыңыз келуі мүмкін (және «асинхронды» үшін ), төмен деңгейлі ағындарды өзіңіз басқаруға тырысыңыз емес. Әдепкі бойынша, Тапсырма s жоспарланады тым көп ағындарға (және контекстік қосқыштарға) қауіп төндірмеуі мүмкін.

Қосымша ақпарат алу үшін Microsoft .NET бірге параллельді бағдарламалау »бөлімін қараңыз.

0
қосылды

Айналдыру процесі шын мәнінде процесті тезірек жасамайды - кейде бірдей процесте бәсекелесу оны төмендетудің орнына қажетті уақытты арттырады. Жақсы бағалау, ең алдымен, сіздің сценарийіңіз мультимедиядан пайда көре ме, жоқ па - бұл.

Ұңғыманың негізгі ерекшелігі қол жетімді ресурстармен көп жағдайда жұмыс істеуге мүмкіндік береді - KooKiz сияқты, бар болған кезде қалған CPU уақытын пайдалану сияқты. Бірақ сіз дұрыссыз, жұмыс жасау уақытын жақсарта алмайтын жағдайлар болуы мүмкін.

Дегенмен, тіпті бірегей ядро ​​жүйелер үшін тіпті, мультиседатикалық мүмкін өнімділікті жақсартатын жағдайлар бар. Бір процент бірдемені күтіп жатқанда, ол кез-келген басқа үрдістерді таңдайды. Күту уақыты қанша уақытқа созылғанына қарай, сіздің жалғыз ядро ​​басқа тәуелсіз процестердің арасында уақытты үнемдеуге дейін ауысуы мүмкін.

0
қосылды