Деградирането на софтуера
Автор на този материал е програмистът Джеф Гриър (Geoff Greer) от Оукланд, написал редица приложения, доста от които се намират в неговото вместилище в GitHub.Деградирането на софтуера
В книгата „Електронната ера: работата, любовта и животът, когато роботите ръководят света“ Робърт Хансън малко се стопира на деградирането на софтуера“
„Програмното обезпечаване в началото е основано за избран кръг задания, принадлежности и обстановки. Но то постепенно се трансформира, с цел да може да се оправи с новия поток от задания, принадлежности и задания. Софтуерът от този вид става комплициран, нежен и в него става все по-трудно да се вършат потребни промени. В края на краищата, по-добре е всичко да се стартира изначало и от нулата да се напишат всички подсистеми, а от време на време е по-добре и да се основат напълно нов вид подсистеми“.
Сигурен съм, че това е истина и нещата стоят тъкмо по този начин. Като предписание, грамотната акомодация на софтуера към зародилите нови условия заема повече време и старания, в сравнение с написването на ново програмно обезпечаване от нулата. Програмистите не обичат да признават това, само че доказателствата са явни. В open source плановете има няколко доста известни образеца.
Многопроцесният Firefox
В началото Mozilla Firefox стартираше всичко в един единствен развой. Но след излизането на Гугъл Chrome стана ясно, че моделът с няколко процеса покачва осведомителната сигурност и продуктивността. Веднага по-късно разработчиците на Mozilla започнаха да възнамеряват реализирането на многопроцесна работа в браузъра Firefox. Това се случи през 2007 година.
След към 10 години Mozilla най-сетне показа многопроцесен Firefox за всеобщата публика. Това закъснение бе не заради липса на предпочитание или нещо друго. Mozilla разполага с надарени и способни разработчици и програмисти. Но все пак, Chrome бе написан безусловно от нулата за надалеч по-малко време, в сравнение с бе нужно на Firefox да реализира плануваните промени. Причините за това в съществени линии са две:
Преобразуването на еднопроцесната архитектура в многопроцесна изисква огромен брой дребни промени. Някои извиквания на функционалности би трябвало да бъдат сменени с междупроцесни връзки. Общото положение би трябвало да бъде пронизано от мютекси. Кешовете и локалните бази данни би трябвало да поддържат успореден достъпFirefox би трябвало да резервира съвместимостта със съществуващите разширения (или разработчиците ще би трябвало да ги обновят). Гугъл сътвори API за Chrome от нулата, без да има терзания от сходен жанр
Но обстановката в действителност е още по-зле. Ограниченията си опонират едно на друго: належащо е да бъде престроена вътрешната архитектура, само че общодостъпните API би трябвало да останат без промени. Не е за удивление, че Mozilla имаше потребност от цели 10 години, с цел да извърши този героизъм.
Събитийно-ориентираният Apache
Първоначално Apache httpd работеше по модела „един поток на една сесия“. Един и същ развой слуша порт 80, по-късно прави accept() и fork(). След това един дъщерен развой извършва read() и write() в границите на сесията. Когато поръчката завърши, дъщерният развой затваря сесията с close() и се излиза с exit().
Тази архитектура е опростена и лесна за осъществяване на всички платформи. И това е всичко. Тя е безусловно ужасна за продуктивността, изключително при дълготрайни свързвания с дълги сесии. Но въпреки всичко това бе през 1995 година. Малко по-късно Apache мина към многонишков модел, който усъвършенства продуктивността. Въпреки това, той не може да обработва 10 000 едновременни връзки. Архитектурата „един поток на една връзка“ изисква 1000 потока за обслужването на 1000 връзки. А всеки поток си има личен стек и положение, той би трябвало да е плануван и стартиран от операционната система. А това лишава време.
Точно противоположното, Nginx още през цялото време употребява Шаблона на реактора. Това му дава опция още през цялото време да обработва повече едновременни връзки и да го направи нестабилен към Slowloris офанзивите.
Nginx излезе през 2007 година и неговите прерогативи и продуктивност бяха явни. Няколко години преди излизането на Nginx разработчиците на Apache започнаха да преправят httpd за повишение на продуктивността. Многопроцесният модул event се появи през 2005 година във версия Apache 2.2. Но се оказа, че има проблеми със съвместимостта. И най-лошото бе, че той провали съвместимостта с най-популярните модули, като да вземем за пример mod_php. Програмистите не можаха да се оправят с този проблем до 2012 година, когато излезе Apache 2.4, включващ този модул (MPM) по дифолт. Въпреки че всичко работеше доста по-добре, спрямо предходните prefork и MPM, полученото изобщо не можеше да се съпостави с продуктивността на Nginx. Вместо шаблона на реактора, Apache употребява обособени пулове от потоци, с цел да слуша и приема съединенията и да обработва поръчките. Не се получи чак толкоз добре.
CPython GIL
Python е един доста добър програмен език. Той е експресивен, елементарно се учи и употребява, и се поддържа в другите платформи и операционни системи. Но през последните няколко години най-популярната реализация на Python има сериозен проблем: не може да употребява преимуществата на многоядрените процесори.
Причината е световното блокиране на интерпретатора (GIL). В документите на Python е написано:
„В CPython световното блокиране на интерпретатора е мютекс, който блокира едновременното осъществяване на няколко потока код. Това блокиране е належащо. тъй като ръководството на паметта в CPython не е обезопасено, когато се прави многопоточна работа. И тъй като GIL съществува и няма по какъв начин да се махне, останалите функционалности започнаха да зависят от него“.
Първоначално GIL не е проблем. При основаването на Python съвсем няма многоядрени процесори и компютърни системи. А написването на GIL е елементарно и това е една опростена и разумна скица. Но през днешния ден дори в ръчните часовници има многоядрени процесори и GIL е явен и въпиещ недостатък във всички връзки на този програмен език. Въпреки известността на CPython, макар надарените програмисти и разработчици, макар спонсорите от ранга на Гугъл, Microsoft и Intel, никой не има намерение да трансформира и оправя GIL.
Заключение
Дори при съществуването на надарени експерти, доста пари и явен проект, зрелият програмен продукт е прекомерно мъчно да бъде изменен. Опитах се да намеря случаи, които да опровергаят деградацията на софтуера, само че не можах и наподобява няма такива. Аз в действителност желая да намеря образци, които да опровергаят деградацията на софтуера, тъй като без тях се обрисува една прекомерно мрачна вероятност.
В книгата „Електронната ера: работата, любовта и животът, когато роботите ръководят света“ Робърт Хансън малко се стопира на деградирането на софтуера“
„Програмното обезпечаване в началото е основано за избран кръг задания, принадлежности и обстановки. Но то постепенно се трансформира, с цел да може да се оправи с новия поток от задания, принадлежности и задания. Софтуерът от този вид става комплициран, нежен и в него става все по-трудно да се вършат потребни промени. В края на краищата, по-добре е всичко да се стартира изначало и от нулата да се напишат всички подсистеми, а от време на време е по-добре и да се основат напълно нов вид подсистеми“.
Сигурен съм, че това е истина и нещата стоят тъкмо по този начин. Като предписание, грамотната акомодация на софтуера към зародилите нови условия заема повече време и старания, в сравнение с написването на ново програмно обезпечаване от нулата. Програмистите не обичат да признават това, само че доказателствата са явни. В open source плановете има няколко доста известни образеца.
Многопроцесният Firefox
В началото Mozilla Firefox стартираше всичко в един единствен развой. Но след излизането на Гугъл Chrome стана ясно, че моделът с няколко процеса покачва осведомителната сигурност и продуктивността. Веднага по-късно разработчиците на Mozilla започнаха да възнамеряват реализирането на многопроцесна работа в браузъра Firefox. Това се случи през 2007 година.
След към 10 години Mozilla най-сетне показа многопроцесен Firefox за всеобщата публика. Това закъснение бе не заради липса на предпочитание или нещо друго. Mozilla разполага с надарени и способни разработчици и програмисти. Но все пак, Chrome бе написан безусловно от нулата за надалеч по-малко време, в сравнение с бе нужно на Firefox да реализира плануваните промени. Причините за това в съществени линии са две:
Преобразуването на еднопроцесната архитектура в многопроцесна изисква огромен брой дребни промени. Някои извиквания на функционалности би трябвало да бъдат сменени с междупроцесни връзки. Общото положение би трябвало да бъде пронизано от мютекси. Кешовете и локалните бази данни би трябвало да поддържат успореден достъпFirefox би трябвало да резервира съвместимостта със съществуващите разширения (или разработчиците ще би трябвало да ги обновят). Гугъл сътвори API за Chrome от нулата, без да има терзания от сходен жанр
Но обстановката в действителност е още по-зле. Ограниченията си опонират едно на друго: належащо е да бъде престроена вътрешната архитектура, само че общодостъпните API би трябвало да останат без промени. Не е за удивление, че Mozilla имаше потребност от цели 10 години, с цел да извърши този героизъм.
Събитийно-ориентираният Apache
Първоначално Apache httpd работеше по модела „един поток на една сесия“. Един и същ развой слуша порт 80, по-късно прави accept() и fork(). След това един дъщерен развой извършва read() и write() в границите на сесията. Когато поръчката завърши, дъщерният развой затваря сесията с close() и се излиза с exit().
Тази архитектура е опростена и лесна за осъществяване на всички платформи. И това е всичко. Тя е безусловно ужасна за продуктивността, изключително при дълготрайни свързвания с дълги сесии. Но въпреки всичко това бе през 1995 година. Малко по-късно Apache мина към многонишков модел, който усъвършенства продуктивността. Въпреки това, той не може да обработва 10 000 едновременни връзки. Архитектурата „един поток на една връзка“ изисква 1000 потока за обслужването на 1000 връзки. А всеки поток си има личен стек и положение, той би трябвало да е плануван и стартиран от операционната система. А това лишава време.
Точно противоположното, Nginx още през цялото време употребява Шаблона на реактора. Това му дава опция още през цялото време да обработва повече едновременни връзки и да го направи нестабилен към Slowloris офанзивите.
Nginx излезе през 2007 година и неговите прерогативи и продуктивност бяха явни. Няколко години преди излизането на Nginx разработчиците на Apache започнаха да преправят httpd за повишение на продуктивността. Многопроцесният модул event се появи през 2005 година във версия Apache 2.2. Но се оказа, че има проблеми със съвместимостта. И най-лошото бе, че той провали съвместимостта с най-популярните модули, като да вземем за пример mod_php. Програмистите не можаха да се оправят с този проблем до 2012 година, когато излезе Apache 2.4, включващ този модул (MPM) по дифолт. Въпреки че всичко работеше доста по-добре, спрямо предходните prefork и MPM, полученото изобщо не можеше да се съпостави с продуктивността на Nginx. Вместо шаблона на реактора, Apache употребява обособени пулове от потоци, с цел да слуша и приема съединенията и да обработва поръчките. Не се получи чак толкоз добре.
CPython GIL
Python е един доста добър програмен език. Той е експресивен, елементарно се учи и употребява, и се поддържа в другите платформи и операционни системи. Но през последните няколко години най-популярната реализация на Python има сериозен проблем: не може да употребява преимуществата на многоядрените процесори.
Причината е световното блокиране на интерпретатора (GIL). В документите на Python е написано:
„В CPython световното блокиране на интерпретатора е мютекс, който блокира едновременното осъществяване на няколко потока код. Това блокиране е належащо. тъй като ръководството на паметта в CPython не е обезопасено, когато се прави многопоточна работа. И тъй като GIL съществува и няма по какъв начин да се махне, останалите функционалности започнаха да зависят от него“.
Първоначално GIL не е проблем. При основаването на Python съвсем няма многоядрени процесори и компютърни системи. А написването на GIL е елементарно и това е една опростена и разумна скица. Но през днешния ден дори в ръчните часовници има многоядрени процесори и GIL е явен и въпиещ недостатък във всички връзки на този програмен език. Въпреки известността на CPython, макар надарените програмисти и разработчици, макар спонсорите от ранга на Гугъл, Microsoft и Intel, никой не има намерение да трансформира и оправя GIL.
Заключение
Дори при съществуването на надарени експерти, доста пари и явен проект, зрелият програмен продукт е прекомерно мъчно да бъде изменен. Опитах се да намеря случаи, които да опровергаят деградацията на софтуера, само че не можах и наподобява няма такива. Аз в действителност желая да намеря образци, които да опровергаят деградацията на софтуера, тъй като без тях се обрисува една прекомерно мрачна вероятност.
Източник: kaldata.com
КОМЕНТАРИ