Comments: |
Проблема на мой взгляд в том, что программное обеспечение обновляется сейчас чуть ли не быстрее процессоров. Конечно есть старые отточенные библиотеки, но какой процент программ их используют? А там, где нужно быстродействие - всё каждый раз переписывают под новые фичи. Каждая новая версия SSE - и весь старый мультимедийный код летит в помойку.
Что-то курили? Ядро Windows претерпевает в основном косметические изменения. Всерьёз поменяли, пожалуй, только видеоподсистему.
Пробежался поиском, но не нашёл, где в ветке шла речь о ядре Windows.
Это пример. Вся "классика" если и меняется изнутри, то это простым смертным неведомо: photoshop, office, и т.д. Ядро Linux туда же. Казалось бы, появление GPU должно всерьёз сменить конценпцию ядра ОС, но воз и ныне там. Есть отдельные экспериментаторы, использующие GPU для SSL и роутинга, но частью ОС это всё не станет ещё долго. Программки "одного дня" -- да, переписываются постоянно, но когда это было не так?
таки я однажды лет 10 назад "ахальти ота". Меняла малюсенький кусок в чужой и весьма обширной программе - и она начала лажать, причем в фичере, который совершенно и абсолютно не зависел от моих изменений! В конце концов установила, что лажа шла от одного поля в совершенно не моей и нетронутой мною структуре, которое, будучи инт32, торчало посередь полей инт16, и в новой версии оказалось на адресе, не делящемся на 4.
(глядя со стороны) - а нельзя ли как-то автоматизировать процесс поиска таких багов?
From: A R 2014-01-02 03:20 pm
huh? | (Link)
|
Просто никогда не использовать 'packed' структуры и нормальный компилятор все расставит на свои места - ну потребуется больше памяти в самом самом крайнем случае.
Использование 'packed' позвольяет обойтись без сериализации/де-сериализации не задумываясь о деталях но создает тонну головной боли при миграции с одной архитектуры на другую.
Edited at 2014-01-02 15:21 (UTC)
ну на всяких ДСП памяти почему-то всегда в обрез.
да такое-то и дотошный компайлер поймать может, просто обычно народу влом читать 100500 ворнингов, если всё работает. А потом меняешь че-нить маленькое - а компилируешь-то уже только поменянный файл! Мораль: вредно отключать или еще как-нить игнорировать ворнинги. Они иногда умный вэщь говорят.
From: A R 2014-01-02 04:23 pm
Huh? | (Link)
|
Оказывается есть на свете места где компилируют без -Werror или его эквивалента.
Настоящие клубы самоубийц.
Edited at 2014-01-02 16:24 (UTC)
ну вот я получила допустим биб-ку от человека, который вручную оптимизировал так, что никакой оптимайзер не доплюнет (тем более что в оптимайзере баги). Но на ворнинги он плювал принципиально. Ну то есть как бы имел право - если он архитектуру знал лучше оптимайзера и отдавал себе отчет в том, что он делает.
From: A R 2014-01-02 04:55 pm
Re: Huh? | (Link)
|
1. Это не о программистах а о корпоративной политике.
2. Я не никогда не поверю что человек досконоально разбирающийся в архитестуре не знает как подавить false positive warnings.
3. И еще я не поверю что человек плюющий на warnings может разбираться в архитектурах. С другой стороны может это Российская специфика.
Edited at 2014-01-02 17:03 (UTC)
э... как Вы угадали? Я-то в Израиле, но автор биб-ки в России.
В архитектурах, может, и разбирается, а в процессе промышленного производства софта — нет. Просто хочется взять и уе Довольно часто встречаются такие узкие специалисты, приходится с ними работать, ашоделать.
cache thrashing, IPI, lock contention, и всё такое нынче гораздо больше головной боли создают, как мне кажется...
ESR почему-то считает, что в наше время все разучились это делать, или просто новые программисты на Си не знают об этом, а помнят одни "старички". Я не вижу оснований так считать
никто не говорит, что "новые" хуже или тупее "старичков".. но надо признать, что Си вытесняется из мэйнстрима (20-30 лет назад) на уровень инфраструктуры, которой занимаются все меньший процент людей в этой индустрии .. а эта самая инфраструктура уже так придумана/построена/отлажена, что воспринимается как данность, как вода в кране или электричество в розетке .. соответственно, все меньший и меньший процент программистов понимают, как оно "там" работает, и владеют техниками написания "там" .. типа того-же выравнивания структур ..
Меньший процент не потому что все придумано и отлажено, а потому что уже существующая инфраструктура позволяет делать много гитик не задумываясь как все устроено внизу.
Именно так, и, увы, задумываться находится мало любителей. На лекции о новой архитектуре процессора, объединяющей достоинства DSP и general purpose CPUs, ходит от силы пара десятков человек.
Архитектура процессора меняется раз в несколько часов, от того что я пересаживаюсь на ноутбук, а затем выхожу из дома с телефоном.
Это неважно; задумываться, как устроена любая из них, и как ее можно было бы улучшить, находится мало желающих. В разработке процессоров нет легких денег, рекламу там запихнуть некуда.
Да. Я тоже откусил от кактуса . Иногда не так страшно выравнивание, как то, что остается в щелях.
Ну, когда я работал в DrWeb, мы о выравнивании думали всегда. Просто потому, что иначе приходилось сутками не вылезать из дебаггера. А учитывая специфику того, что мы писали, отлаживался как правило уже крэшдамп.
Я думаю, если что и поменялось, так как раз в сторону большего знания низкоуровневых подробностей C и C++. Лет 20 назад на C писали множество прикладухи просто потому, что это был мейнстрим, были библиотеки, было real programmers write in C. Ну и еще лет 10 после этого мейнстримом был C++. Но сейчас на них в основном пишут те, кому это действительно надо, и работа с бинарными структурами, часто железными, входит в число причин выбора именно C/C++. Т.е., не знают этого разве что совсем еще начинающие или те, кто вообще на них писать не хочет и не любит, но вот пришлось явщику/шарповику чуть повозиться с чужим кодом.
Ссылка на HN ведёт на обсуждение статьи про Сноудена.
Спасибо, сейчас исправлю.
Напомнило динамические языки на JVM. | |