Молодое поколение

Не так давно я выпустился из ВУЗа и, что неудивительно, в голове еще свежи воспоминания из студенческой жизни. Мне довольно повезло в плане учебного коллектива, т.к. одногруппники попались очень интересные, жадные к знаниям и ремеслу разработчика. Ну и, конечно, через друзей моих друзей удавалось неоднократно общаться с ребятами из других факультетов и университетов.

Будучи подростком мне очень нравилось читать что-то в стиле журнала «Хакер». Опустим, что там писали зачастую всякую публицистическую ерунду. Меня особенно завораживали статьи про финты с ассемблером и разборы нюансов низкоуровневого программирования. Но вот досада — ничего там не понимал. Но продолжал лелеять себя надеждами, что вот вырасту, пойду в политех и тогда все станет ясным и понятным. А потом вырос, отучился в том самом политехе, и понял, что те мечты были ни к чему.

В самом университете дали знания по устройству процессора, и даже 2 предмета с asm были. Но они были из серии «сдал-забыл». А лабы все писал сначала на Turbo C (ага, на дворе 2005 год), потом перешел на C/C++ и gtk для визуализации, а на последних курсах и вовсе JSE.

Конечно, не все из моего выпуска нашли работу в разработке ПО. Кто-то аж на 5-ом курсе понял, что это все не его дело, и доучился ради корочки. Но большинство пошли в программисты, и технологии по популярности можно расставить в следующем порядке: PHP, Web, Java, ObjC, C++. Были ребята и на 1C. Ни одного на чистом C или asm.

Получается, что современному поколению разработчиков в большинстве своем не интересны низкоуровневые технологии и языки. Может, конечно, у меня окружение такое. Но даже судя по популярным интернетам, современного молодого программиста интересуют бизнес задачи и высокоуровневые языки для их решения, создание продуктов и т.д. Энтузиастские разборы дизассемблированных программ нынче не в моде. И, судя по всему, в моде не будут. Все хотят на новые технологии.

И вот вопрос: хорошо это или плохо? Нужно ли современному разработчику высокого класса понимать, как работает компьютер на уровне процессора и памяти? Требует ли этого индустрия, или в 90% случаев можно обойтись пониманием структуры фреймворка? Может, раз индустрия так быстро развивается, то пусть отцы сидят на низком уровне, а бойцы пишут себе высокоуровневые обертки?

Очень интересно мнение каждого.

👍ПодобаєтьсяСподобалось0
До обраногоВ обраному0
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Два поинта:

1. Очень часто знания — сами по себе награда, которая не нуждается в монетизации.

2. Знаю вакансию, точнее не вакансию, а, так сказать, потребность проекта, где нужно написать компилятор либо в native код с веселенького языка, либо в llvm, тут знания асмов еще как нужны. Если подойдет человек, оторвут с руками, не ищут просто потому что не надеются особо, хотят своими силами. Заметьте, не ембед ни разу, а очень такая выскоуровневая хрень для веба. Но там помимо знаний асмов разнообразных еще нужно ой-ой сколько знать. Считают, что я могу, а я вот не знаю, браться или не браться.

PS. Начинал с асма, сейчас работаю в мессенджерах, электронной почте, и багтрекере :) и иногда на питоне.

Хорошо, плохо... Абстрактные вопросы об абстрактных вещах. Моё сугубо личное ИМХО:
1) Человек, как хороший разработчик, должен зарабатывать хорошие деньги. Пишет он на асме или двигает формочки мышкой — в данном конкретном случае — без разницы. Может он просветлённый, ему «по барабану», чем заниматься. Он нашёл нишу, работает 4 месяца в год, остальные 8 сидит на Тибете или путешествует.
2) Хороший разработчик, как просто человек, должен быть доволен своей жизнью. Тут он может получать удовольствие от минимизации использования памяти или от построения мышкой изящных решений при использовании какого-либо e-commerce DSL — без разницы.

Одним хочется понимать, что происходит с его бутербродом с момента намазывания масла до момента активизации митохондрий. Другим — как движение его мышки меняет структуру авто-сгенерённого XML-файла или Ant-сценария. Третьи счастливы, когда их точку зрения принимает кто-то ещё. Каждому своё =)

Для начала чтоб стартануть, можно, скорее даже нужно начинать с высокоуровневых языков, затем по мере совершенствования углубляться, расширяя тем самым круг задач, которых ты способен решать, да и вообще понимая как оно устроено на низком уровне подход к программированию будет более совершенным.

>Нужно ли современному разработчику высокого класса понимать, как работает компьютер на уровне процессора и памяти?

Обязательно. Также ,надо знать хотя бы С. Также желательно знатЬ, как все это работает на уровне ОСи, иначе будешь страдать впоследствии, выполняя задачи посложнее.

>Требует ли этого индустрия, или в 90% случаев можно обойтись пониманием структуры фреймворка?

Формошлепам и аутсорсерам не требуецца ,но тогда сиди всю жисть на жопе за потолок в 3к, который картельным сговором могут спустить.

>Может, раз индустрия так быстро развивается, то пусть отцы сидят на низком уровне, а бойцы пишут себе высокоуровневые обертки?

Пусть сидят. Молодые-горячие формошлепы будут работать за копейки, а ценность специалистов будет только рости. Причем, иногда даже в самых формошлепских областях надо спускацца на уровень пониже, если ты нормальный спец, а не городить огороды.

>Но большинство пошли в программисты, и технологии по популярности можно расставить в следующем порядке: PHP, Web, Java, ObjC, C++.

Моя истерически ржет. Обжектив-С без знания С? Работа только в пределах некстстепа и кокоа/кокоа-тача? Да это же формошлепство. Ни один же серьезный проект в руки не дадут, только и придецца в «лидерах рынка» за копейки работать.

>Были ребята и на 1C. Ни одного на чистом C или asm.

И это отлично. А то потом еще переметнуцца на близкий по духу и языку ойфон/макос дев серьезный, где половина всего пишецца на С, или, что еще хуже, в те области, куда я только собираюсь лезть.

Результат узкой специализации — кадров мало, кадры нужны, кадры стоят дорого.

Ы? Эт вы о чем? Я наоборот ратую за то, что даже высокоуровневый программер должен, в случае необходимости, уметь спускацца на уровень пониже.

уровень пониже — это не ассемблер. Ассемблер это очень низко куда высокоуровневому программеру надо примерно настолько же, насколько и законы физики, действующие в процессоре.

Ну ок, с асмом и потребностями разобрались.
К примеру, вы решаете некую сферическо-вакуумную задачку с помощью jquery. Как считаете, нужно ли уметь написать то же самое без библиотеки и понимать, как оно работает? Да и нужно ли вообще понимать, к примеру, структуру DOM? Ведь без этого эту нашу задачу можно решить (или просто нагуглить решение), и деньги свои получите. И спрос на таких специалистов тоже где-то будет, пусть и недорого. А может и дорого, ведь заказчику на код все равно. А результат есть, и причем быстро.
Вот насколько глубоко вы хотите знать то, с чем работаете? Желательно конкретные примеры, если можно.
Чем мотивируетесь при обучении? Интерес, деньги, ценность на рынке, признание среди коллег?
Всегда ли используете модель обучения сверху вниз?
Опять же, мнение каждого приветствуется.

опять некорректное сравнение. jQuery завязано на DOM больше чем полностью, а вот как разработка современного софта завязана на ассемблере? Современное программирование и программирование на ассемблере — это вообще 2 разные, почти несвязные вещи...

Современное программирование и программирование на ассемблере — это вообще 2 разные, почти несвязные вещи...
? Давайте определение «современному» программированию.

Он просто путает программирование и формошлепство.

т.е. программирование это ассемблер, а остальное формошлёпство?

вам определения надо? :)

Посмотрите на стиль программирования на ассемблере и скажем на .NET — будет видно что эти 2 вещи оперируют совсем разными логическими сущностями.

Простите, а ЦПП, Ц и Лисп — это современное программирование?

хорошо, давайте скажу высокоуровневое программирование. Блин, так и знал что кто-то начнёт придираться к словам.

Здаетсо мне что вы имеете ввиду не высокоуровневое, а прикладное программирование :)
Если да, то на ассемблере возможно написать текстовый редактор, поэтому

Современное программирование и программирование на ассемблере

не понятно.

Если нет, то Лисп — это язык высокого уровня, ЦПП и Ц тоже. При этом программирование на Ц и ЦПП требует знания «системного уровня» (железки, ОС и тд)

Блин, так и знал что кто-то начнёт придираться к словам.

Суть не в придирании, а в том что, к примеру, я не понял что вы хотели сказать. Если не трудно, объясните.

Здаетсо мне что вы имеете ввиду не высокоуровневое, а прикладное программирование :)

Здаетсо мне что кому-нибудь могло не понравиться слово «прикладное» (мол ассемблер тоже можно там использовать), поэтому написал «высокоуровневое». Не угадал, всё-равно кому-то не так :)

Суть не в придирании, а в том что, к примеру, я не понял что вы хотели сказать. Если не трудно, объясните.

та Господи, разработка ПО для хранения и обработки данных в БД.

та Господи, разработка ПО для хранения и обработки данных в БД.

Удачный коммент trimm’а

Он просто путает программирование и формошлепство.

Ибо если не формошлепство, то рано или поздно человек упираетсо в проблемы с сетью или каким-то сетевым протоколом, в винт, в то что ОСь не может выделить какой-то ресурс и тд.

А так человеку который разрабатывает одноюзерское КРУД приложение, может и не надо :)

и где здесь пригодится ассемблер?

А никто про конкретно ассемблер и не говорил. Речь идет о знании вещей которые работают на более низком уровне. Тот же jQuery и javascript, тот же джаваскрип при работе с плавающей точкой. Многопоточное программирование. При разработке, например, на джава надо понимать как работает виртуальная машина.

Кстати, а ассемблер пригодится, хотя бы для прочистки мозгов.

А никто про конкретно ассемблер и не говорил. Речь идет о знании вещей которые работают на более низком уровне. Тот же jQuery и javascript, тот же джаваскрип при работе с плавающей точкой. Многопоточное программирование. При разработке, например, на джава надо понимать как работает виртуальная машина.

я с этим и не спорю и про пример с jQuery и javascript своё мнение я высказал выше.

Кстати, а ассемблер пригодится, хотя бы для прочистки мозгов.

всё в этой жизни может пригодиться, знаний лишних не бывает

Речь идет именно об ассемблере, со знанием на изусть всех командов, регистров процессоров, прерываний, и прочих умных слов.

Каждый прочитал, то что хотел.

А если писать на MSIL/CIL — это будет современное программирование?

А когда писали Singularity — это было выскоуровневое программирование?

повторюсь в последний раз — назовите как хотите. Вроде понятно что я имел ввиду.

Ассемблерная ниша программинга и ниша разработки прикладных программ с использованием БД и формочек — абсолютно непересекаемые сейчас ниши и знание/незнание одной никак не мешает/помогает другой.

повторюсь в последний раз — назовите как хотите. Вроде понятно что я имел ввиду.

Странная попытка разделить всё на белое и чёрное, когда всё серое разных оттенков.

серое разных оттенков — это понимание как работает тот же фреймворк, как работает ОС и т.д. А вот ассемблер и разработка прикладных программ (такого типа как я написал выше, иначе кто-то опять начнет придираться к словам мол прикладное бывает разное) — это действительно черное и белое. Ассемблер настолько уже абстрагирован от этого, как и микроэлектроника

Нет ©

Ага. Безусловно все именно так. Только, иногда, дял оптимизации надо из высокого уровня уходить в низкий ,иногда, это надо делать для того, чтобы не городить огороды. Недаром в высоком уровне есть NDK разные. Так что вещи вполне связанные, если вы выполняете задания, за которые платят деньги, а не которые вам выдают в лидерах рынка.

Троллить нельзя помиловать.
Сферические «задания, за которые платят деньги» в вакуме...

Примеры в студию! Вакансий, где основательное знание ассемблера дает преимущество разработчику в решении его проблемы, и где «платят денег» больше чем в лидерах рынка. Мы на них посмотрим и решим стоит ли, потраченое время на изучения ассемблера, того или нет.

как вы предлагаете оптимизировать код, скажем используемый Entity Framework и делающий какие-нибудь запросы к БД? Вот например код, написанный вами, работает недостаточно быстро. Как здесь можно заюзать ассемблер?

К примеру, вы решаете некую сферическо-вакуумную задачку с помощью jquery. Как считаете, нужно ли уметь написать то же самое без библиотеки и понимать, как оно работает? Да и нужно ли вообще понимать, к примеру, структуру DOM?

А еще надо понимать как работают интерпретаторы джаваскрипта, бо будет куча ошибок. Самое простое с замыканиями (ее допускает каждый кто продвинулся дальше функций в одну строку :) )

Ведь без этого эту нашу задачу можно решить (или просто нагуглить решение), и деньги свои получите.

Если решаете (!)только стандартные решения, но я с таким не сталкивался, всегда хотят немного по другому.

У нас постоянно интерны вокруг — учатся, разбираются. Просто на Украине — аутсорс. Там главное — количество а не качество.

Да ну? Аутсорс — это просто организационная форма. Мы (то есть моя компания) по сути аутсорс, потому что мы тут, заказчик-владелец там, но мы делаем самые что ни на есть современные вещи. Сейчас весь современный мир — аутсорс так или иначе %). Глобализация иными словами.

>>>

>>> Т. о. не все способны к обучению в ВУЗе, но тем не менее все туда прутся.

Ну скажімо так — до ВТУЗу я, наївний хлопчина, пішов саме навчаися на розробника апаратури — ціль дитинства та юнацтва була — тому й перся. Ось роки промайнули, і я досить ткаи кваліфікований розробник. Таж ніяк не завдяки ВУЗу — мене тричі(!!!) з нього відраховували, та так я його і не закінчив. Мало того відкрию державну таємницю — там ті розробники і не викладають.

>>>
>>> В итоге и рождается мнение, что в ВУЗе ничему не учат.

>>>

Йдете на радіотехнічй факультет КПІ, відбираєте тих хто прослухав та успішно здав курс "генеруання та формуання...«(радіопередавачі) та даєте завдання розробити простий передавач. Чекаєе років з 5. Робите висновки. Ті хто перед цим закінчив технікум — не враховуються, попри байкам по недостачу фінансів там іноді ще щось і вчать та випадково можна зустріти компетентну людину...

Про радіопередавачі я навмисно — бо як скажи про ті ж мікроконтроллери, то заскиглять що це не профільне(ну звичайно, де радіо, а де контоллери).

Ще слово про ВУЗи й метастази. Коли моя районна сітка ще не злилася з LANETом, нас іноді підключали до сіток-партнерів — як бонус, фільми там покачати. І я зайшов на комп якогось сучасного (2008) студента, там якісь курсачі його, дипломи — і що цікаво в технікумі(не пам’ятаю де — чи не на львівській) він вивчав архітектуру ARM, досить добрий ввідний курс, а в ВТУЗі (не РТФ, чи энергетичний чи ФЭЛ) x51 в стилі техопису Г4-18, зате зі звітностями на А4 в рамочці з підписом... Це я до того, що діагноз ВУЗів технічного не софтового профілю — неблагоприємий. Чи не розвідслужби постарались? Ті хто запевняє що міліардні вливання спасуть ситуацію — бреше, скоіш за все не байужий ці міліарди «паімєть». В технікуми ніхто ж ночами золото не завозить — все на ентузиазмі.

Это нормально! Мой отец, к примеру, двигатель Москвича мог перебрать в поле при слабом лунном освещении. А я в своём «тазике» — ну максимум свечи поменять могу. И то стрёмно. Это плохо? Это нормально!

Важный момент: вы автомеханик?

Не. Но мой отец считает, что каждый водитель должен быть в состоянии перебрать двигатель. Типа, а вдруг? Так и тут.

Тогда ваш пример немного не по теме. Ибо это больше похоже на: каждый программист должен уметь паять процы и память и винт чинить. А вопрос не в этом, а в том что каждый программист должен иметь представление о том как оно работает.

Нет, не похоже на винт. Похоже на «а как оно работает». Почему когда крутят руль — крутятся колёса, что происходит когда дёргают рычажок между сидениями и т.д.
Как оно работает? А что «оно», кстати? Всё равно опускаешься до какого-то уровня. Ну, у молодёжы этот уровень несколько выше. У нас ниже. У тех, кто застал перфокарты он ещё ниже.

мой отец считает, что каждый водитель должен быть в состоянии перебрать двигатель.

В том-то и дело что перебрать двигатель москвича. Он просто как угол дома и чинится на коленке. Пусть попробует двигатель BMW или Порша перебрать при лунном свете)))

Это вопрос из типа, нужно ли уметь пользоватся лопатой, чтобы рыть котлован эскаватором.

Несомненно, умение копать лопатой — полезный навык, но оператор эскаватора вполне может без него обойтись без какого-либо ущерба для своей квалификации.

в том то вся и суть, что оператору эскаватора действительно может потребоваться выйти и помахать лопатой, т.к. ковш куда-нить просто не пролазит, а вот чтобы знания ассемблера были незаменимыми и вообще оправданными в разработке приложения с использованием какого-нить высокоуровневого фреймворка....

Обычно, оператор эскаватора — далеко не единственный специалист на стройке, там еще есть разнорабочие для зачистки всяких узких мест недоступных для автоматизации. Причем у разнорабочих кожа на руках закаленная и мышцы прокачаные. Зачем копать оператором эскаватора?

на случай если ВДРУГ не окажется разнорабочего (там инопланетяне похитили, а новых нанять не успели), вот тогда скилл работанья лопатой действительно понадобится оператору эскаватора, в отличие от скилла «гуру ассемблера» для разработчика приложения с использованием скажем .NET и Entity Framework.

Будет спрос, будет и предложение.

Но вобще да — эволюция в целом идет от меньшого к большему.

Если вы уважающий себя программист, то вы всегда стремитесь расширять свои знания.

В одном из подкастов, с Робертом С. Мартином (Uncle Bob) он рассказывал историю, про своего друга — он работал проектировщим hardware, в одной оч крупной организации (HP, IBM не важно..). Он достиг очень большого успеха в этом, и позже перлючился на софт. С необычайной легкостью он освоил АСМ, потому как все команды, которые он использовал в АСМ — были ему уже знакомы.. Он знал как работает ALU, он знал как работает контроллер прерываний и микропроцессор. Дальше, С/С++, Java и т.д.. это не более чем высоуровенивые «обертки» над его уже имеющимися знаниями. Он стал очень крутым программистом.

Я разделяю ваш интерес, и считаю — базовые, низкоуровненвые знания важны. Эти познания во многом опредяют вас как разработчика.. и отделяют от б-кодера).

Коментар порушує правила спільноти і видалений модераторами.

А еще он забыл добавить что это было «давно и не правда».
Если и брать область разработки H/W которая граничит с ассемблером или низкоуровневым С, где знания смежны, то уж извините, но «нормальные» плюсы(с бустом, стл и другими библиотеками), жава с её фреймворками это никакая не обвертка над знаниями. т.к. задачи решаются разные, совсем разные.

знания про количество тактов на выполнение команды, особенность контроллера прерывания, или конкретная реализация конвеера процессора никоим образом не поможет разработчику мапить базу данных в хибернейте или релизовывать GUI на Qt.

Спросите у профессионального архитектора — может ли он проективать сложные здания без знаний строительных материалов, вплоть до свойст бетона и стали. Это низкоуровневые знания, которые, как Вам кажется — не нужны.

Аналогия очевидна.. Слепить сарай из досок, может любой. Построить небоскреб, знающий.

Правильно.
Но исходя из вашей же аналогии, то что нужно архитектору ПО для работы — это знать что базовые компоненты: железо, ОС, возможности языка/языков проектов, библиотек и прочего соответсвуют требуемым критериям.

И грубо говоря, если для работы программы нужно 1000 мипсов мощности на одно ядро, 1гб оперативки и POSIX совместимая ОС, то уже все равно каким образом и через какие конвееры эти мипсы берутся у процессора, используя какие времянки, управляющие сигналы и т.д. работает память и какая именно реализация у интерфейсов ОС.

>>>Спросите у профессионального архитектора — может ли он проективать сложные >>>здания без знаний строительных материалов, вплоть до свойст бетона и стали. Это низкоуровневые знания, которые, как Вам кажется — не нужны.

>>>>Аналогия очевидна.. Слепить сарай из досок, может любой. Построить небоскреб, знающий.

а вы таки наивный молодой человек

Главное до какого уровня детализации он должен их знать. Команды процессора скорее относятся к уровню атомарному :) по Вашей аналогии. Для шарпника мир по сути заканчивается на объектном коде, в дебри его реализации им уже лезть не надо, даже вредно.

Архитектура программно-аппаратной системы, которую представляет наш компьютер, в тысячи раз сложнее самого сложного архитектурного сооружения в мире :). Поэтому сравнивать эти вещи нельзя.

Наример, зачем PHP-программисту нужно знать асемблер?

аналогия неверна (как часто это и бывает). Потому что в проектировании зданий играют роль свойства материалов и даже каждый из нас прекрасно понимает к чем приведёт постройка небоскрёба из глины. Только вот как повлияет знание программистом ассемблера если проект всё-равно собирает компилятор?

Если это C/C++ то очень часто при креше «релизного» билда приходится смотреть стек, и содержимое регистров, а не только исходник. Да что там, даже я в своем питоне раз в год точно с самим интерпертатором под gdb вожусь, правда в асм лезть там не нужно, но смысл понятен — lowlevel нужен.

Ну и даже штатные компиляторы выдают более оптимизированный код, чем средней программист-ассемблерист. Да и учитывая разнообразие процессоров затачивать десктопное приложение под один конкретный процессор — нонсенс. Те же кодеки проще и быстрее писать на базе библиотек интеля. Так что чистый асм и с — это скорее для всяких ARM, embedded и иже с ними. Сам начинал с асм :)

Ну и даже штатные компиляторы выдают более оптимизированный код, чем средней программист-ассемблерист.

Согласен на 100%.

Да и учитывая разнообразие процессоров затачивать десктопное приложение под один конкретный процессор — нонсенс.

А вот с этим не согласен, смотря что это приложение делает. Не зря же в десктопных процессорах есть SIMD/MIMD инструкции. Раньше они были разные у каждого процессора. Сейчас, конечно, на десктопах остался один только Интел.

Те же кодеки проще и быстрее писать на базе библиотек интеля.

Кодеки очень разные бывают, чтобы просто юзать готовую библиотеку :) и сейчас их делают в основном на базе GPU.

Так что чистый асм и с — это скорее для всяких ARM, embedded и иже с ними

Ну я бы не стал столь категорично говорить.

Так я ж писал — «скорее, почти» и т.д. Понятно, что есть всякие прикладные области, где такие знания очень пригодятся.

Интел один (почти), но и процессоров у него много, с разными наборами команд и с разными длительностями выполнения команд, с разными контроллерами памяти. Код, оптимизированный под и7 первого поколения может оказаться не совсем эффективным для и7 второго поколения и может просто не работать на процессорах серий 3хх, 5хх., 7хх, 9хх. Ну это так, к примеру, что качественная оптимизация — процесс длительный и дорогостоящий и проще поднять планку требуемого железа, если есть куда подымать %) конечно — чем оптимизировать жестко код. Часто оптимизация алгоритма дает лучший результат, чем оптимизация кода на нижнем уровне.

Ну и даже штатные компиляторы выдают более оптимизированный код, чем средней программист-ассемблерист.

Неправда. Другое дело, что в 99.99% случаев языков высокого уровня сегодня достаточно.

Правда, правда. Оптимизация — это NP-полная задача, с частичным решением которой человек справляется гораздо хуже машины.

Ток шота она не всегда работает, особенно в случае DSP алгоритмов. Год назад ускоряли С-код под TI в 5 раз на ассемблере. Ну и включенная оптимизация — основная причина ошибок на выходе компилятора.

Другое дело, что железо сегодня на столько быстрое, что многие с подобными проблемами просто не сталкиваются и считают компиляторы — эталоном оптимальности.

На выходе компилятора? Компилятор обвинить проще всего :<). Возможно под TI там и есть проблемы, но я ведь речь вел о десктопах. Поверьте 20-ти летнему опыту оптимизации кода на асм (мои примеры есть и в мсдн %) — сейчас написать код более быстрый, чем это делает современный компилятр микрософт или интела (браво россиянам) — нетривиальная задача и требует нестандартных решений именно для вашей задачи — так как при оптимизации компилятор, к счастью?, не понимает смысла конечной цели. Ну и есть библиотека от интела — где 99% задач математики, цос уже оптимизирована, и под разные типы процессоров — опять браво нижнему %). Те же gpu , cuda — практически никто не программирует прямо в командах gpu — используют соответсвующие библиотеки. Понятно, что кто-то эти библиотеки пишет, и вполне даже, что на асм, с — но это явно не юниоры.

В отличии от х86 платформы, где компиляторы отличные, компиляторы от вендоров контроллеров/процессоров TI, freescale, atmel и т.д. порой и ошибки генерят, и неоптимизированный код.

Поверьте 20-ти летнему опыту оптимизации кода на асм (мои примеры есть и в мсдн %) — сейчас написать код более быстрый, чем это делает современный компилятр микрософт или интела (браво россиянам) — нетривиальная задача

Расскажите, основываясь на свой 20 летний опыт, почему, к примеру, компилятор от VS2010 , на этот тривиальный код генерит полный цикл условных/безусловных переходов, которые сможет оптимизировать любой ассемблерщик:

int func(int a, int b){
int c = 0, d = 0;
for(int i = 0;i < 16;i++)
if (i&1)
c+=a;
else
d+=b*2;
return d + c;

}

Хотя при цикле for(int i = 0;i < 10;i++) код оптимизирован правильно компилятором до 10 последовательных команд.

а если написать 2 цикла, по четным и нечетным, то все будет впорядке причем при увеличении количества элементов бранчинг не появится, даже если цикл не развернется

Если написать сразу оптимизированно на сях или на сразу асме — тоже все будет хорошо.

Но мы же говорим о конкретной функции, с конкретными тривиальными ветками, которые не оптимизируются конкретным компилятором, а должны бы, если по хорошему.

Почему должны? Кто так решил? Современные ЦПУ сами по себе оптимизируют код при выполнении — и такой код они проглатывают на ура. Разработчики компиляторов в курсе и голову ерундой не забивают. Иначе стоимость компиляторов будет такой, что проще на асме писать будет %)

ГОСПОДА! Мы ушли не в те дебри %)

Почему должны?

Если не должны — то спор о том, что компилятор создает код лучше человека совсем не в сторону компилятора.

ЦПУ сами по себе оптимизируют код при выполнении — и такой код они проглатывают на ура

Я что-то пропустил в мире и ЦПУ развернет цикл из машинных кодов и ветвлений и выполнит его итерационно?

В некотором смысле да, развернет. Ибо цикл в данном случае строго определен и проц его просчитывает абсолютно со 100% вероятностью вперед и подкачивает именно следующие команды по алгоритму выполнения, а не по расположению в памяти.

Насчет спора — я ж писал, что современный компилятор код на асме делает лучше, чем СРЕДНИЙ программист-ассемблерист. Обязательно найдется специалист, который данный конкретный код сделает лучше, но лучше ли это будет для конечного результата в современном мире? (money-money-money).

Представляете, как бы летали оси, если бы они были изначально написаны на оптимизированном коде, вот только сколько столетий пришлось бы ждать результата.... им каков глючный он бы был, этот ... windows, unix?

В некотором смысле да, развернет. Ибо цикл в данном случае строго определен и проц его просчитывает абсолютно со 100% вероятностью вперед и подкачивает именно следующие команды по алгоритму выполнения, а не по расположению в памяти.

Вот 3 команды из листинга который вы скинули:

00401012 inc eax
00401013 cmp eax,10h

00401016 jl wmain+6 (401006h)

Как предсказатель переходов определит какую команду закидывать в конвеер после команды 00401016 если результата сравнения еще нету?Если бы то, как вы описываете было бы правда — наличие условий в програме не влияло бы на скорость работы никаким образом и никогда кроме дополнительных двух комманд для реализации условного перехода. Но на деле все трохи иначе.

Как предсказатель переходов определит какую команду закидывать в конвеер после команды 00401016 если результата сравнения еще нету?

Нужно помнить, что переход по истинному результату сравнения всегда выполняется быстрее, чем переход по ложному. Даже, если предсказатель переходов промахнулся. Это первое.

Если бы то, как вы описываете было бы правда — наличие условий в програме не влияло бы на скорость работы никаким образом и никогда кроме дополнительных двух комманд для реализации условного перехода.

А оно и не влияет, branch predictor не один, и процессор готов к любому результату сравнения. Сложнее будет с jmp [eax], но даже тут количество угадываний превышает промахи.

А оно и не влияет, branch predictor не один, и процессор готов к любому результату сравнения. Сложнее будет с jmp [eax], но даже тут количество угадываний превышает промахи.

Т.е. пока процессор выполнит одну команду, предсказатели перехода осилят выборку минимум 2х команды из памяти(даже не из кеша?!) и не задержат работу конвеера?

В реальности есть системы где память в 2 раза быстрей чем процессор?

Процессор не выбирает команды из памяти именно командами. Читается prefetcher’ом участок памяти определенного размера (сache line), 64 байта на большинстве современных процессоров. Условные переходы, как правило, не уходят за пределы 2-3 cache line’ов. Доступ к L1 кешу — 3 такта на современных процессорах, к внутренним блокам процессора ещё меньше.

Но никто не гарантирует наличие данных в кеше для адресов условного перехода, а это уже — внешняя память и выборка целой новой линии в кеш.

Да, гарантию никто не дает. Как раз вся соль современного процессора именно в этом — предугадать, какие данные и какой код будет нужен на следующих тактах, а частота и количество ядер уже давно вторичные.

И с каждым новым поколением процессоры делают это всё лучше и луче. Или число транзисторов растет в разы каждый при почти одинаковом наборе команд просто так, от нечего делать? Процессор давно уже перестал быть процессором в академическом виде — это давно уже микрокомпьютер, чаще всего RISC....

И вообще — о чем спор? Если в том, кто лучше оптимизирует — ну так давайте тут на форуме заведем соответствующий уголок, вывесим там задания, может даже придумаем призы — и вперед — оптимизируем %)))))

ПС: с обязательным бенчмаркингом

Зато, самая программистская ветка во всей теме. Интересно читать.

В случае статического предсказания следующая инструкция будет взята с адреса, который меньше текущего (т. е. 401006h). В случае динамического на первом проходе — зависит от конкретной имплементации. На втором проходе — будут уже учитываться результаты первого.

В некотором смысле да, развернет. Ибо цикл в данном случае строго определен и проц его просчитывает абсолютно со 100% вероятностью вперед и подкачивает именно следующие команды по алгоритму выполнения, а не по расположению в памяти.

Вообще то мне кажется нету достаточно умных компиллеров что бы они зашарили что в данном примере не нарушается алиасинг -> в зависимости от ключиков программа вполне может преодолевать барьер памяти на каждой итерации и никаких процессорных оптимизаций не будет. Это кстати еще и обьясняет почему все в регистрах лежать не будет.

Я что-то пропустил в мире и ЦПУ развернет цикл из машинных кодов и ветвлений и выполнит его итерационно?

Почти, но branch predictor в CPU — это уже почти искусственный интеллект.

А предсказание переходов и разворачивание кода дают эквивалетность в скорости выполнения?
Ведь защита от опустошения конвеера, даже при 100% предсказаний не выполнят код из примера который я привел парой страниц выше, по скорости, к приблизительно такому варианту асмового кода:
00000 03 c0 add eax, eax
00002 8d 0c 00 lea ecx, DWORD PTR [eax+eax]
00005 8d 14 36 lea edx, DWORD PTR [esi+esi]
00008 03 c8 add ecx, eax
0000a 03 d6 add edx, esi
0000c 03 c8 add ecx, eax
0000e 03 d6 add edx, esi
00010 03 c1 add eax, ecx

00012 03 d6 add edx, esi

Нет, полного эквивалента не будет. Здесь не только разворачивание, все команды разбиваются на пары. Но дело даже не в этом, разворачивание циклов всегда можно включить. После этого обычно компилятор переделывает полученный код, чтобы убрать лишние команды.

Если говорить конкретно о проблемах с разворачиванием в VS2010, то почему не поменять на Intel компилятор, который более качественно генерирует код? И к тому же дешевле стоит. Я после MSVC 2003 видел только ухудшение кодогенерации. Хотя надо отдать должное, что под 64-битовую платформ код генерируется в MSVC 2010 гораздо лучше.

У MSVC есть бесплатная ерсия

Но стоит ли выделка овчинки? Я считаю — что для такого кода уже не стоит. Если бы это была эра 8080, 8086 или даже 80386 — то еще стоила бы.

Угу, только в реальности вместо того, чтобы делать выборки элементов один раз вы заставите контроллер памяти дважды пройтись. Если цикл короткий — то один ечрт (оно еще в первом кеше будет), но если цикл длинный — то вот вариант с if будет как раз быстрее.

В общем я не спорю, и соглашаюсь со всеми тут, потому как каждый прав, просто хочу автору первоначального поста донести — что оптимизатор (а других ассемблеристов практически сейчас не нужно, ну почти) — это и профессия, и призвание, и непрерывная учеба. ПХП выучить проще %) .

какая память, если для данных, из примера, вполне достаточно только регистров?:)

еще вариант

int func(int a, int b)
{
int c[2]={0};
const int data[2] = { b*2, a};
for(int i = 0;i < 16;i++)
c[i&1]+=a[i&1];
return c[0] + c[1];

}

Место того что-бы функция выполнялась фактически только с регистрами, вы вносите необходимость использовать стек и добавляете ненужных команд что-бы убрать 1 условный переход. Это как оптимизируется?Ну и еще я молчу про читаемость такого кода.

тут всего 4 инта + счетчик, компилятор должен догадаться разместить все в регистрах.
мне кажется код довольно читаем.

для оптимизации под симд такой код будет приятнее

СИМД — ляжет практически идеально, но именно тот вариант, когда компилятор не понимает конечной цели, а человек понимает, — и тогда пишет код лучше компилятора. Либо даже меняет изначальный код, не меняя цели — компилятор еще изменять сами алгоритмы не умеет (разворот цикла в последовательность команд не есть изменением алгоритма в моем понимании). Иначе бы пришлось всем программистам туго %))). Иногда на уши приходилось вставать ради лишних тактов... Но давно это уже было. Отстал.

А, опередили %) См.выше

только у Вас там ошибочка в

c[i&1]+=a[i&1];

)

я поменял местами b c a и с c d

int func2(int a, int b)
{
00401000 sub esp,10h
int c[2]={0};
00401003 xor edx,edx
00401005 push esi
00401006 mov dword ptr [esp+4],edx
0040100A mov dword ptr [esp+8],edx
const int data[2] = { a, b*2 };
0040100E mov dword ptr [esp+0Ch],0Ah
00401016 mov dword ptr [esp+10h],28h
0040101E push edi
0040101F nop
for(int i = 0;i < 16;i++)
c[i&1]+=data[i&1];
00401020 mov eax,edx
00401022 and eax,1
00401025 add eax,eax
00401027 add eax,eax
00401029 mov esi,dword ptr [esp+eax+10h]
0040102D add dword ptr [esp+eax+8],esi
00401031 lea ecx,[esp+eax+8]
00401035 lea eax,[edx-1]
00401038 and eax,1
0040103B add eax,eax
0040103D add eax,eax
0040103F mov edi,dword ptr [esp+eax+10h]
00401043 add dword ptr [esp+eax+8],edi
00401047 add dword ptr [ecx],esi
00401049 add dword ptr [esp+eax+8],edi
0040104D lea eax,[esp+eax+8]
00401051 add edx,4
00401054 cmp edx,10h
00401057 jl func2+20h (401020h)
return c[0] + c[1];
00401059 mov eax,dword ptr [esp+8]
0040105D mov ecx,dword ptr [esp+0Ch]
00401061 pop edi
00401062 add eax,ecx
00401064 pop esi

}

Вроде бы оптимизация кода на С реально вылилась в более громоздкий код. Потому что компилятор Вас не понял. Поэтому и говорю — для современных компиляторов такая вот «оптимизация» на С вредна по двум причинам — компилятор Вас не поймет, не поймет Вас и тот, кто после Вас будет поддерживать код. Ручками конечно можно оптимизированный код С переложить на команды компилятора (но код будет либо похож на первоначально-компиляторский постом выше, либо вы просто его развернете в прямолинейный код, за что потом Ваш последователь помянет Вас нетихим словом, когда придется циклы сделать другой длительности или поменять одну команду внутри — а в результате ему придется перелопачивать-переписывать весь супер-пупер оптимизированный код), а еще можно и ССЕх задействовать, но.. код быстрее не будет. Не верите — пишите и запускайте бенчмарки.

Да, не поймите меня неправильно — оптимизация нужна, но только там, где необходима, а не везде %)

я выше уже написал более симпатичный вариант, там где в одной итерации исполняются обе команды

а этот код я потом перепроверю, мне что-то кажется что вы компилили без отпимизаций

Выставил ради интереса по максимуму в IDE. Еще можно ручками дописать ключи — но нет времени %) работа не ждет, увы.

Ну вот, что написал компилятор:

#include “stdafx.h”

int func(int a, int b){
int c = 0, d = 0;
for(int i = 0;i < 16;i++)
if (i&1)
c+=a;
else
d+=b*2;
return d + c;

}

int _tmain(int argc, _TCHAR* argv[])
{
printf("%i“, func(10,20));
00401000 xor edx,edx
00401002 xor ecx,ecx
00401004 xor eax,eax
00401006 test al,1
00401008 je wmain+0Fh (40100Fh)
0040100A add edx,0Ah
0040100D jmp wmain+12h (401012h)
0040100F add ecx,28h
00401012 inc eax
00401013 cmp eax,10h
00401016 jl wmain+6 (401006h)
00401018 add ecx,edx
0040101A push ecx
0040101B push offset string “%i” (4020F4h)
00401020 call dword ptr [__imp__printf (4020A0h)]
00401026 add esp,8
return 0;
00401029 xor eax,eax

}

Ваш код скорее всего будет короче на 1-2 команды, но навряд ли быстрее.

ПС: не ругайте за микс стилей — всунул код для пробы куда попало.

А, забыл уточнить — опции компилятора умолчальные. Если нужно развернуть циклы — то просто в опциях нужно дописать пару символов и будет вам счастье в виде unwinded кода. Только для такого короткого кода не вижу смысла — современным ЦПУ это один черт.

Только вы неправильно провели эксперимент. Из-за константных параметров и одного вызова компилятор вам занес фактические параметры прямо в тело функции. поменяйте ваши 10 и 20 на (argc +2) и (argc +4) и посмотрите на разницу.

и такое

int func(int a, int b){
int c = 0, d = 0;
for(int i = 0;i < 16;i+=2)
{
c+=a;
d+=b*2;
}
return d + c;

}

самый правильный вариант

int func(int a, int b)
{
return 8*( a + b*2 );

}

1. Совершенству нет предела, ровно как и совершенству оптимизации.
2 Процессоры Интел — это даже не 50% мирового рынка процессоров, а скоро будут и все 10%.
3. Многие современные процессоры (soft cores) позволяют создавать custom instructions, ускоряющие программу 10 раз оптимизированную на С еще в 10 раз. Компилятор, как правило, о них несовсем в курсе, поэтому приходится вставлять их в код самому, где нужно.

4. Если у Вас ультра-производительная система из 64 процов, у каждого памяти по 128Б −1кБ, вы тоже будете на С писать?

Тем не менее некоторые задачи решаемые компиллером во время компиляции действительно НП полные: en.wikipedia.org/...ster_allocation

Я лично за середину, писать на си, а батлнеки каких не много если невмоготу можно попереписывать на асме.

Согласен на все 100. Даже было в штате 1-2 ассемблериста . Потом оказалось невыгодно и неэффективно. Но тут у каждого по-своему.

Правда и то, и другое.

С железа на софт несложно перейти. Многие украинские железячники в свое время переквалифицировались в программеров. В обратную сторону примеров не наблюдал.

знания конечно лишними не бывают, но к сожалению сейчас такой объём полезной информации, что элементарно не хватит времени чтобы во всём хорошо разбираться. И те же фреймворки часто довольно сложны и чтобы достичь хорошего уровня нужно потратить много времени. Для множества прикладных задач, где используется тот или иной фреймворк, знание ассемблера элементарно не нужно и это время куда полезнее потратить, покопавшись в фреймворке. Так что ваше определение как разработчика и отличие от б-кодера не более чем повышение своего ЧСВ (я вот знаю ассемблер, а они, б-кодеры, могут только формы клепать). Только между этими 2-мя крайностями есть ещё куча всего и для этого всего ассемблер не нужен вообще.

ЗЫ. Время, потраченное на изучение ассемблера прикладным программистом, лучше потратить на какое-то своё хобби, т.к. человек должен быть счастливым в жизни, а не тупо педалить код 80% времени :) Тем более те люди, которым пришлось плотно возиться с ассемблером — несут этот «багаж» в себе и при необходимости вспомнят и поймут как применить, а изучать его без практики — это время на ветер

Это один выбор, имеющий право на жизнь.

А другой выбор — это не гоняться за фрейморками, а изучать «вечное». АСМы не меняются каждый год, там один в десятилетие появляется, который можно за пару недель освоить, если оно нужно. Языка C тоже будет с нами еще очень долго, дольше, чем C++. И т.п. вверх по стеку технологий.

а я не предлагаю гоняться за фреймворками. Я предлагаю эффективно и быстро разрабатывать сложные приложения (и это не только формошлёпство, как кое-кто тут выразился, правильно построенное приложение требует немалых знаний и опыта), а не учить то, что актуально сейчас только для довольно узкой сферы

Областей где нужно знать внутренности компа выше крыши — и упомянутые embedded, high load, а еще базы данных(их тоже кто-то пишет), виртуализация, медиа кодеки, безопасность по обе стороны барикад, промышленные и не только роботы. Другое дело что в украинском аутсорсе этого всего за исключением embedded исчезающе мало, и в 90% случаев действительно достаточно знать 5 фреймворков на джаве или .нете.

рынок просто «узкий» в данном случае, низкоуровневая оптимизация и все такое важны либо на упомянутом ниже эмбеде, либо на хай-лоад системах, чего не так уж много...
кроме того не всякий разработчик психологически вытянет это все, кроме знань и умень, тут еще надо и мозк сдвинутый немного набок иметь ...

а обычному б-кодеру это все не надо, да и не всегда доступно

А в чём разница между программированием на C# и на ASM?
В том что нужно знать разные технологии/подходы специфичные для данной области?

И всё? А что если вы просто почитаете как это внизу работает — разве этого не будет достаточно?

Не всегда. Работая с асмом иногда приходится еще и работать с осциллом.

теоретически — будет, практически — нет.

Например, если новичок прочитает пару спецификаций (C#, .NET,...), то он теоретически не должен отличаться от разработчика с ХХ-летним стажем, но на практике... — сами понимаете... ;-)

Система образования в этой стране давно дала дуба, а вонь от разлагающегося трупа до сих пор теребит неокрепшие умы студентов. Как правило к концу 4 курса начинаешь понимать, что универ тебя нечему хорошему не научил/научит. После это как правило или идут переквалификация туда где знакомые возьмут или начинаешь сам как то крутится. Доходят до конца чисто ради корочки. Вот так вот.

Только в этой стране: мечтаешь об одном, учишься на втором, а в итоге занимаешься третим ..

Только в этой стране: мечтаешь об одном, учишься на втором, а в итоге занимаешься третим ..

если говорить о вопросе профессии, то я, например и хотел, и учился и занимаюсь одним и тем же.

а что вам мешает заниматься с/с++, если это вам до жути нравится?

или то, что вакансий 5, а не 50 как на жаву/пхп сразу делает это направление ущербным?

Отнюдь, просто меня без опыта работы Juniorom не возьмут, а с тем же С# и Java шанс есть. Вот и весь расклад.

Если Вы сами не хотите научиться, то в институте Вас ничему не научат — так было всегда. Это основное отличие ВУЗа от школы. Т. о. не все способны к обучению в ВУЗе, но тем не менее все туда прутся. В итоге и рождается мнение, что в ВУЗе ничему не учат.

Помойму мы говорим о разном. Желание учится есть, универ просто нечего достойного предложить не может. И таки да, сейчас универ это в первую очередь корочка, а знание это уже как получится. Повторюсь:

Система образования в этой стране давно дала дуба, а вонь от разлагающегося трупа до сих пор теребит неокрепшие умы студентов.

Либо желания учится таки нет, либо Вы учились не в том универе.

можно привести лошадь у ручью, но нельзя заставить ее пить.

Если вода хорошая, то таки да, заставлять не нужно — будет пить сама, не оттащишь.

тю. а меня чему-то научили в универе (и, даже, кое-что воспитали во мне). что я делал не так?

вы хотите сказать, что вузы — отстой, а аутсорсинг — школа жизни, как и макдональдс.
Тогда может давайте все вместо школы в мадональсе работать, а вместо вуза — в аутсорсинге?

Непонятно только, почему в аутсорсинге высшее образование требуют.

вы хотите сказать, что вузы — отстой, а аутсорсинг — школа жизни
Нет, вы меня не правильно поняли. Я всего навсего хотел лишь сказать, что систему образования надо в срочном порядке допиливать до мировых стандартов ! А не как сейчас — на бумажке одно, на деле совсем другое. Чего только стоит интерпретация болонской системы (кто учится в КПИ тот знает о чем я говорю) ...

Может, конечно, у меня окружение такое.

100%.

в геймдеве (я имею ввиду настоящие игры которые требуют крутых видюх, новых технологий и тп) редко, но нужно точно знать как будет выглядеть ассемблерный выхлоп компилятора, где он втулит виртуальный вызов, где лишний раз переменные в память запишет. Если PC еще балует, и не сильно ругает за такое, то вот в консолях можно получать существенный выигрыш от статической типизации и минимизации условных переходов и обращений к памяти.

вот допустим довольно познавательные слайды macton.smugmug.com/...593426709_ZX4pZ

Нужно ли современному разработчику высокого класса понимать, как работает компьютер на уровне процессора и памяти? Требует ли этого индустрия, или в 90% случаев можно обойтись пониманием структуры фреймворка? Может, раз индустрия так быстро развивается, то пусть отцы сидят на низком уровне, а бойцы пишут себе высокоуровневые обертки?

thin trolling

как бы тогда выглядел толстый троллинг? )

как бы тогда выглядел толстый троллинг? )
примерно так:
я 5 лет учился в ВУЗе на программиста,
и желания пойти работать пограммистом не возникло.
точнее... он возникало на диване после ужина.

Сейчас, когда родители не дают карманных денег,
а до пенсии ещё далеко, я вспомнил о дипломе.
Но как стать этим самым программистом?
Подскажите пожалуйста, уважаемый ДОУ!

Ответ: дорогой Михаил! благодарим вас за интересный вопрос.
индустрия сейчас на подьёме, потому конторы на работу берут всё что шевелится,
а если кандидат ещё и с дипломом. ..
Да если по-английски ещё на собеседовании не ударит фэйсом об тэйбл...
Скорее ищите работу, потому что когда грянет очередной кризис, лентяев погонят под жопу, как трутней из улья по осени.

целую,
ДОУ

Сейчас достаточно знать то, за что платят деньги. И не более. Я не говорю, что это хорошо, но это наша действительность

А все идет вовсе не от программиста, а от задач. Вот сейчас наиболее масштабны разработки в паутине.. Зачем кому-то писать сайт-сервис с использованием ассемблера?

С другой же стороны, вполне реальным явлением является использование языков, заточенных под определенные нужды (н. Erlang), которые можно считать более низкоуровневыми.

Еще присустсвует понятие количества кода и времени разработки. Так вот, высокоуровневые языки хороши тем, что имеют набор функций/методов для реализации самых используемых задач.

Проекты с установкой/удаленим модулей на лету можно считать программированием еще более высокого уровня.

Нужно ли знать что-то о низкоуровневом или интерпритации/компиляции кода? -, для хорошего/продвинутого программиста — да. Т.к. они чаще сталкиваются с ситуациями, которые требуют углубления в более низкие уровни (пример JS: начало выполнения интервалов и таймаутов)

И еще:
низкий уровень = строгая логика + оптимазации скорости, потребления ресурсов

высокий = понятность, сжатость кода + скорость написания продукта

хорошо это или плохо?

хорошо.

Нужно ли современному разработчику высокого класса понимать, как работает компьютер на уровне процессора и памяти?

того понимания какое есть у програмиста занимающегося «низким» уровнем не надо.

лишний и не нужный багаж знаний для реальной работы. базовых понятий достаточно.

Требует ли этого индустрия, или в 90% случаев можно обойтись пониманием структуры фреймворка?

индустрия требует быстрого решения задачи, которая принесет бабла.

то, что медленно/обобщенно/масштабируемо и т.д. реализовано в очередном фреймворке справляет с нужной индустрии лучше.

Может, раз индустрия так быстро развивается, то пусть отцы сидят на низком уровне, а бойцы пишут себе высокоуровневые обертки?

а когда тем отцам, которые сидят на низком уровне, надоест работа разработчика ПО, то кто будет за них все делать?

работы хватает в каждой нише и отцам, и бойцам. было бы желание.

а когда тем отцам, которые сидят на низком уровне, надоест работа разработчика ПО, то кто будет за них все делать?

работы хватает в каждой нише и отцам, и бойцам. было бы желание.

Угу, мне от до жути нравится С/C++, но почему то вакансий с меткой Junior я не вижу. Приходится учить всякую С-мивину чтоб хоть куда то взяли...

«Кто ищет, тот всегда найдет» ©

Я имел ввиду изобилие вакансий, а не одинокий случай. Если найдете вакансию по C/C++ где возьмут студента — низкий вам поклон и респект, как говорится.

Получается, что современному поколению разработчиков в большинстве своем не интересны низкоуровневые технологии и языки.

Так и есть. Как говорили ранее, порог вхождения очень высок, зарплаты, как правило, по-началу хуже, чем при использовании других технологий.

По сути низкоуровневое программирование ушло в embedded. Но большинство людей сидят в основном на микроконтроллерах, низкоуровневых вещей хоть отбавляй, часто имеет место смещение в сторону программируемой логики, etc. Но это все не то, мое IMHO.

Работу можно найти в аутсорсе, проекты все очень разные, но не факт что знаний будет достаточно, чтобы заняться чем-то другим из той же области. Либо на местном рынке, но это разные недо-девайсы, ККР, и прочая шелуха. По разным причинам на местном рынке такая работа считается какой-то дешевой и непристижной, зарплаты неадекватно низкие.

Энтузиастские разборы дизассемблированных программ нынче не в моде. И, судя по всему, в моде не будут.

А зачем? Это такая вещь, которая никому не нужна, кроме того, кто делал :)

Все хотят на новые технологии.

Чем больше уходят на новые технологии, тем больше у embedder’ов зарплата. Это единственная область, где зарплатного потолка практически нет.

Да, сколько embedded не развивай, все равно под все драйвера не напишешь.

Тут немаловажен тот факт, что новые embedded процессоры (не микроконтроллеры) выходят каждые пол года, причём от десятка производителей. Как правило, внутренности от 10% до 100% являются несовместимыми с предыдущими. Количество работ превышает количество эмбеддеров и системщиков на несколько порядков. Это по всему миру так.

Пока зарубежные университеты штампуют эмбеддеров в огромных количествах, украинские штампуют мейнстрим. Украине не только не светит откусить кусочек пирога, но даже не светит увидеть его издалека.

А я до сих пор иногда мечтаю об embedded... В один прекрасный день я забью на все эти дотнеты и пойду туда джуном :)

Пока зарубежные университеты штампуют эмбеддеров в огромных количествах, украинские штампуют мейнстрим. Украине не только не светит откусить кусочек пирога, но даже не светит увидеть его издалека.

Единственное что эта страна штампует так это безработных. Это я вам говорю как студент 6го курса КПИ. Программа безнадежно устарела, приходится или в авральном порядке переучиваться или самому все поднимать до нужного уровня.

Ну ясное дело, что надо уже работать с 3-его курса :). По поводу того, что программа устарела — и что? Ну была технология старая, стала новая. Под всех программу не подстроишь. ООП хорошо рассказали? Дискретку рассказали? Вышку? Довольно неплохой старт, я считаю. А окружение подтянет. С бомжами общаешься — бомжом станешь, а со специалистами — спецом. Ничуть не жалею о всех 6 курсах в том самом родном КПИ.

Программу уже давно не подтачивали и врятли когда нибудь подточат, если нашелся человек который толково рассказал ассемблер — считай счастливчик. О столь высоких материях как ООП и речи быть не может.

Смысл универа в том чтоб после выпуска быстро найти работу по специальности, а не бегать переучиваться и подтягиваться.

У вас что, даже базовые принципы ООП не рассматривали? Что за факультет-то такой? Менеджмент небось :).

Нет, мед. системы (программирование + инженерия + немного медицины). Есть много друзей с ФИОТа и ИПСЫ, там тоже не в восторге от программирования.

Был бы на менеджменте или ему подобному вообщеб не парился :) .

а где есть вакансии, и как узнать, чем они обычно там занимаются?

Мы, к примеру, нанимаем, много вакансий: www.qnx.com/.../opportunities . Реально вакансий гораздо больше, т.к. только в моем отделе постоянно ищут различных driver developer’ов уже долгое время. По большому счёту хотим увеличиться вдвое.

Я могу сказать только за Graphics Team, если человек толковый, то контора либо обеспечит переезд, либо работу в Украине по контракту на различных условиях. Первое предпочтительно.

а есть возможность удаленки, допустим на 10 часов в неделю, чтоб понять интересно/нет, да и вообще понять чем вы занимаетесь, чужие баги правите или код пишете.

и как попасть на собеседование?

а есть возможность удаленки, допустим на 10 часов в неделю

Думаю, что это зависит от того, что Вы умеете. К примеру, драйвера делать 10 часов в неделю можно месяцами, поэтому врядли так возможно будет сделать.

чтоб понять интересно/нет, да и вообще понять чем вы занимаетесь

Так двумя словами и не опишешь. В принципе очень многим, практически всем :)

чужие баги правите или код пишете.

Баги свои правим :) В том части предприятия, где я работаю (custom engineering), всё зависит от желания заказчика. Если заказчик хочет перламутровые пуговицы, а у нас есть только зелёные, то переделываем то, что есть. Это, как правило, своё, но написанное ранее. Если хочет что-то особенное, то часто бывает, что с нуля.

и как попасть на собеседование?

Там в каждой вакансии есть внизу Click here to submit your resume online. Если разработка драйверов, то можно через меня. Я отправлю резюме сразу ответственному product manager’у. Если связано с разработкой различных графических драйверов, то желательно через меня :)

Чем больше уходят на новые технологии, тем больше у embedder’ов зарплата. Это единственная область, где зарплатного потолка практически нет.

Вливания «свежей крови» практически нет, а ресурс с каждым годом не молодеет. Рискуем в один прекрасный момент попасть в ситуацию где спрос огромен, а опытные работники уже «отошли». И что тогда? А наберем молодняк. Ок, набрали, а они вам такое понаписывали ...

Но в embedded, как в ссылку, отправлять насильно тоже не будешь :)

Ещё надо не забывать что львиную долю низкоуровневого программирования никто не отдаст на аутсорс — как можно аутсорсить разработку драйверов для железа которое только через пару лет выйдет на рынок? Ну и доверия больше у американцев выпускникам американских вузов.

Отдают такое на аутсорс, причём в огромных количествах. А вот nVidia не даёт ничего даже для старого железа :) Если честно, то мое мнение, что это одна из компаний, в которой security стоит на самом первом месте. И таких компаний не очень много.

Писал с недо-девайса, поэтому был краток. Например, я работал с процессорами от Freescale, Intel, Renesas за год до анонса ;)

Получается, что современному поколению разработчиков в большинстве своем не интересны низкоуровневые технологии и языки.

Проблема в том что возможностей мало, поэтому их и не видно, хотя они есть.

Нужно ли современному разработчику высокого класса понимать, как работает компьютер на уровне процессора и памяти?

Интересный факт: недавно один знакомый доказывал что это все нах не надо (и железки, и лиспы) и сейчас без этого всего можно быть супер-пупер профи, ирония в том что он всякую низкоуровневую хну довольно хорошо знает :) .

Естественно, потому и супер-пупер :). Но нужно ли именно молодому бойцу влезать сначала в глубокую теорию, чтобы потом подняться на высокий уровень языков? Скорее всего, лучше всего по-немногу.

Но нужно ли именно молодому бойцу влезать сначала в глубокую теорию, чтобы потом подняться на высокий уровень языков?
Проблема в том что, если это не сделать молодому бойцу, то старому не поможет.

Я могу ошибаться, но мне кажется, что

Энтузиастские разборы дизассемблированных программ

является примерно таким же сакральным занятием, как Идти В Гараж Делать Машину, особенно распространённое среди владельцев потрёпанных жигуляторов, волжан, а также иномарок прибалтийской сварки. Причём в последнее время оно также медленно, но неумолимо идёт на спад.

Хорошо это или плохо? Jedem das Seine.

Тем не менее это все не мешает настоящим любителям авто заниматься автотюнингом или содержать СТО — неплохие денюжки, кстати.

То же саме и с дизассемблерами: ниша есть, кому надо — зарабатвают хорошие денюжки. А мейнстримом это никогда не было.

Підписатись на коментарі