1. К черту!
Когда я был маленький, то на меня снизошла милость божЫя и ниспослала мне две книжки. Одна книжка была про бейсик для студентов каких-то там ВУЗов, а вторая - «Паскаль в иллюстрациях». По одному из абзацев первой книжки я в принципе научился программировать в пятом классе - там был мозголомающий отрывок с программой, заставляющей нолик летать по экрану, отталкиваясь от стенок. Вторая книжка, отданная мне соседом-алкашом, познакомила с алгоритмами. На дворе стояли 90-е — начало компьютерной эры человечества. Компьютера у меня при этом не было — я видел его пару раз в неделю на компьютерном кружке, ведущей которого была вчерашняя или даже сегодняшняя студентка, отпирающая и запирающая дверь — большего от неё нам и не требовалось.
И этот исторический экскурс в чертоги памяти заставил меня поразмышлять на тему возможности программировать без алгоритмов. И я подумал, что прекрасно делал это, и до сих пор продолжаю подобным заниматься, хоть и прошло с тех давних времён тридцать лет и три года.
В конце концов я определил для себя, что алгоритм — это такой порядок действий, который позволяет решить задачу быстрее, чем самый простой - «наивный» - способ.
В качестве примера давайте рассмотрим элементарный алгоритм сортировки. Наивным способом детвора в детском саду собирает пирамидку. Ну как малыш это делает? Правильно, берет самую большое колечко и нанизывает его на палочку. Потом из оставшихся колечек берет следующее самое большое. Ну и так далее. Можно ли считать такой наивный способ «алгоритмом»? Ну, наверное можно, но такой способ даже в школах не проходят как мне кажется. При том я видел взрослых людей, которые этот способ даже сформулировать не могут. Учил знакомого юриста, желающего войти в ИТ, но он мне не смог ответить, как бы он отсортировал массив, хотя я приветствовал любой способ и задавал наводящие вопросы. Получается, что ребёнок трёх лет умнее взрослого с высшим образованием? Видимо…
Давайте рассмотрим алгоритмы сортировки, которые понапридумывали разнообразные математики. Ну сразу же на ум приходит тот самый пресловутый «пузырёк». Можно ли научить его ребёнка о трёх годах, который собирает пирамидку? Элементарно! Просто попросить его переложить колечки попарно, чтобы слева оказалось колечко меньше, а справа больше. Я проверил на четырёхлетней деточке за неимением под рукой трёхлетки — все сработало. Но когда я вижу взрослого дядю, который не может в это «вдуплить», я огорчаюсь мыслью, старой как сам мир: «куда, собственно, он (мир) катится?»
Ну ладно, расскажу про своё житие дальше. После школ я пошёл работать. Но т. к. открывал с ноги дверь кафедры информатики в институте переподготовки педагогических кадров, то работу мне подыскали легко и не принужденно — лаборант компьютерного класса в местном педагогическом университете. По соседству с кафедрой располагалось научно-исследовательское бюро, в котором на деньги соросов и иже с ними было накуплено древнего компьютерного барахла, видимо списанного где-то. И на нем крутились программы, на которые без слез не взглянешь. Суть всего этого древнего железа и софта была в обеспечении работы лаборатории дендрохронологии.
Ну не сказать, что наши западные партнёры задарили нас совсем уж мамонтовыми какашками, но комплекс измерения был на базе крайне древней ХТ с монохромным зелёным монитором, а ввод данных осуществлялся нажатием кнопки, когда под микроскопом поздняя древесина сменялась ранней и наоборот. Девочки-лаборантки крутили «крутилку», керн, начищенный зубной пастой для того, чтобы древесные кольца были хорошо видны, двигался вдоль оси мкроскопа, девочки смотрели в этот микроскоп и нажимали «большую красную кнопку» при достижении границы. Старый ХТ выдавал файл формата «Tucson sample» (видимо, по названию университета), который потом дискетами переносился на стоящий рядом 386-й, к которому был подоткнут широкоформатный матричный Epson, в который, в свою очередь, был заправлен рулон кальки. Для печати таким образом полученного временного ряда использовался Quattro pro — этакий эксель под MS DOS. Умный математик с Уральских гор нарисовал для него какой-то скрипт, но чтобы он сработал, временной ряд надо было из формата «Tucson sample» превратить в формат «prn». Разница была существенна — в американском формате в строка начиналась с имени серии (6 букв вроде бы), дальше через ТАБ (оформленный пробелами) шли 10 чисел с показателями (1-999), потом следующая строка с именем серии и числами. Где-то там был еще и год, но я уже забыл, где. А формат «prn» с Уральских гор начинался с года и представлял из себя столбик показателей, заканчивающихся значением «999».
Ну вот и попросили меня для начала так сказать научной деятельности сделать конвертор из формата Туссона в формат Урала, а то девочки теряли по две недели времени, превращая одно в другое путём нажимания энтеров, делитов и «999».
Можно ли решать такую простую задачу, не особо разбираясь в алгоритмах, но умея программировать? Конечно! Все методы, которые я использовал, мало отличались от того, что делали девочки, стирая пробелы, переводя каретки и завершая файл тремя девятками. Здесь алгоритмы были не нужны. Не нужны они были и далее, когда начались хотелки о предварительной датировке образцов друг относительно друга (коэффициент синхронности), не нужны они были и после того, когда математика вышла за пределы школьной программы и достигла функций корреляции, стандартного отклонения, коэффициента чувствительности и прочего, что решалось предельно наивно проходом по массиву значений и аккумулированием результата. Поэтому когда мне говорят, что программисту нужна математика, то я прошу, обычно, показать мне конкретную функцию, а не лить в уши общими фразами.
Я работал программистом в научной лаборатории уже третий год, но так и не встретил надобности в алгоритмах. Неужели все так плохо? Неужели программисту и правда не нужны алгоритмы? Ведь я, не понимая ни в математике, ни в программировании, за условные три копейки двигал вперёд и вверх российскую науку. И софт, который я делал, был куда более юзер-френдли, чем американский (библиотека DPL доктора Грызино-Майера (Grissino-Mayer, H.D.)) и даже немецкий (TSAP, который толкал за 3 косых Франк Ринн). Американцы осилили командную строку, немцы сделали интерфейс. Но оба продукта с трудом читали даже свои собственные файлы, не говоря о чужих. А я за три года сделал вьювер, который интегрировался в Нортон Коммандер, который по кнопке F3 визуализировал временной ряд, после чего по кнопке F4 отправлял его на кальку с помощью поскрипывающего Epson’а. Он умел предварительно датировать набор серий из формата «Tusson», умел читать кривой «Tusson», сохраняемый из немецкого TSAP, который сам его обратно прочитать уже не умел (как минимум три последних версии программы на 1999-й год — точно не умели), умел он читать и уральский «prn», и родной немецкий формат «Heidelberg», отличавшийся большим заголовком с кучей информационных полей.
Периодически дорабатывая вьювер (добавляя новые фичи), я занялся разработкой CDS — большой и красивой программы для комплексной работы с временными рядами. И да, там я тоже не использовал другие алгоритмы, помимо наивных. Запускался CDS с картинкой из файла, поверх которой звучала музыка, выдранная из второго варкрафта (при нажатии на замок рыцарей). Дальше появлялись знакомые всем две панели аля Нортон Коммандер, которые на 146% реализовывали функции файлового менеджера (копирование, переименовывание, удаление и все прочее, что можно было сделать с файлами). Система позволяла подключать внешние программы для просмотра и редактирования файлов в соответствии с их расширением, помимо прочего имела возможность запоминать каталоги — этакая панель избранного. Мелкомягкие явно свистнули эту идею у меня. Помимо прочего, программа делала все то, что делал вьювер, но уже не в режиме 640х480х4 (16 цветов), а в режиме VESA 800х600х16 (65536 цветов). Ну и куча математики и статистики, визуализация графика в обычной и полулогарифмической шкале, визуализация автокореляции.
И, поверьте, все это было сделано наивными методами.
Дальше я написал достаточно большую программу для работы с флористическими данными. Систему назвали FLORIST. Она позволяла считать коэффициенты родственности флор по десятку коэффициентов с самого простого коэффициента Джакара до коэффициента Сьёренсена-Чекановского. И опять мне не понадобилась ни математика, ни алгоритмы — за меня считал компьютер, и, поверьте, делал это лучше человека и, разумеется, гораздо быстрее.
И да, весь этот софт не тормозил вот вообще. Даже автоматическое распознавание 39-ти различных дендрохронологических форматов происходило куда быстрее, чем проведение документа в современных 1С на куда более продвинутом железе. И да, никаких алгоритмов, никакой математики — обход массивов данных с по большому счёту четырьмя арифметическими действиями. Если у кого-то язык повернётся назвать это математикой, то можете первыми кинуть в меня какашкой.
И да, писалось все это на Borland Pascal 7.1. CDS работал в защищённом режиме под DOS, остальные продукты работали в обычном режиме. Я не использовал чужие библиотеки — если только работу с мышью. Стек окон в текстовом режиме был написан на ассемблере, obj-файлы которого импортировались в паскаль. Также на ассемблере был написан механизм печати графиков на принтере — я его ещё для вьювера написал.
И т. к. это все писалось на паскале, то оно не взлетело в Туссоне, т. к. у них там стояли более быстрые компьютеры, а паскаль на быстрых компьютерах не умел — валился с делением на ноль. И да, мы это пропатчили, но я уже свалил с трёх институтских копеек на три рубля в программирование на 1С, т. к. другое программирование в нашей деревне было особо никому не нужно. Не, иногда я помогал друзьям и знакомым курсовики писать, дипломы, диссертации даже, но за 1С платили куда больше, а дома жена…
2. А всё-таки они вертятся!
И вот наступила эра винды. Вообще, она наступила раньше, но до меня дошла ближе к 00-м. В первой конторе, куда я вообще пошёл работать менеджером, меня взяли программистом, т. к. у директора хватило ума поинтересоваться, чем я вообще занимался-то. Ну а у меня хватило ума ответить, что программы писал. В итоге я познакомился с кривой и косой 1С 6.0, деланной явно пальцем, но не ясно, каким. Потом с 7.7 и далее. И до сих пор мне не нужны были никакие алгоритмы — все продолжало решаться наивными методами, а для сортировки можно было использовать соответствующие методы.
А потом я вернулся в университет. Там мой приятель уже нехило так понаписал на С++, но я, будучи верен паскалю, начал творить на Delphi. И вот тут, внезапно, мне понадобились эти чертовы алгоритмы.
Фактически, я занимался продолжением FLORISTа — этакого пакета для классификации и исследования биоразнообразия региона. К этому моменту тот человек, который занимался дендрохронологией, стал работать в организованной лаборатории биоразнообразия. Они там провели большую работу по формированию классификатора и засунули в него около 50к видов различных растений, а может быть ещё грибов и лишайников. И с первым, с чем я столкнулся, так это с тем, что 50к видов грузились не быстро, т. к. одновременно грузились ТРИ классификатора: вид, род и семейство. И если виды нужно было загрузить все, то семейства и роды у разных видов могли совпадать. Вот тут-то мне и понадобилась книжка «Паскаль в иллюстрациях», которую, как вы несомненно помните, подарил мне сосед-алкаш.
Попытка решить загрузку наивным методом упёрлась в то, что классификатор грузился минуту. Т.е. грузился вид с его родом и семейством, потом в коллекции семейств и родов искались соответствующие род и семейство, и если чего-то не было, то в коллекцию добавлялись новые род, семейство или и то, и другое.
И так, дамы и господа, встречайте! Первый алгоритм, который мне понадобился при разработке программного обеспечения — это «бинарный поиск», т. е. «поиск методом листания словаря» (открыли посредине, посмотрели, если буковка больше, то вправо на пол-оставшегося, если меньше — влево, ну и пока не найдем). Одна загвоздочка — список должен быть упорядочен. В итоге загрузка классификатора с минуты ускорилась до долей секунды на достаточно древнем третьем пентиуме.
Следующий раз, когда мне понадобились алгоритмы, наступил через 10 лет после этого замечательного случая с двоичным поиском — в остальном хватало наивных вычислений. Это был алгоритм рюкзака. Подробности не расскажу.
Третий раз, когда мне пригодилось знание алгоритмов, произошёл в 2018-м году, когда ФМС ещё предоставляло на своём сайте файл со стопиццот миллионов недействительных паспортов. И эта история прям вот кричит о том, что алгоритмы лучше знать, чем не знать. Тут как раз подробности прям вот топят за то, чтобы разработчики иногда думали мозгом. А то, что ФМС перестала предоставлять этот файл, выводит раскрытие этих подробностей за пределы NDA.
История была такая. Я сидел на своём рабочем месте, клацал по кнопкам, не особо вдаваясь в алгоритмы и продолжая решать большую часть работы наивным методом. Нужно сводимость — нате вам градиентный спуск, который я бы не стал называть алгоритмом, т. к. оное доступно тем же трёхеткам, неоднократно наблюдавшим, как мячик на неровном полу с помощью сил притяжения находит локальный минимум. Нужен расчёт себестоимости — сложим затраты. Какие тут алгоритмы? Может быть XBRL, которым я в основном и занимался, требует алгоритмов? Нет — это просто текстовый файл с уникальными контекстами, а проверить на уникальность — способов масса, наивные среди них тоже есть и не менее эффективны.
И вот сижу я, скучаю, и внезапно узнаю, что добрые разрабы 1С решают задачу загрузки сотни миллионов чисел наивным методом — просто засовывая это в таблицу СУБД. Знаете, сколько занимает это на 1С? Наивно на тех серверах, которые у нас были, это занимало сутки. Ага-ага. Сутки прошли — пора грузить новый файл. Зато железо загружено на 100%. Дальше программисты начали думать, напрягли лучших из лучших. И решили грузить по 50к. Не помогло — при каждой вставке СУБД формировала индекс для номера и серии. И тут программистов посетило первое озарение — нужно сначала отсортировать, а потом грузить! Ура, стало работать за 8 часов: 4 часа сортировало, 4 часа грузило. Потом пришел я и сказал: а давайте попробуем многопоточно! Ура, 4 часа. Но если первый миллион грузился без блокировок, то последний миллион падал 9 раз, прежде чем загрузиться.
Итак, наивным методом на платформе 1С решить не удалось. Начали грузить напрямую в SQL. 30 минут — и все дела. Я предложил засунуть в Redis — 5 минут, куча памяти. Но 1С не умела с Redis вот так вот прямо, да и у многих клиентов не было такой инфраструктуры.
А потом я вспомнил про алгоритмы. Ведь 4 цифры серии (0-9999) и 6 цифр номера (1-999999) — это не фиг чего вариантов, поэтому можно сотворить битовую матрицу в 10 миллиардов бит (1,2 Гигабайта, что для современного компьютера ниачём). Но т. к. половина серий еще не выдавалась, то вполне хватало и половины от этого объёма, если выделять память на каждую серию отдельно.
В итоге я написал прототип на С, коллеги взяли идею и реализовали на 1С. И если на С из кеша ОС битовая матрица формировалась за какую-то долю секунды, то на 1С достаточно мощный компьютер формировал её за 8 минут. 8 часов и 8 минут — хорошая оптимизация, да?
Заключение
Программист вполне может обойтись и без математики, и без алгоритмов. И при этом он может быть очень хорошим программистом, владеющим обширным стеком технологий. Я в своей работе по большому счёту без всего этого обхожусь, ибо не считать же знанием математики способность создать программу, вычисляющую стандартное отклонение или что-то в этом духе. Математику пусть знает заказчик или бизнес-аналитик — вот им она полезна, т. к. позволит правильно поставить задачу. А программист должен уметь массив обойти какой, дерево, может быть связанный список. Этого достаточно, чтобы не пропасть в своих перекладываниях джисонов.
Но всё-таки иногда знание алгоритмов помогает увеличить скорость работы продукта на несколько порядков. И достаточно одного человека в команде, который был бы способен увидеть решение, поразмыслив над тем, какой алгоритм сюда вписать. И давайте дадим ему медаль...
Подписывайтесь на мой канал, ставьте лайк, ... (с)
Комментарии (162)
Algrinn
15.12.2023 19:55Нужны ли алгоритмы? Есть такая пословица: "Заставь дурака Богу молиться, так он себе лоб расшибёт". Нужны, но в меру и при умном использовании, а не на собеседовании давать и решать эти алгоритмические головоломки. Чтобы не увеличивать количество ненависти в мире. Там была когда-то такая Матрица Компетентности Программиста, в Гугле можно найти, там написано сколько всего программисту желательно знать ещё кроме алгоритмов.
Chelyuk
15.12.2023 19:55Я вам блольше скажу. Алгоритмы, нынче, даже у тестировщиков на собеседованиях спрашивают.
Algrinn
15.12.2023 19:55Спрашивают это одно, но бывают случаи когда прямо на собеседовании дают головоломки написать код на красно-чёрно-серо-буро-малиновое дерево. Могли бы просто говорить: "Наша дев команда не хочет раздувать штат. Это менеджер хочет раздуть штат, чтобы потом провести сокращения"
alelam
15.12.2023 19:55Есть же и другой вариант - прямо на собеседовании понимают, что вы ничем не выделяйтесть из тех х кандидатов, что с утра успели на вашем месте побывать, вот вам и дают шанс это сделать:)
Kreastr
15.12.2023 19:55Но ведь выделяющийся кандидат потом вероятно попросит себе и выделяющуюся зарплату? Деньги-то бизнес понимать должен. Или shut up and take my money?
saboteur_kiev
15.12.2023 19:55Автора статьи я бы взял.
Если в проекте есть 1-2 человека с хорошей математикой, человек разумный всегда сможет с ними проконсультироваться, если вдруг перформанс будет недостаточен.
Но именно то подход, который применял автор - показывает адекватность подхода. Надо решить - решили. Надо оптимизировать - попробовали. Главное, что программист понимает суть поставленной задачи от начала и до конца, а не "я свою джиру сделал, а дальше пусть ее кто-то интегрирует".
Адекватный человек вовремя догадается, что может быть вот тут нужен алгоритм, или хотя-бы консультация со знающим человеком.
Правда раньше можно было описать проблему на реддит/SO и получить в ответ "юзай вот такой алгоритм", и уже про него отдельно прочитать. А сейчас можно спросить у chatgpt.
Умея программировать, изучить и реализовать конкретный математический алгоритм не составит слишком большого труда. Поэтому те, кто прям крутят математикой налево и направо, в большинстве случаев востребованы там, где пишут специализированный софт, где пишут библиотеки, где пишут кодеки и движки. А не просто прикладной софт.p.s. В свое время еще на Ansi C, придумал двусторонний список, ибо надо было хранить кастомный структуры, и сперва для вставки нужного объекта, проходил вперед, находил и вставлял, потом подумал что можно же сделать ссылку назад, получился двухсторонний список, и вставки/удаление упростились до элементарной операции. Про сложные алгоритмы не думал, просто писал игрушку еще в школе.
sena
15.12.2023 19:55Любая программа это алгоритм, поэтому любой программист может сам свой алгоритм придумать. Просто некоторые особенно удачные и часто неочевидные алгоритмы систематизированы и поименованы. Нужно ли знать наизусть, как они сделаны? Да нет конечно. Но как минимум надо просто знать о их наличии (хотя бы какого рода бывают) и где их искать если что, уметь отличать NP полные задачи, хотя бы замечать экспоненциальную сложность. Понимать проблему останова и т.п. То есть какая-то минимальная база важна.
Ну и по-моему, (здесь уже не уверен, после такой статьи-то) любому программисту понимание работы некоторых алгоритмов (особенно когда потратил кучу времени пытаясь решить самостоятельно) может доставить истинное наслаждение. Я, например, однажды достиг катарсиса, разбираясь с алгоритмом Брезенхема для окружности.
Wesha
15.12.2023 19:55Именно. " ...делали девочки, стирая пробелы, переводя каретки и завершая файл тремя девятками. Здесь алгоритмы были не нужны." — как это "не нужны"??? Девочки именно что следовали алгоритму ("набор инструкций, описывающих порядок действий исполнителя для решения определённой задачи"): "стереть пробелы, перевести каретку, завершить файл тремя девятками, повторить".
Anarchist
15.12.2023 19:55Хотите задачку? Попробуйте алгоритмы Брезенхема для плоскости, замощённой не квадратами, а шестиугольниками. Для прямых решение получилось интересное. А как для окружностей?
starik-2005 Автор
15.12.2023 19:55Кстати, по поводу алгоритмов Брезенхема, то в моем тогдашнем софте как раз использовался похожий алгоритм построения линий, суть которого сводилась к вычитанию из большего смещения меньшего, и если огребался флаг знака (значение уходило в минус), то к нему прибавлялось большее смещение, а к курсору прибавлялась единица по Х и У. Если же значение в минус не ушло, то менялась только одна из координат - по большему смещению. Вычитано это было бегло из какой-то книжки о графике, после чего уже самостоятельно было придумано, что начинать вычитать надо не из целого смещения, а из его половины.
Ну и про окружность, то классе в седьмом-восьмом я обнаружил, что квадрат следующего числа равен квадрату предыдущего +2N+1, где N - само число. Т.е. квадрат пяти равен квадрату четырех плюс четыре умножить на два плюс один: 16 + 4 * 2 + 1 = 25. В итоге я придумал, как целочисленно построить круг. Ну и реализовал это на ассемблере. А потом еще из-за соотношения сторон, не равного единице, делил это на три и умножал на два по У. Интересное было время! А не так давно игрался с китайским дисплеем с алика за три копейки на электронных чернилах, скачал у вендора с гита драйвер для lolin32, и нашел там кучу целочисленных алгоритмов для графики: точки, линии, круги, элипсы, дуги... Так что сейчас кружок нарисовать - это не к алгоритмам, а к библиотекам..
Politura
15.12.2023 19:55Скажу по секрету, только никому не говорите: когда пишешь какую-то функцию, пусть и по перекладыванию джосона, пусть на языке 1с, не важно, всегда пишешь алгоритм. Чисто по определению алгоритма.
Хотя понятно, что речь не об этом. Как по мне, знание базовых алгоритмов, понимание их алгоритмической сложности и практика решения алгоритмических задачи всегда полезна, и особенно перекладывателям джесонов. Ибо именно в их среде легко найти тройные вложенные циклы где в самом внутреннем цикле будет вызов какого-нибудь метода, типа, ЧегонибудьService.getЧегонибудьDetails(), который делает запрос, к базе, или лезет во внешние ресурсы, при этом всегда один и тот-же и мог-бы быть вызван за пределами цикла и просто данные потом использованы в этих циклах.
Я видел это миллион раз в разных вариациях. У самых сеньеристых сеньеров. Если же имеешь практику решения каких-нибудь литкодовских задачек, не на отвали, а для себя, то как-то привыкаешь следить за алгоритмической сложностью алгоритмов, которые пишешь, или ревьюишь у других, и тем самым делаешь мир в целом чище.
:)
starik-2005 Автор
15.12.2023 19:55В программировании на 1С запрос в цикле считается моветоном не только лишь всеми - факт. Начинающих падаванов вот прям зомбируют, чтобы они это не делали.
А по поводу алгоритмов, то любой список действий - это да, алгоритм. Но я указал, что под алгоритмами в рамках этой конкретной статьи я считаю такие, которые делают дело быстрее, чем наивный подход.
Zenitchik
15.12.2023 19:55У меня такое наивное подозрение, что запрос в цикле может породить квадрат...
Wesha
15.12.2023 19:55Квадрат — это плохо!
Стучать будет!
— А почему у поезда колёса круглые, но стучат?
— Формулу для площади круга помнишь?
— Ну да, пи эр квадрат...
— Ну вот квадрат и стучит.
SilverHorse
15.12.2023 19:55Там не квадрат, там намного хуже может быть чисто за счет диких накладных расходов на эту операцию. Любое обращение к СУБД, хоть проиндексированной и оптимизированной в хлам, по определению будет намного медленнее работы с заранее полученной таблицей значений в памяти. Не говоря уже о том, что запрос запросу рознь, и одно дело читать какие-то служебные флаги из регистра, и совершенно другое - грести тяжеленные данные из табличных частей документов пополам с регистрами накопления, где объем одной выборки может измеряться шестизначным числом.
CorwinH
15.12.2023 19:55Любое обращение к СУБД, хоть проиндексированной и оптимизированной в хлам, по определению будет намного медленнее работы с заранее полученной таблицей значений в памяти.
Вообще-то, нет. Иначе, для ускорения работы скачивали бы всю БД в память.
nronnie
15.12.2023 19:55Иначе, для ускорения работы скачивали бы всю БД в память.
Redis так и делает, например :)
SpiderEkb
15.12.2023 19:55Если объем данных в БД превышает физический объем доступной памяти (что обычно и бывает, причем, превышение как минимум кратное, если не на порядки), то... Дальше варианты - виртуальная память со свопом, одноуровневая память где что-то располагается в памяти, что-то на диске.
Так или иначе, обращения к диску все равно будут. И профит тут неочевиден.
ptr128
15.12.2023 19:55Дальше варианты - виртуальная память со свопом, одноуровневая память где что-то располагается в памяти, что-то на диске.
В подавляющем большинстве БД, кроме оперативных и мастер данных, которые и так быстро оказываются в кеше, есть еще старые и архивные данные. Поэтому, на практике, деградация производительности наблюдается только при доступе к таким редко используемым данным.
И Вы забываете самое главное. Даже Redis вынужден сбрасывать свои данные на диск. А уж ACID этого просто требует.
превышение как минимум кратное, если не на порядки
На порядки - это должна быть уж очень специфичная СУБД. Типовое требование - объем памяти 20-50% от размера БД, в зависимости от задач.
Так или иначе, обращения к диску все равно будут. И профит тут неочевиден.
Для тех, кто давно пользуются даже обычными РСУБД, не говоря уже о Hana или ClickHouse - очевиден. Хорошо продуманная стратегия кеширования и спекулятивное чтение творят чудеса. Я так чаще упираюсь все же в ядра CPU, а вовсе не в производительность СХД (точнее 40-гигабитки к СХД, так как сам СХД способен на большее).
Типичная картина, когда запрос ограничен 24 ядрами из 32-х:
SpiderEkb
15.12.2023 19:55Мы про кеширование, или про полную загрузку всей БД в память?
Началось-то с
Иначе, для ускорения работы скачивали бы всю БД в память. @CorwinH
и
Redis так и делает, например @nronnie
ptr128
15.12.2023 19:55Я потому и упомянул Hana с ClickHouse, показав, что тут все далеко не однозначно. И если Redis бездумно грузит в память действительно всю БД, то другие СУБД требуют загрузки в память только той части БД, которая необходима, позволяя не грузить в память ту часть БД, которая просто не нужна для текущих запросов. По той простой причине (скрин выше), что это не дает никаких преимуществ.
Redis может позволить себе грузить все базу данных в память, только потому, что он не поддерживает SQL. А поддержка SQL, хочется Вам этого или нет, требует создания временных объектов плохо предсказуемых размеров. В том числе в разы превосходящих суммарные размеры таблиц, участвующих в запросе.
Ну и все же некорректно сравнивать Redis, не поддерживающую ACID, с ACID СУБД. WAL/TransactionLog тоже может расти до размеров, превышающих размер данных в БД.
Neraverin
15.12.2023 19:55Я бы аккуратно поспорил на тему бездумности. Мб вы просто с такими задачами не сталкивались. Есть масса чисто in-memory DB, в том числе с ACID и поддержкой SQL. В некоторых задачах ждать пока данные для запроса поднимутся с диска в память недопустимо.
starik-2005 Автор
15.12.2023 19:55Да даже в MS SQL можно создать таблицы (а может даже целые базы - не упомню), которые целиком и полностью в памяти хранятся.
А вот и цитата с мелкомягклого сайта относительно ACID:
Таблицы, оптимизированные для памяти, по умолчанию полностью устойчивы. Как и транзакции на (стандартных) дисковых таблицах, транзакции на оптимизированных для памяти таблицах полностью соответствуют классификации ACID (atomic, consistent, isolated, durable — атомарные, целостные, изолированные и устойчивые). Оптимизированные для памяти таблицы и скомпилированные в собственном коде хранимые процедуры поддерживают только подмножество функций Transact-SQL.
ptr128
15.12.2023 19:55Да даже в MS SQL можно создать таблицы (а может даже целые базы - не упомню), которые целиком и полностью в памяти хранятся.
Сами таблицы хранятся полностью в памяти, а вот для обеспечения устойчивости (durable) на диске ведется журнал в директории $FSLOG, а транзакции и данные фиксируются тоже на диске в директории $HKv2. Что, кстати, приводит к заметной деградации производительности при модификации in-memory таблиц. Почитайте, если интересно.
ptr128
15.12.2023 19:55Я бы аккуратно поспорил на тему бездумности. Мб вы просто с такими задачами не сталкивались. Есть масса чисто in-memory DB, в том числе с ACID
Для того, чтобы спорить, нужно хотя бы указать, о каких СУБД идет речь. Я не представляю, как реализовать ACID, без фиксации данных в постоянном запоминающем устройстве. Последняя буковка не вписывается без этого.
GospodinKolhoznik
15.12.2023 19:55А надо как на ZX Spectrum: либо все данные целиком помещаются в ОЗУ, либо никак))
vkni
15.12.2023 19:55Иначе, для ускорения работы скачивали бы всю БД в память.
Вы забываете про время и ресурсы сети/памяти на скачивание всей базы. А так-то вы правы, кроме случаев, когда сервер БД много мощнее клиента.
vkni
15.12.2023 19:55У вас через всю статью сквозит, что «господин Журден не знал, что говорит прозой».
Достаточно очевидно, что асимптотическая сложность не играет большой роли, когда данных мало. Опять-таки, очевидно, что в старые компьютеры данных помещается сильно меньше чем в современные. Как вы написали «1,2 Гигабайта, что для современного компьютера ниачём».
То есть, масштабы используемой памяти сильно выросли, поэтому в ЦОДах надо держать в голове асимптотическую сложность почти всегда. А раньше этого не надо было, а наоборот, нужно было уменьшать время обработки одного элемента. Поэтому сейчас можно писать на Питоне, но следить за сложностью, а раньше нужно было писать на ассемблере, но за сложностью следить было не обязательно.
SpiderEkb
15.12.2023 19:55асимптотическая сложность не играет большой роли, когда данных мало
Достаточно типичная проблема для больших систем, которые живут долго и развиваются в течении жизни - увеличивается не только количество данных, но и количество процессов, с этими данными работающих Т.е. нагрузка на систему растет не только по данным, но и по процессам и в какой-то момент система перестает справляться с возложенными на нее задачами т.к. в основу старых процессов были положены какие-то "нативные" алгоритмы, которые на момент разработки устраивали по производительности, а на данный момент уже не устраивают.
Решение проблемы экстенсивным путем, переходом на более мощное железо, это крайняя мера т.к. очень затратно. Поэтому сначала будет использоваться интенсивный путь решения - оптимизация алгоритмов. Переход от нативных к более сложным и более эффективным.
Как раз сейчас проходили этот этап. Очень много задач "на оптимизацию" - переписывание старых модулей, потребляющих слишком много времени и ресурсов. Сам недавно переписывал 6-7 таких модулей. Код 16-го года. Тогда у нас было... Не знаю сколько, наверное, миллионов 20 клиентов. Сейчас 50. Плюс количество бизнес-процессов увеличилось. И да, с тех пор железо менялось (как минимум один раз, если не два). Но все равно - наступил момент когда время работы старых модулей перестало укладываться в рамки допустимого временного окна и пришлось брать их в полную переработку. Там уже вопрос не в рефакторинге кода, а в полном его переписывании. Т.е. берем бизнес-логику и реализуем ее заново, максимально эффективно. Где-то другие таблицы используем, где-то какие-то кеши, где-то добавляем витрины, где-то перестраиваем запросы, вынося из них "тяжелую" логику на постобработку и т.д. и т.п.
В результате в данном конкретном случае получилось на том же процессе ускориться в среднем раза в четыре.
mixsture
15.12.2023 19:55Решение проблемы экстенсивным путем, переходом на более мощное железо, это крайняя мера т.к. очень затратно. Поэтому сначала будет использоваться интенсивный путь решения - оптимизация алгоритмов.
Странное утверждение. Из моего опыта как раз наоборот - железо дешевле людей и сначала пытаются увеличить железо. Если это не помогает, идут к людям.
Вы вот чуть ниже приводите как раз эту стратегию в пример, а вовсе не ваше утверждение.SpiderEkb
15.12.2023 19:55Совершенно не странное. Мы вот работаем на платформе IBM i (AS/440). Сервер
IBM Power E980:
120 процессорных ядра Power9
RAM (Оперативная память) - 12Тб
LAN (Сетевые контроллеры) - 10Гигабит
Storage - 400Тб на SSD
Operation System: IBM i 7.4
В курсе сколько такая машинка стоит? И как ее сейчас купить? Перевод банка с 50млн клиентов на новое железо (а банк нельзя "закрыть на санитарный день") - та еще развлекуха. Это чуть чуть сложнее и чуть дороже чем проапгрейдить домашний комп или сервер ООО "Сукин и Сын" на 100 сотрудников.
Избавление от старого неэффективного кода в любом случае хорошо. И введение "нефункциональных требований" (по производительности и эффективности) на основе накопленного опыта и огромного количества статистик Performance EXplorer (PEX) - основного нашего инструмента для нагрузочного тестирования через которое проходят все поставки.
Так что в первую очередь интенсивный путь и только потом уже экстенсивный, но никак не наоборот. Тем более, когда четко видно что можно ускориться по софту - есть еще резервы (тот же PEX показывает что в старом коде не все гладко).
mixsture
15.12.2023 19:55Думаю, что конкретно ваш случай очень узкоспецифичный. Вы уперлись в потолок апгрейда мейнфрейма, архитектура, подозреваю, не позволяет горизонтально масштабироваться на несколько серверов и это загоняет вас в оптимизацию кода.
SpiderEkb
15.12.2023 19:55На самом деле нет. По всем позициям нет.
Это не мейнфрейм (мейнфрейм - это IBM z)
Там нет потолка - эти сервера отлично кластеризуются (и у нас не один сервер, а кластер) и горизонтально масштабироваться можно. Но это сильно дороже чем оптимизировать работающий код. Неужели вы думаете что тут не умеют деньги считать? Здесь на все первый вопрос - "сколько на этом заработает банк?" - сколько надо вложить сейчас и как скоро это окупится и начнет приносить прибыль.
Неоптимизированный код сродни несвежим продуктам. Может быть для кого-то это норма - для нас нет. Посему на весь новый код сейчас очень жесткие требования, а старый - там выявляются проблемы и исправляются. Что позволяет продлить срок службы серверов, а не менять их каждый год просто потому что у разработчиков руки растут непойми откуда.
И да, периодически железо обновляется. Когда-то у нас стояли Power7, потом Power8, сейчас Power9. Думаю, что и Power10 (они уже существуют) тоже в свое время будет. Как только это действительно станет рентабельным. 10-е поколение, кстати, еще более масштабируемо (по тем описаниям, которые были в сети) - там непосредственно на кристалле размешен контроллер шины, позволяющий объединять машинки так, что они работают как одна, включая совместное использование памяти и всех прочих ресурсов. Условно - ставите 4-процессорную машинку с 10Тб памяти и 200Тб диска, по необходимости еще одну, подключаете к первой и вот у вас 8-процессорная машина с 20Тб памяти и 400Тб диска. Нужно еще? Подключаете еще. И по прежнему для вас это один сервер.
RTFM13
15.12.2023 19:55Условно - ставите 4-процессорную машинку с 10Тб памяти и 200Тб диска, по
необходимости еще одну, подключаете к первой и вот у вас 8-процессорная
машина с 20Тб памяти и 400Тб диска. Нужно еще? Подключаете еще. И по
прежнему для вас это один сервер.Интересно как это работает. Потому, что при нынешних скоростях лишние пол метра кабеля между корпусами будут очень заметно замедлять работу внося соответствующие задержки просто из-за ограниченной скорости света. А пропускную способность шины равную шине проца сложно представить (даже с увеличенным временем отклика). И на сколько я знаю это актуально даже в пределах 1й материнки, если слотов много (там еще электрические проблемы вылезают).
Именно из-за этих топологических проблем память разбита аж минимум на 4 уровня (3 уровня кэша процессора и RAM). По идее память из соседнего сервера это память следующего уровня, с еще большей задержкой доступа. Но планировщик находится в процессоре. По этому нужен какой-то драйвер, который бы приоритизировал выделение памяти и миграцию по ядрам. Возможно я видел что-то такое в ядре линукса, но не уверен. Но если архитектурно большая часть процессов шарится по большей части памяти, то такая оптимизация даст не много.
И именно с точки зрения оптимизации это не выглядит лучшим решением. Как по мне, проще раскидать сервисы по отдельным серверам, тогда поток данных между серверами будет гораздо меньше и более прогнозируемым и обычного 10GE будет даже избыточно.
ptr128
15.12.2023 19:55Интересно как это работает
Возможно сейчас уже не так, но еще в 2008 году IBM использовала для этой цели HyperTransport. Суммарная длина шины ограничена ~0.6 метрами, что вполне позволяет соединять ей соседние стойки. Зато на HT легко реализуется NUMA. Издержки заметны, но в мультизадачной среде, правильные настройки affinity процессоров позволяют их минимизировать.
vkni
15.12.2023 19:55Вы уперлись в потолок апгрейда мейнфрейма
Даже если у вас гуглевские PCшки, добавляя функциональность вы рано или поздно упрётесь в какие-то внешние — физические, финансовые или административные ограничения.
Например, если одни сервер потребляет 100 ватт, то 1000 серверов потребляет 100 кВт — а это уже ощутимые деньги на электричество, серьёзная проводка, вопросы охлаждения и т.д. И просто увеличить в 4 раза кол-во серверов станет несколько накладно.
А в случае серьёзных датацентров может оказаться, что для ввода ещё сотни серверов надо строить новый энергоблок ближайшей электростанции. Просто потому, что на данный момент резервы распределены, и кого-то придётся отключать.
ptr128
15.12.2023 19:55железо дешевле людей и сначала пытаются увеличить железо
Так было раньше, когда действительно производительность одного ядра CPU, скорости внутренней и внешней памяти росли двукратно каждые пару лет.
Сейчас экстенсивный путь развития вертикального масштабирования себя изжил. А для горизонтального масштабирования требуется рефакторинг. Причем, часто, очень даже не простой. И то, что раньше работало на монолите, теперь приходится переводить, например, на микросервисную архитектуру. Что, в первую очередь, человеческий труд, а не просто закупка нового железа. И спрос с просто эффективных алгоритмов сейчас сместился на, пусть и не столь эффективные, но поддерживающие параллельные и распределенные вычисления алгоритмы.
SpiderEkb
15.12.2023 19:55Да все это есть давно уже. И параллельное и распределенное вычисление на этой платформе работает. И микросервисы тут не уперлись (дались они вам, эти микросервисы - там проблем не меньше чем пользы). Все и так модульное и все в отдельных заданиях крутится. И внедряются и тестируются модули независимо друг от друга, и два модуля в разных заданиях полностью изолированы друг от друга не хуже контейнеров...
Почитайте про Power9, Power10, про NUMA и CAPI. И никакого рефакторинга не нужно (см. TIMI в IBM i).
ptr128
15.12.2023 19:55распределенное вычисление на этой платформе работает
Рассказывайте это кому-то другому. С распределенными вычислениями на AS/400 все совсем не радужно. И описанная Вами конфигурация это только подтверждает. Три десятка средненьких 32-х ядерных серверов с парой терабайт оперативки и с такой же парой СХД по 200 ТБ стоят на порядок дешевле кластера из двух описанных Вами AS/400, а с программным обеспечением ориентированным на распределенную обработку будут заметно производительней и, тем более, надёжней. Существенно более тяжелые системы уже так переехали даже с z/OS, а не AS/400. И Вы переедете, если Вы в РФ.
SpiderEkb
15.12.2023 19:55Можно примеры тех, кто переехал? И сравнение производительности?
Те обзоры, что я читал, говорят об обратном.
ptr128
15.12.2023 19:55https://www.tadviser.ru/index.php/Проект:Слезть_с_IBM.%D0%9E%D0%B4%D0%BD%D0%B0%D0%B8%D0%B7_%D0%BA%D1%80%D0%B8%D1%82%D0%B8%D1%87%D0%BD%D1%8B%D1%85_%D0%B2%D1%8B%D1%81%D0%BE%D0%BA%D0%BE%D0%BD%D0%B0%D0%B3%D1%80%D1%83%D0%B6%D0%B5%D0%BD%D0%BD%D1%8B%D1%85_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC_%D0%A0%D0%96%D0%94_%D0%BF%D0%B5%D1%80%D0%B5%D0%B5%D1%85%D0%B0%D0%BB%D0%B0_%D0%BD%D0%B0_Postgres
Только не спрашивайте, почему не стали шардировать данные. Я бы точно стал.
SpiderEkb
15.12.2023 19:55Во-первых, РЖД - это госкорпорация (или корпорация с госучастием, или как там оно у них называется). И вопрос это больше политический, нежели технический. Тоже самое касается и ПФР (там процесс аналогичный)
Во-вторых, я не в курсе что там у них крутится на аске - не факт что именно то, для чего аска предназначена.
В третьих, нет никаких данных о том, что даст сравнимую производительность и сколько оно будет стоить.
И, наконец, ну мигрировали куда-то. Ок. На сегодня вопрос закрыли. А завтра? У нас вот за три года количество клиентов увеличилось с 36млн до 50млн. Сколько можно наращивать количество серверов? 5? 10? 20? 50? В какой момент вам придется выкинуть старое и перетаскивать все на новое? Будет ваша платформа поддерживать аналог TIMI на аске, или с переходом на новые процессора вам придется пересобрать под них весь код чтобы он был оптимизирован под новые процессоры?
ptr128
15.12.2023 19:55вопрос это больше политический, нежели технический
Ну так и Вам потребуется уходить со своей любимой i 7.4 и не менее любимой DB/2, на которые сертификаты ФСТЭК были приостановлены еще в марте прошлого года. Теоретически, можно полностью исключить обработку и хранение персональных данных на Вашей системе, но практически это вряд ли оправдано. И уже сейчас Вы стоите перед нелегким выбором. Либо обновление версий (закон обратной силы не имеет) и риск многомиллионных штрафов (мораторий на плановые проверки до 2030 года не исключает внеплановые проверки и инспекционные визиты), либо переход на сертифицированное программное обеспечение.
я не в курсе что там у них крутится на аске
Во-первых, это некультурно писать ответ, даже не ознакомившись со ссылками. Во-вторых, к них была не AS/400, а кластер IBM Mainframe Parallel Sysplex на z/OS. Это несколько мощнее.
нет никаких данных о том, что даст сравнимую производительность и сколько оно будет стоить
То, что производительность сравнима, могут подтвердить сотни тысяч пользователей АСОУП. Я лично подтверждаю, что по логам интеграции с АСОУП-3 провалы производительности были в сентябре-октябре, но в ноябре, когда они уменьшили нагрузку системные таблицы на порядок, сократив использование временных таблиц, я этого уже не замечаю. Был бы у них до этого опыт с PostgreSQL - и этого бы не произошло. Баги всплывали еще на прошлой неделе. Но это тоже было ожидаемо. Исправляют.
Сколько можно наращивать количество серверов?
При правильно настроенном шардировании - бесконечно. К тому же есть Beowulf: "Since 2017, every system on the Top500 list of the world's fastest supercomputers has used Beowulf software methods". Beowulf кластеры из обычных компьютеров содержат до тысячи нод включительно (NASA).
Будет ваша платформа поддерживать аналог TIMI на аске, или с переходом на новые процессора вам придется пересобрать под них весь код чтобы он был оптимизирован под новые процессоры?
Вернитесь в XXI век. Технологии .NET (CIL), Java (JVM) и node.js (V8) избавляют от такой необходимости. Под новые процессора оптимизируются только компиляторы из байт-кода, что не требует пересборки приложений. И если TIMI тупо компилирует байт-код при запуске в машинный код, то идеология CIL, JVM и V8 намного сложнее, так как первичная компиляция выполняется очень быстро без оптимизации, а уже в процессе выполнения, по результатам профилирования, производится более медленная оптимизирующая компиляция наиболее нагруженных объектов. Впрочем тут немало копий уже сломано. К тому же CIL и V8 сейчас развиваются быстрее, чем JVM (камень в сторону Oracle).
SpiderEkb
15.12.2023 19:55Во-первых, это некультурно писать ответ, даже не ознакомившись со ссылками. Во-вторых, к них была не AS/400, а кластер IBM Mainframe Parallel Sysplex на z/OS. Это несколько мощнее.
Во-первых, по ссылке текст недоступен. Только заголовок. Вот вторых IBM z - это не мощнее. Это принципиально другое.
АСОУП-3 провалы производительности были в сентябре-октябре
Баги всплывали еще на прошлой неделе.
Надеюсь, вы понимаете, что для банка такое в принципе недопустимо? Вряд ли вас порадует если все ваши счета вдруг обнулятся или доступ к ним заблокируется и вам скажут "мы тут на новую систему переходим, извините, поправим в ближайшее время, в не переживайте так сильно..."
То, что производительность сравнима, могут подтвердить сотни тысяч пользователей АСОУП.
Какой ценой? Погуглите на тему cost-efficiencies of ibm i по сравнению с другими системами.
Вот тут, например:
IBM i/Power i Acquisition Costs
35% Less than the Windows-based server
46% Less than the Linux/Oracle server combo
IBM i/Power i Ongoing Costs
49% Less than the Windows-based server
53% Less than the Linux/Oracle server comboЛибо обновление версий (закон обратной силы не имеет) и риск многомиллионных штрафов (мораторий на плановые проверки до 2030 года не исключает внеплановые проверки и инспекционные визиты)
На дворе декабрь 23-года. Как думаете, этот вопрос, если бы он действительно стал так остро, не поднимался бы уже?
И, кстати, у нас есть возможность хранить ПД на внешних системах (которых несколько десятков штук). Это вообще не проблема. На аске работает АБС, но это сильно не весь банк.
Технологии .NET (CIL), Java (JVM) и node.js (V8) избавляют от такой необходимости
Ну да, ну да. Не в курсе, что банки (страховые и прочие коммерческие расчеты) работают с фиксированной точкой, нативной поддержки которой нет и не будет во всем, что вы перечислили? Т.е. у вас нет и не будет возможности просчитать запись из БД в байтовый буфер и сразу с ней работать, не оборачивая ее всякими временными объектами (а это все накладные расходы).
Кроме того, любой интерпретатор байткода - это само по себе уже дополнительные накладные расходы.
И если TIMI тупо компилирует байт-код при запуске в машинный код
Один раз, при запуске на новом железе.
Вообще, очень странная позиция - вместо того, чтобы обеспечить у себя контроль качества кода и мониторинг нагрузки с выявлением узких мест (прежде всего), вы предлагает по каждому чиху наращивать мощности железа. Вам уже указали на то, что это несет дополнительные расходы не только на само железо, но и на энергетическую инфраструктуру (ту же систему бесперебойного питания серверов в частности).
Но если вы так настаиваете - могу еще предложить сэкономить на тестировщиках - сразу не упало - валим на прод. Хороший баг сам вылезет, потом багфиксами закроем.
Я бы понял такую позицию от продавца серверов - ему выгодно впаривать свой товар. Или от чиновника, сидящего на откатах от закупок. Но для технического специалиста, отвечающего за работоспособность системы это непонятно.
ptr128
15.12.2023 19:55Надеюсь, вы понимаете, что для банка такое в принципе недопустимо? Вряд ли вас порадует если все ваши счета вдруг обнулятся или доступ к ним заблокируется и вам скажут "мы тут на новую систему переходим, извините, поправим в ближайшее время, в не переживайте так сильно..."
Уже несколько раз "не радовало" в МКБ и в ВТБ. Пару раз именно с сообщением "переходим на новую систему, проведение операций не доступно". И совершенно аналогичные АСОУП баги у обоих тоже встречал - баланс по счетам правильный, но не совпадает с суммой отображаемых операций. Не идеализируйте. Как бы Вы ни тестировали систему перед релизом, баги в ней все равно будут по определению.
Погуглите на тему cost-efficiencies of ibm i по сравнению с другими системами.
Не подменяйте понятия. Возрастание стоимости масштабирования в системах IBM достаточно быстро становится экспоненциальным, а в том же Beowulf - она остается линейной. Если бы было по Вашему, то в TOP-500 суперкомпьютеров были бы обычные кластеры мейнфреймов, что далеко не так. При том, что как я уже указал, Beowulf используют все суперкомпьютеры с 2017 года.
На дворе декабрь 23-года. Как думаете, этот вопрос, если бы он действительно стал так остро, не поднимался бы уже?
А он и поднимается повсюду. Вы новостей что-ли не читаете? Кто-то выжидает возвращения IBM, MS и Oracle, осознавая, что обновление аппаратно-программного обеспечения с приостановленной сертификацией противозаконно. Кто-то идет на риск, рассчитывая, что пронесет, так как его бизнес слишком мелок и не критичен для того, чтобы профильное министерство разрешило проведение проверки (мораторий продлили до 2030 года). Кто-то уже близок к тому, чтобы упереться в ограничения текущей архитектуры, и потому вынужден срочно переходить на сертифицированное аппаратно-программное обеспечение. Для кого-то такая миграция настолько дорога, что дешевле хоть каждый месяц платить по 18 млн. рублей штрафа, лишь бы не производить миграцию.
Точно знаю, что в холдинге СУЭК, НТК, ЕвроХим и СГК совет директоров еще в прошлом году установил мораторий на обновление аппаратно-программных средств с приостановленной сертификацией. С очень большой вероятностью, аналогичное решение принял и совет директоров Вашего банка. Если бы Вы указали, о каком банке идет речь, то можно было бы это проверить.
Не в курсе, что банки (страховые и прочие коммерческие расчеты) работают с фиксированной точкой, нативной поддержки которой нет и не будет во всем, что вы перечислили?
Простите, но несете бред. Decimal/numeric типы поддерживаются во всех перечисленных системах чуть-ли не с момента их рождения. Вы и вправду искренне считаете, что тот же OEBS на Java или AX на C# используется для финансового учёта без этого? А если Вы про упакованный десятичный формат, то с появлением SIMD инструкций он катастрофически проигрывает по производительности целочисленному с фиксированной точкой.
Кроме того, любой интерпретатор байткода - это само по себе уже дополнительные накладные расходы.
Я где-то употребил слово "интерпретатор"? Во всех перечисленных системах производится компиляция байт-кода, а вовсе не интерпретация.
Один раз, при запуске на новом железе.
В CIL, JVM и даже V8 это тоже возможно, но на практике редко используется. Ведь в общем случае контейнер/приложение может запускаться на любом хосте или даже на разных ядрах одного гетерогенного хоста. Более того, может потребоваться оптимизация кода даже в зависимости от процессора из-за различий в скорости доступа к памяти в мультипроцессорных системах. Если же учесть, что подавляющее большинство приложений выполняются неизмеримо дольше, чем требуется для компиляции, то чаще всего речь идет тут о тысячных долях процента от общего времени выполнения.
А вот само наличие "горячей" оптимизирующей компиляции по результатам профилирования нагрузки дает возможность динамической адаптации машинного кода к конкретному профилю нагрузки, чего не позволяет однократная компиляция, как в TIMI.
Вообще, очень странная позиция - вместо того, чтобы обеспечить у себя контроль качества кода и мониторинг нагрузки с выявлением узких мест (прежде всего), вы предлагает по каждому чиху наращивать мощности железа.
У Вас глюки. Такое утверждать мог лишь подросток или инфантильный взрослый, страдающий от юношеского максимализма. Любой проект требует экономического обоснования. Если экономически выгодней нарастить мощности железа - то выбирается именно это. Если экономически выгодней оптимизация или даже рефакторинг - то выбирается он. И начинал я как раз наоборот, с совершенно противоположного:
Вам уже указали на то, что это несет дополнительные расходы не только на само железо, но и на энергетическую инфраструктуру (ту же систему бесперебойного питания серверов в частности).
Вы бы заглянули в структуру затрат своего же банка. Будете очень сильно удивлены, насколько ничтожны затраты на амортизацию оборудования и коммунальные услуги по сравнению с затратами на ФОТ. Например, в Альфа-банке затраты на оплату труда в 12-13 раз выше, чем на амортизацию ОС и коммунальные услуги в сумме. То есть Альфа-банку даже 10% рост затрат на амортизацию и коммунальные услуги выгодней, чем 1% рост затрат на оплату труда.
для технического специалиста, отвечающего за работоспособность системы это непонятно
Вот именно поэтому я, после высшего технического, получил еще и высшее экономическое образование. Потому что даже на уровне синьора или архитектора, не говоря уже о линейном руководителе, недостаточно только технических знаний без понимания экономических основ рентабельности производства (в том числе и программного обеспечения). А Вам бы рекомендовал все же повзрослеть и избавиться от юношеского максимализма. Интенсивный и экстенсивный пути развития всегда сочетаются для получения максимального эффекта.
SpiderEkb
15.12.2023 19:55Простите, но несете бред. Decimal/numeric типы поддерживаются во всех перечисленных системах чуть-ли не с момента их рождения
Как в Java или C# объявить переменную типа DECIMAL(15, 0) без создания объекта какого-либо класса? Ну то есть что чтобы вот у нас int i, а вот decimal d(15, 0)?
А если это date? time? timestamp? varchar?
Да, в java есть BigDecimal. Но оно ничего общего с тем DECIMAL что лежит в БД по представлению в памяти не имеет. От слова совсем.
Т.е. вы не можете прочитать с диска запись (надеюсь не секрет, что в итоге там все сводится к чтению M байт по смещению N в буфер) и сразу этот буфер использовать без создания разного рода объектов типов DATE, TIME, etc из кусков этого буфера.
Как это делается на аске (с нулевыми затратами на конструирование объектов в рантайме, чисто на статических структурах и без динамической работы с памятью, которая тоже не бесплатна) я уже неоднократно показывал. Повторяться не буду.
Во всех перечисленных системах производится компиляция байт-кода
А байткод прямо выполняется процессором и не требует дополнительной прослойки? Ну да, ну да...
Да, он выполняется быстрее, чем полный интерпретатор. Но это не исполняемый код. Уж поверьте, что такое байткод знаю. И сам писал скриптовые языки с компиляцией в байткод.
То есть Альфа-банку даже 10% рост затрат на амортизацию и коммунальные услуги выгодней, чем 1% рост затрат на оплату труда.
Т.е. выгоднее держать команду косоруких джунов и раз в полгода покупать новый сервер потому что они не умеют написать эффективный код?
Интенсивный и экстенсивный пути развития всегда сочетаются для получения максимального эффекта.
Я где-то говорил обратное?
Или вы почему-то решили, что для оптимизации узких мест в коде надо обязательно повышать ФОТ?
Я вообще-то возражал против категоричного утверждения о том, что "не хватает производительности - докинем новый сервер".
Докинем. Но только после того, как убедимся что дальнейшая оптимизация кода слишком затратна или невозможна.
ptr128
15.12.2023 19:55без создания объекта какого-либо класса
Зачем создавать объект, если для статического или стекового объекта это может выполнено компилятором? Вы и в C/C++ базовыми типами не обойдетесь для работы с decimal, что совершенно не мешает этим языкам лидировать по производительности.
Да, в java есть BigDecimal. Но оно ничего общего с тем DECIMAL что лежит в БД по представлению в памяти не имеет. От слова совсем.
Потому что в БД свои требования для внутреннего представления, данных, а в разных языках программирование - совсем другие. Это же относится и к DB/2 (я так понял речь именно про нее), так как она тоже вынуждена хранить даже просто целые числа в одном и том же виде, вне зависимости от того, на big-endian, little-endian или mixed-endian CPU она в данный момент функционирует. Поэтому в подавляющем большинстве СУБД данные хранятся вовсе не в машинном представлении CPU, на которой она сейчас запущена, а в своем внутреннем формате. Аналогично и в любом сетевом протоколе endianess строго определяется стандартом и не зависит от CPU.
вы не можете прочитать с диска запись (надеюсь не секрет, что в итоге там все сводится к чтению M байт по смещению N в буфер) и сразу этот буфер использовать без создания разного рода объектов типов DATE, TIME, etc из кусков этого буфера.
Если DB/2 поступает именно так, то легче сразу повеситься, чем мигрировать её БД с одной платформы на другую. А кластер DB/2 в гетерогенной среде превращается в фантастику. Если endianess CPU в DB/2 распространяется и на протокол связи с клиентом - то вообще слов нет, кроме нецензурных. Выгоды же при этом никакой, так как подобные преобразования при необходимости выполняются CPU на порядок быстрее, чем чтение из памяти этих данных. Если же говорить об ARM, то он такие преобразования выполняет автоматически в том же такте, что и операция (префикс rev).
А байткод прямо выполняется процессором и не требует дополнительной прослойки? Ну да, ну да...
Вы точно читать умеете? Могу повторить. А Вы попросите кого-то Вам это прочитать:
И если TIMI тупо компилирует байт-код при запуске в машинный код, то идеология CIL, JVM и V8 намного сложнее, так как первичная компиляция выполняется очень быстро без оптимизации, а уже в процессе выполнения, по результатам профилирования, производится более медленная оптимизирующая компиляция наиболее нагруженных объектов.
Один раз, при запуске на новом железе.
В CIL, JVM и даже V8 это тоже возможно, но на практике редко используется. Наличие "горячей" оптимизирующей компиляции по результатам профилирования нагрузки дает возможность динамической адаптации машинного кода к конкретному профилю нагрузки, чего не позволяет однократная компиляция, как в TIMI.
Разве TIMI позволяет такую оптимизирующую рефлексию машинного кода? Что-то я о таком не слышал.
выгоднее держать команду косоруких джунов и раз в полгода покупать новый сервер потому что они не умеют написать эффективный код?
Очень мало вероятно. По моему опыту, джун всегда убыточен. В следующий раз, прежде чем задавать такие глупые вопросы, просчитайте экономическую рентабельность. Тогда хоть будет что обсуждать.
Я где-то говорил обратное?
Именно так:
Так что в первую очередь интенсивный путь и только потом уже экстенсивный, но никак не наоборот.
Вы явно высказались, что вместо сочетания интенсивного и экстенсивного пути развития, Вы хотите применять интенсивный путь до экстенсивного, а не использовать их совместно, в зависимости от экономической рентабельности в конкретной ситуации.
Или вы почему-то решили, что для оптимизации узких мест в коде надо обязательно повышать ФОТ?
Возможно у Вас полный барадак в учете затрат. Возможно, кто-то ведет его за Вас. Но каждый час работы сотрудника списывается на конкретный центр затрат. И если сотрудник сейчас занимается "оптимизацией узких мест в коде", то он не занимается, например, новой функциональностью срочно необходимой в связи с приказом Центробанка. А значит на эту новую функциональность необходимо привлечь кого-то другого. Но так как бизнес не может себе позволить сотрудников, ничем не занимающихся и свободных для привлечения куда угодно, то в общем случае - увеличив затраты на оплату труда расширив штат.
Иными словами, если руководство решает, что на "оптимизацией узких мест в коде" следует тратить не 640 человекочасов в месяц, а 1280, то это решение подразумевает наем еще четырех сотрудников, занимающихся только этим. С соответствующим ростом затрат на ФОТ. И то, что подобное решение было принято в Вашем банке когда-то раньше, ничего не меняет. С момента принятия этого решения затраты на оплату труда возросли, что требует оборотных средств ежемесячно.
Я вообще-то возражал против категоричного утверждения о том, что "не хватает производительности - докинем новый сервер".
Для ряда задач (Confluent, Cassandra, Spark и т.п.) - это совершенно правильное решение. Их оптимизировать обойдется несравнимо дороже, а шансы на сколь-либо значимый результат этой оптимизации - ничтожны. В общем случае - опять таки, требуется экономическое обоснование. Если, например, на оптимизацию модели прогнозирования мне нужно хотя бы три месяца и при этом, я не могу гарантировать, что на одной A100 нейронная сеть станет обучаться даже в полтора раза быстрее, то закупка второй A100 точно даст двукратный прирост производительности и точно обойдется дешевле, чем затраты работодателя на мой труд в течении этих трех месяцев. Причем закупить и установить ее можно за несколько дней, что тоже немаловажно, если решить проблему нужно было еще вчера.
vkni
15.12.2023 19:55Почитайте про Power9, Power10, про NUMA и CAPI. И никакого рефакторинга не нужно
NUMA и никакого рефакторинга??? Попробуйте написать программу для параллельной обработки чего либо там, ориентируясь на SMP, а потом тупо запустите её на двухпроцессорном сервере. И попробуйте добиться полного использования вычислительных мощностей машины. Ха, ха, ха.
starik-2005 Автор
15.12.2023 19:55Как-то один товарищ писал здесь про зависимость производительности серверов от количества планок установленной памяти. Ну как бы всем должно быть понятно, что если в процессоре 8 каналов памяти, а вставлено две планки, то работают только два. На двух сокетах надо ставить уже 16 планок. При том я нередко даже в очень больших конторах видел сервера - под тот же 1с, - в которых на два сокеты было 4 модуля памяти. И с этим вот вообще не получается бороться, т.к. админы - они вообще не про алгоритмы, хотя в их работе этих алгоритмов (бест практис) - тоже выше крыши.
vkni
15.12.2023 19:55Из моего опыта как раз наоборот - железо дешевле людей и сначала пытаются увеличить железо. Если это не помогает, идут к людям.
Да, но:
1. Если конкретное место однопоточно, то для добавления железа тем или иным образом придётся идти к людям — расшивать либо в параллельную обработку, либо в сервисы.2. Если там сложность высокого порядка (квадрат/куб), то скоро упрёмся в какие-то проблемы с железом: либо его нет, либо некуда поставить, либо ещё что.
3. Если система живёт долго, лет 10, то она, скорее всего, достигла потолка аппартной части, и использует её в ситуациях пиковой нагрузки почти на 100%. А расширение этой системы упирается в какие-то серьёзные ограничения, скажем, размер центра. Ну потому, что «сначала увеличивали железо».
То есть, к людям приходится довольно часто ходить.SpiderEkb
15.12.2023 19:55Тут еще такой момент - когда сопровождение видит конкретные проблемы в конкретных (особенно старых) модулях, то проще и быстрее переделать несколько модулей и получить кратный прирост производительности в наиболее узких местах, чем сразу ставить еще один сервер и переносить на него старый ресурсозатратный код.
Как пример - был у нас один процесс, который с ростом количества обрабатываемых данных занимал до 12-ти часов (и это при параллельной обработке в 10 потоков). На тех самых "нативных" алгоритмах.
Сейчас он полностью переписан и занимает меньше часа. Да, там стало сильно сложнее в плане алгоритма (и пришлось ряд попутных задач реализовать), но вот так вот.
Что надо сделать по железу чтобы в 12 раз ускориться? Я сомневаюсь что это можно только железом решить за какие-то осмысленные деньги.
ItsNickname
15.12.2023 19:55Сперва будут покупать новое железо. Оптимизация 1 процесса в системе стоит от 5к долларов, иногда сотни тысяч долларов. Проще купить железо чем оплатить неделю разработки
dyadyaSerezha
15.12.2023 19:551) Автор явно выбрал неверное название для статьи. Верное - почитайте мои ностальгические воспоминания про якобы почти не-программиста, который уделывал и западных, и наших крутых программеров. Про алгоритмы тут процентов пять максимум.
2) "На дворе стояли 90-е — начало компьютерной эры человечества". Ну вот не надо грязи. Начало было гораздо раньше.
3) про сортировку кружочков ребёнком - девочка сразу видела все кружочки и сразу выбирала наибольший (точнее, сравнивая попарно, построечно несколько раз, быстро двигая глазами). Попросите ее так отсортировать 50 кружков и она не сможет. А вот видеть, что очередной кружок больше нижнего из уже отсортированных - сможет.
4) вьювер - блин, как же меня достает это а-ля деревенское произношение (типа как "маде ин Япан")
5) "на С из кеша ОС битовая матрица формировалась..." - из какого такого кэша? Вот тут поподробнее, что за кэш и так далее.
Zara6502
15.12.2023 19:55вьювер - блин
а что? обычный англицизм, я так говорил еще с 80-х, почему бы мне бросать это делать?
Kerman
15.12.2023 19:55вьюер - англицизм, вьювер - рунглицизм
Zara6502
15.12.2023 19:55в СССР было принято чтение в латинской транскрипции (меня поправят как это правильно называлось), поэтому например Вильям Шекспир, Вальтер Скот, Гудзон и т.п. Вероятно да, это рунглицизм, но то что он есть, не должно вызывать негодования. Люди, пользующиеся такими словами уйдут и останутся только истинные англочитающие товарищи ломающие себе язык.
Ну и "вьюер" писать в быту, как и "уотсап", как и другие слова мне кажется непрактично, поэтому - вацап, тимвьювер, браузер и т.п. Если уж на то пошло - нет слова "компьютер" вот вам транскрипция
computer [kəmˈpjuːtə]
мне кажется вас проклянут, если вы заставите русского человека так говорить.
Kerman
15.12.2023 19:55Можно спорить о том, как правильно читать "william", "whatsup" и прочее. Это инвариантные случаи. Но в слове "view" нет второй "в" и никогда не было. Никто же не читает "ренаулт", "куеуе", "бузинесс".
Кринге, блин.
ptr128
15.12.2023 19:55В слове "doctor" звук "r" тоже не произносится в британском произношении, что не мешает ему звучать в американском. Это даже не трогая русское слово "доктор".
Вышеупомянутый "computer", аналогично, имеет звук "r" в американском произношении, но не имеет в британском.
Что касается "view", то русский язык достаточно богат, чтобы не заимствовать это слово из английского языка. В переводах я везде вижу слово "представление", а вовсе не "вью". Но даже по аналогии, слово "clown" пришедшее из английского языка, звучит как "клоун", без лишних звуков. И говорим мы "ноу-хау", а не "кноув-хаув" )
Никто же не читает "ренаулт"
Ну тут как повезет. ДДТ ("dust") в русском языке устоялся, как "дуст", а вовсе не "даст". И травили тараканов дустом. А если Вы, говоря о "xerox", скажете "зиракс", а не "ксерокс", то Вас вообще не поймут.
mvv-rus
15.12.2023 19:55Что касается "view", то русский язык достаточно богат
А что касается viewer? Как с этим?
ptr128
15.12.2023 19:55В зависимости от контекста, это может быть и зритель, и читатель, и просмотрщик, и досмотрщик, и осмотрщик.
mvv-rus
15.12.2023 19:55Контекст тут конкретный: средство для просмотра чего-либо. Каковы будут ваши варианты?
ptr128
15.12.2023 19:55Либо просмотрщик, либо программа просмотра, если требуется уточнение контекста, что имеется в виду именно программа, а не устройство (например, просмотрщик микрофильмов).
ptr128
15.12.2023 19:55Почему? В библиотеках даже 40 лет назад называли просто "просмотрщик", так как программ просмотра тогда не было. Сейчас их надо как-то разделять, если контекст не ясен. На микрофильмах очень много осталось до сих пор не отцифрованного.
ptr128
15.12.2023 19:55Ну это исключительно Ваше личное субъективное мнение. Причем на уровне двухлетнего ребенка, многие из которых коверкают слова именно потому, что "произносить неудобно". На Эйяфьядлайёкюдль с непривычки даже дикторы центрального телевидения язык ломали. Но ничего, быстро привыкли. Из-за этого Эйяфьядлайёкюдль никто не переименовал )))
starik-2005 Автор
15.12.2023 19:55Eyjafjallajökull происходит от eyja [ˈɛɪja] — остров, fjall [fjatl̥] — гора и jökull [ˈjœkʏtl̥] — ледник.
По исследованию американских лингвистов, название ледника могут правильно произнести лишь 0,005 % населения Земли[13]. Исландская певица Элиза Гейрсдоттир Ньюман сочинила песенку, помогающую выучить слово Эйяфьядлайёкюдль[14][15]. Русская транскрипция Э́йяфьядлайёкюдль довольно близко фонетически передаёт произношение названия исл. Eyjafjallajökull.
Довольно близко != точно.
ptr128
15.12.2023 19:55В любом случае, дикторы научились его произносить. А уж научиться произносить просмотрщик, если уже используешь слова досмотрщик (на таможне) и осмотрщик (на железной дороге) - явно не проблема.
mvv-rus
15.12.2023 19:55Ну это исключительно Ваше личное субъективное мнение. Причем на уровне двухлетнего ребенка
Хамите? А зря: к вашему сведению, в языке слова, которые произносить неудобно, могут меняться под это самое удобство. Не верите? Посмотрите про происхождение слова "близорукость".
А пример про исладский вулкан отношения к делу не имеет: поговорили про него досужие разговоры и забыли. А вот viewer - штука используемая часто, и не дикторами, которым бабло платят за говорение, а обычными людьми. Забыть не получится, называть как-то придется. Лучше - удобно.
ptr128
15.12.2023 19:55Хамите?
Нисколько. Просто забыл уточнить что имелось ввиду знание языка на уровне двухлетнего ребенка. Скорее всего, для Вас русский язык не родной, поэтому Вы не знакомы со словами осмотрщик или досмотрщик. Если человеку мешает только изменение приставки давно устоявшихся в русском языке слов с о- или до- на совершено обычную в русском языке приставку про- - то это действительно уровень человека только начинающего осваивать язык.
в языке слова, которые произносить неудобно, могут меняться под это самое удобство
Это не относится к словам, различающихся только приставками, с одинаковым корнем слова и суффиксом.
GospodinKolhoznik
15.12.2023 19:55Нет никакого американского английского языка. Есть британский и есть те, кто говорят на нём с ошибками.
ptr128
15.12.2023 19:55А где Вы увидели, что я писал об американском английском языке? В английском языке есть два официальных стандартизированных диалекта - британский и американский. К тому же выше речь шла вообще о произношении. Например, если отъехать всего на несколько сотен километров от Москвы - сразу это замечаешь. Например, Вологодско-Костромская речь отличается от среднерусской речи оканьем, а Курско-Орловская - аканьем. Или Вы будете доказывать, что наречий и, тем более диалектов, русского языка нет, а "есть те, кто говорят на нём с ошибками"? Начните тогда с наиболее известного противостояния между Питером и Москвой - бордюр или поребрик )))
К слову, на периферии москвичей по говору весьма точно идентифицируют.
GospodinKolhoznik
15.12.2023 19:55Скорее вы говорите о том, что в словах вилка и тарелка нет мягкого знака, но это не мешает ему звучать на Кавказе "вилька, тарелька". Также и с английским словом doctor, которое в штатах произносят по-своему.
ptr128
15.12.2023 19:55Давайте Вы все же акценты не будете путать с диалектами. Хотя бы, чтобы не выглядеть демагогом подменяющим понятия.
Именно поэтому я и предложил Вам начать с бордюра и поребрика, что явно относится к диалектам.
ptr128
15.12.2023 19:55С каких пор Елизавета II получила право устанавливать стандарты языка? Ладно еще в Великобритании. Но какое отношение она имеет к США? Еще раз, в английском языке есть два официальных стандартизированных диалекта - британский и американский. И никакой Елизавете II это не изменить.
GospodinKolhoznik
15.12.2023 19:55Ну уж у кого кого, а у английского монарха побольше прав говорить о том такое английский язык, чем у пары диванных аналитиков с популярного-технического сайта из русскоязычного сегмента интернета ))
ptr128
15.12.2023 19:55Говорить монарх Великобритании может что угодно. Но юридически его слова никакой силы не имеют не только для Содружества, но и для самой Великобритании. Тем более у нее нет прав указывать США, каким должен быть SAE.
пары диванных аналитиков
Прошу прощения, но я ссылаюсь на законодательно принятые стандарты английского языка в Великобритании (SBE) и США (SAE), чем и отличаюсь от такого действительно диванного аналитика, как Вы )
Cerberuser
15.12.2023 19:55Начните тогда с наиболее известного противостояния между Питером и Москвой - бордюр или поребрик )))
В смысле - с того, под каким одним словом правильно объединять два изначально разных понятия?
ptr128
15.12.2023 19:55С точностью наоборот. Когда один тот же объект в Питере называют поребрик, а в Москве - бордюр. Неплохо так же разобраться со спором батона с булкой, водолазки с бадлоном и гречки с гречей. Это я только по питерскому и московскому диалектам проехался.
Cerberuser
15.12.2023 19:55Ну так изначально-то бордюр и поребрик - это разные вещи. И их стали в итоге называть одним словом (а то, что это "одно слово" оказалось регионозависимым - это уже второй вопрос). Впрочем, признаю, другие примеры такого не позволяют.
geher
15.12.2023 19:55Никто же не читает "ренаулт", "куеуе", "бузинесс".
Я читаю, особенно "куеуе", хотя знаю, как оно на английском правильно читается. Долгие-долгие годы изучения немецкого дают о себе знать.
А char часто хочется прочитать как "хар" или хотя бы "шар" (по аналогии с немецким "chance")
SilverHorse
15.12.2023 19:55"куеуе"
"Куюй". Ага, у нас в универе это несчастное queue все читали именно так, локальный мем, sort of. И я еще слышал минимум три разных варианта произношения.
Zara6502
15.12.2023 19:55Ну в явном виде редко встречается, но бывают и ренаулты и пеугеоты, ну и что уж кривить душой - никто не говорит "хёнде", а все говорят "хюндай".
А для себя, в своей компании, я люблю эти слова говорить так как написаны, меня это немного веселит. Вне компании я конечно стараюсь говорить так, чтобы меня поняли, но если я скажу "хёнде" то скорее все подумают что я имею в виду "хонда".
Слово queue - как я понял вы его именно написали, я не знаю как читать правильно, поэтому оно для меня всегда "куеуе", так же со словами типа "length" или "through", в моей голове они звучат как "ленгтх" и "троугх", это в первую очередь связано с тем, что я пишу всегда диктуя себе в голове и если я продиктую "фро" или как оно там правильно, то я сам не буду понимать что мне написать, мне нужны буквы, а не звуки. Ну а "length" я всегда называл "ленч", абсолютно не знаю откуда это повелось.
Но в слове "view" нет второй "в" и никогда не было
Скажу больше, там нет первой "в", как изучавший немецкий я там вижу "фив", а ваша "queue" - это "квойе" (ˈkvɔɪ̯ə), ну и "business" это всё же "бузинес" ([buˈziːnəs]), хотя у немцев двойная "s" будет как "ß".
geher
15.12.2023 19:55Скажу больше, там нет первой "в", как изучавший немецкий я там вижу "фив", а ваша "queue" - это "квойе" (ˈkvɔɪ̯ə)
У Вас таки лучше немецкий сохранился. У меня это вспоминается только после некоторого напряжения памяти. Но по английски правильно все равно произносить не хочется.
Zara6502
15.12.2023 19:55Как ни странно, но я всегда считал что в школе плохо учил немецкий, хотя спокойно читал немецкие газеты и переводил всё что в учебнике. Немецкий мне кажется более стройным и понятным, но в жизни совсем не пригодился, разве что лет 5 назад познакомился с игрой Rust (не с ЯП) и там был какой-то сервер с бандой немцев, я им даже что-то писал и понимал ответы :) Но в целом мышление именно из-за программирования сильно ушло в английский, хотя касательно слов и написания в голове конечно кордебалет полный.
У нас еще поборники чистоты английского часто вообще забывают что английский мир очень неоднородный и как минимум делится на british и american, где всё тоже весело.
Лично мне не приходится вести переписку или общаться на английском, поэтому я всё делаю так как мне удобно и когда я программируя пишу public void SomeClass, то я диктую - публик воид СомеКласс. Я уверен что Джону и Майклу в Дакоте глубоко плевать как я это произношу в своей голове )
SalazarMAX
15.12.2023 19:55тимвьювер
Как можно так говорить и писать при наличии слова «интервьюер», которое успело достаточно обрусеть и стать широкораспространённым?
Zara6502
15.12.2023 19:55Тут ведь главное чтобы меня понимали, мне по большому счёту вообще всё равно. А большинство тех с кем идёт переписка или общение говорят и пишут "тимвьювер". Тут же нужно понимать что кроме английского люди и немецкий изучают, а изучавшие английский дай бог "spar" без ошибок прочитать смогут.
Ну и до того как начать доколупываться к таким иностранным словам неплохо бы русский язык чтобы все знали идеально, чего совсем не наблюдается.
PS: вот вы знаете такое слово "файликмультифора"? А я знаю и говорю я его регулярно, потому что половина людей знает что такое файлик, а вторая половина - мультифора и чтобы не выяснять кто и как меня поймёт я говорю так чтобы было понятно всем. Тупость? Ну наверное, но мне главное чтобы меня понял рядовой гражданин, а не чтобы одарённый филолог одобрил.
muxa_ru
15.12.2023 19:55Математику пусть знает заказчик или бизнес-аналитик — вот им она полезна, т. к. позволит правильно поставить задачу.
А кто должен знать какие данные должен предоставить заказчик: сам заказчик или программист?
funca
15.12.2023 19:55Автор работает в институтах, решая местные прикладные задачи. Могут предложить, что его заказчики это учёные, которые вполне могут объяснить свою задачу со стороны домена в мельчайших подробностях. За программистом остаются технологии.
Zara6502
15.12.2023 19:55Когда заказчик не может сформулировать задачу, про какие данные вы у него спросить сможете? Я работал на заводе, хотели внедрять ERP, за 3 года ни один отдел не смог подготовить ничего. Вы предлагаете мне ходить между 1500 человек, осваивать все техпроцессы и готовить данные? У завода столько денег нет чтобы меня на это сподвигнуть.
Rusrst
15.12.2023 19:55Я тут недавно читал, что алгоритм бинарного поиска (целиком рабочий) опубликовали сильно позже того, как открыли. Так что не сказать что это мелочи.
Ну и с вашим подходом все можно назвать не алгоритмом и не математикой - надо нам фигуру подвигать, да что там те векторы, сложил,вычел. Надо фильтр написать простой, да тоже самое. Но все же нет, работает это не так
Zara6502
15.12.2023 19:55Дело в том что это работает и везде, причем и в коммерческих продуктах. А алгоритмический перфекционизм он существует где-то там, но где - нам не говорят.
Rusrst
15.12.2023 19:55Вы знаете, я читал несколько книжек по алгоритмам, и там, к счастью приводятся реальные примеры, где могут быть нужны деревья, где надо рассмотреть разные алгоритмы, где ещё что-то. Поэтому хотя бы обзорно знать эти вещи надо. (Хотя я вот сам далеко не все знаю)
vkni
15.12.2023 19:55Алгоритм бинарного поиска используется для поиска страницы в книге. Я буду сильно удивлён, если Пушкин искал нужные ему отрывки линейным просмотром.
Zara6502
15.12.2023 19:55Сомневаюсь что это бинарный поиск, возможно вариация на тему, но не классический. Простой пример, вам нужна 174 страница, вы открыли книгу на половине, там 215 страница, вы не станете нижнюю часть книги делить пополам, вы возьмёте несколько страниц и посмотрите на результат, например 191, возьмете еще несколько, станет 176, а потом по одной.
haqreu
15.12.2023 19:55Ой, "целиком рабочий" - это без переполнения со сложением? Тот, что вместо m = (a+b)/2 делает m = a+(b-a)/2? Да просто пару десятков лет инта хватало с большим запасом, вот и не парились с обработкой данных, которые едва влезают в тип.
Zara6502
15.12.2023 19:55В школах и непрофильных специальностях вузов изучали (80-90-е) наивные алгоритмы, сдавали зачеты и вопрос закрывался. Возможно на профильных в москвах это было иначе. Мы на теории и технологии программирования даже бинарный поиск не изучали, сортировок вообще не касались. Потом я всё это читал у Страуструпа, но до применения никогда дело не доходило, так как оперирование большими объемами данных никогда не происходило и всё делалось или наивным способом или std:sort.
Вот одна моя история когда я столкнулся с проблемой, у меня была локальная sql таблица с 200000 записей и любые манипуляции онлайн происходили по 10-15 секунд, что было очень неудобно. Я создавал два потока и кешировал запросы, а при простое - склеивал базы. Это работало, но иногда ломались сами базы. Для чего они у меня постоянно бэкапились.
А чуть позже я рассказал о проблеме своему знакомому 1С-нику и он сказал - а ты в памяти держи базу и обновляй только в конце работы или по кнопке или по закрытию окна. Попробовал - оно стало работать моментально и без потоков, проблема с поломкой баз тоже ушла.
Всё. И это за 35 лет. Жизнь у всех разная как и профессиональная деятельность, поэтому как я во всех подобных статьях и пишу - умение в алгоритмы пригодится вам только на позиции уметора алгоритмов. А 99 ваших коллег будут писать:
if (a==1) then
if (a==2) then
...
if (a==21837463653) then
и получать ту же зарплату что и вы.
1755
15.12.2023 19:55Убили как-то друг друга программист компьютерной графики и фронтенд-разработчик, споря о том, должен ли программист отлично знать линейную алгебру. Попадают к апостолу Петру и просят рассудить:
– Апостол Пётр, – говорит программист компьютерной графики, – я не выдержал и стал душить его, макаку вебную, ожидая, что он согласится со мной.
– Нет, это я не стерпел и стал душить его, олимпиадника сутулого, ожидая, что он согласится со мной, – перебил фронтенд-разработчик.
Не выдержав, программисты снова сцепились.
– Лучше бы вы дедлоков избегали... – проворчал Пётр.
Rusrst
15.12.2023 19:55А какие у разработчиков ui дедлоки то? Ui на своем потоке рисуется, все знают что если его завесить, то хорошим дело не кончится. Так что оба этих товарища делоки создадут с очень малой вероятностью, ну на ui слое как минимум
ptr128
15.12.2023 19:55Ну классика же! Если при сохранении одной формы сначала выполняется UPDATE первой таблицы, а затем уже агрегаты сохраняются во второй, а на другой форме сделано с точностью наоборот, dead lock рано или поздно поймаете.
p07a1330
15.12.2023 19:55Ну например- если я фетчу данные из нескольких мест, обрабатываю/комбинирую их и делаю составное представление, причем запросы не коммутативны - получается классическая проблема асинхронищы, в точности как в бековском программировании.
Где параллельные процессы - REST запросы, а вьюшка - разделяемый ресурс
BlithePeach
15.12.2023 19:55Выскаду своё личное скромное мнение, я считаю что хранение алгоритмов обязательно для каждого специалиста в сфете т.к. это база на которой построена по сути вся информатика, это все равно что быть программистом и не знать что ПК опирирует нулями и единицами, а не строками символов и т.д. и это уже не говоря о том что функции ( базовые конструкции большинства языков программирования это по сути частное представление тех же алгоритмов, но уже созданных человек для решения какой-то конкретной задачи).
НО! На сколько хорошо и глубоко нужно вникать в эту тему это уже другой вопрос и для каждого человека ответ будет разным.
Программист прикладного уровня должен знать в первую очередь архитектуру приложений и как её строить, как писать читабельный код, и как умело пользоваться теми ресурсами ПК которые были ему выделенны для решение конкретно это решения, и это уже не говоря о том что почти во всех высокоуровневых языках программирования все необходимые базовые алгоритмы уже давным давно интегрированны в различные библиотеки и фреймворки, и расписывать огромный алгоритм каждый раз когда вам надо отсортировать какой-либо набор данных это будет как минимум глупо, а как максимум безумие.
В итоге: Да, знать алгоритмы должен каждый IT специалист, точно так же как каждый специалист должен знать и понимать устройство того с чем он работает (ПК), для большинства программеров знания базовых алгоритмов будет более чем достаточно что бы работать 10 - 20 лет в своей сфере и чувствовать себя комфортно, но узко направленным специалистам в какой-то конкретной сфере может понадобится значительно расширить свои познания для того что бы успешно работать с какими-то конкретными технологиями.
jackcrane
15.12.2023 19:55Умный математик с Уральских гор нарисовал для него какой-то скрипт
реально умный математик применил бы awk с вызовом из bat-файлов. для MS DOS были реализации. работали даже на 8086 (т.е. i386 не обязателен), работали заведомо быстрее Quattro Pro.
вывод: алкаш не ту книжку подарил. надо было такую:
http://flibustaongezhld6dibs2dps6vm4nvqg2kp7vgowbu76tzopgnhazqd.onion/b/402132
IvaZo831
15.12.2023 19:55Те, що преподают? - Нет.
Взять даже дурака как джуна с улицы и научить сначала на примерах, потом с вкраплениями теории на порядок проще. Чем брать с курсов универов и т.п. самоуверенного дурака с инициативой и переучивать...
По факту сначала будет обучение "Логике": если A => B => C, то A => C (=> равно "следует).
Далее часть простой доказательной геометрии, как получать нужный результат, расписывая все "ходы". А потом, когда школьный базис будет на уровне нормального 3банщика старой норм школы - тогда можно говорить даль.Ибо нарот вообще дупля не режет просто в очевиднейших вещах...
Ну и главное - нахрен всяких HR. Пусть вместо них собеседуют клинические психологи - набор же не в кунсткамеру или палату №6. А остальному научим, так и быть. лишь бы человек нормальный, вменяемый, адекватный был)
AndreyDmitriev
15.12.2023 19:55У нас было два семестра численных методов. Ну всякие там Рунге-Кутта, системы линейных и нелинейных уравнений, диффуры, вот это вот всё. Первый семестр на Фортране, а второй - на Паскале (дело в середине девяностых). За тридцать лет что-то писать "с нуля" не потребовалось практически ни разу, в основном потому, что есть хорошие мат библиотеки, где всё это реализовано. Но курс был пройден в общем не зря, так как несколько поворачивает мышление в алгоритмическую строну, плюс даёт возможность ориентироваться в алгоритмах. Несколько книжек по алгортимам у меня всегда под рукой, если что туда всегда можно заглянуть. Четырёхтомник Кнута как справочник - вполне хорош.
Пример - в этом году у меня был довольно жёсткий по срокам проект, и мне в помощь выдали девушку-контрактора, мастерицу на все руки, работающую удалённо. По ходу работы возникает необходимость сделать несложную аппроксимацию полиномом. Я ставлю задачу - смотри, я отдаю тебе два массива - по х и по y, ты строишь по ним полином второй степени и возвращаешь коэффициенты и ошибку. Потом я даю тебе y, а ты смотришь корни и возвращаешь мне обратно х, тот что меньше. Точки сидят на полиноме хорошо, метод наименьших квадратов вполне подойдёт. Вроде всё просто, работы максимум на полдня, да и то если с перекурами. Это притом, что в мат библиотеке есть готовые функции, ну и весь интернет полон исходников, надо только знать где и что искать. Даю ей день - завтра мне понадобится. На следующий день вижу с трудом вымученную кусочно-линейную интерполяцию... По итогу это почти неделю заняло, но в конце она разобралась.
Rusrst
15.12.2023 19:55Математика это вообще сложно на самом деле. Я иногда такие перлы творю с всякими векторными преобразованиями, хотя казалось бы... Так что если понятно вам, не значит, что понятно всем. Иногда мат аппарата не хватает, а улучшать его - всегда время.
konst90
15.12.2023 19:55Вам это давали, вам хорошо. А я учился на инженерной специальности, и программирование свелось к одному семестру Паскаля раз в две недели и куче пар скриптового языка прочностной программы. В итоге, когда мне на первом году работы понадобилось для решения одной задачи искать площади под графиками - я написал метод Симпсона, потому что понятия о библиотеках не имел, а переходы в коде были сделаны через if. Потому что иначе я не умел, а решить задачу было надо.
ptr128
15.12.2023 19:55IMHO, самое главное, что дает высшее образование, вовсе не знания по специальности, а умение быстро изучить любой предмет в рамках своей сферы (технической, медицинской, экономической и т.п.) самостоятельно. Порой даже изучить, использовать (например, сдав экзамен или завершив проект) и забыть. А работать, используя только то, чему научили - это уже уровень среднего специального (профессионального) образования, а вовсе не высшего.
php7
15.12.2023 19:55Все же сам ты болтаешься в своем болоте.
Общение с коллегами полезно.
Общаться могут и люди со средним специальным образованием.
Иногда даже полезна смена коллектива. Открываются новые вещи, которые не использовались ранее в старом коллективе.
Это не значит что я против самообразования или только за общение.
ptr128
15.12.2023 19:55Совершенно не понял связи между Вашим ответом и тем, что написал я. Общение - это одно, беспрерывное самообразование, жизненно необходимое в столь быстро развивающейся отрасли, как IT - совсем другое. И они никак не могут заменить друг друга. И никак не мешают друг другу.
php7
15.12.2023 19:55Я о том, что:
ВО не дает (не только ВО дает) умение самостояльно изучить предмет. ВО также может дать и знания. А может и не дать.
Образование (или умение учиться) - это одно. А иногда (часто) коллега может показать то, что ты ранее не видел.
ptr128
15.12.2023 19:55Если после множества курсовых и дипломных проектов студент так и не научился самостоятельно изучать предметы, то, на мой взгляд, диплом он получил нечестным путём. Ну или ВУЗ вообще никакой, что у него курсовые и дипломные проекты можно защитить, не изучив что-то самостоятельно.
Даже работая в крупных компаниях интеграторах, я намного чаще узнавал то, что не видел ранее, вовсе не у коллег, а изучая предмет по книгам и в интернете. Понятно, что встречаются какие-то самописные системы или фреймворки, у которых просто нет качественной документации. Тут уже без помощи коллеги изучение по исходникам будет слишком медленным. Но это, скорее исключение, чем правило.
php7
15.12.2023 19:55Студент мог и не научиться самостоятельно изучать предметы. Но мог и уметь до вуза. Мог научиться и без вуза. Я просто не понимаю выражения "не дает знания, а учит учится". Это как? Учит гуглить? Хотя в интернетах нет многого, что есть в книгах.
Я не имел в виду, что коллеги чаще. Я о том, что можно вариться в своем болоте, но иногда смотреть на других. А еще бывает полезно парное программирование. Не на постоянной основе.
ptr128
15.12.2023 19:55Да, я знаю такие случаи. Но, например, академические знания по техническим наукам, экономике или юриспруденции легче получать в ВУЗе, чем осваивать их самостоятельно. Слишком уж высоким уровнем самокритики нужно обладать человеку, что экзаменовать себя на уровне стороннего экзаменатора. А на практике эти знания проверить сложно. Можно только упереться в их нехватку.
Это как? Учит гуглить?
Поисковик может лишь помочь найти книгу, научную статью, реферат или диссертацию. В редких случаях - готовый ответ. Немного разобраться в теме можно поспрашивав в конференциях. Но действительно хорошо изучить предмет можно лишь объясняя его на тех же конференциях задающим по нему вопросы.
Хотя в интернетах нет многого, что есть в книгах.
И какую же книгу нельзя найти в интернете? Даже купить электронную версию книги намного проще, чем бумажную, которой может просто не быть в запасах.
Опять не понял о чем Вы. Вот тут сейчас каждый из нас "варится в своем болоте" или все же учится у других? Ну за исключением тех, кто тут ради собственного ЧСВ, а не ради самообучения.
konst90
15.12.2023 19:55Чтобы изучить - надо знать, что такое в принципе есть. И нужен всё-таки стимул для изучения.
Я этого Симпсона написал на C# в Матлабе, изучив и Шарп и Матлаб (до нужного мне предела) самостоятельно. И программа уже лет восемь работает, исправно считая нужные мне параметры. То есть предмет в достаточной для меня рамке я изучил, а не использовал только существующие знания.
Но для того, чтобы изучить предмет - надо знать, что такой предмет в принципе есть. Я этого на тот момент не знал и считал, что переходы через if - единственно верный путь. А потом узнал, что не единственно.
ptr128
15.12.2023 19:55Чтобы изучить - надо знать, что такое в принципе есть.
Это как раз и есть одна из главных составляющих самообучения - отслеживание нововведений и стороннего опыта. Если не по статьям и рефератам, то хотя бы по новостным сайтам своей профессиональной тематики.
Я этого Симпсона написал ... считая нужные мне параметры
Почему то мне кажется, что тиражируемость и масштабируемость этого решения нулевая, а кроме Вас его никто не сможет поддерживать. А это признаки любительского программного продукта. И именно по одной их этих причин даже гениальные начинания в Open Source оказывались ненужными и забытыми.
konst90
15.12.2023 19:55Если не по статьям и рефератам, то хотя бы по новостным сайтам своей профессиональной тематики.
Именно что своей. Моя специальность - проектирование и испытание некоторых изделий. А программирование - не моя. Программу я использовал как вспомогательный инструмент для решения задачи, которая до меня делалась вручную, для каждой кривой отдельно.
И здесь - вопрос более широкий, о границах своей компетентности в решении задач при условии, что заведомо компетентного сотрудника в организации не имеется. То есть - либо я делаю задачу вручную и постоянно на это трачу кучу времени, либо я максимально быстро пишу программу как умею, либо погружаюсь в не свою специальность, при том что остальную работу с меня никто не снимает, и компетентен-то я в ней.
Вообще могу по опыту сказать, что таких штук написано очень много. Написано плохо, написано на единственно известном сотруднику языке, написано так, что никто кроме сотрудника не разберется. Потому что, например, специалисту проектированию виброопор ставится задача - подобрать оптимальную развесовку дизеля на этих опорах. Он может либо вспомнить вузовский учебник по сопромату и посчитать как учили в вузе - на бумажке в несколько итераций и потом повторить для каждого нового изделия, либо накидать простую программу, которая будет считать это быстро. Вариант "Заказать программу настоящему программисту" у него отсутствует, а осваивать правильное программирование самому ради одной программы на сто строк - нерационально. Так и рождается специфический неподдерживаемый софт.
И, что характерно, аналогичная ситуация наблюдается (вот буквально позавчера) в другую сторону. Если у человека есть сварочный аппарат, куча ненужного железа и задача "сделать ключ на внутренний шестигранник 22" - он не будет окунаться в сопромат, а сварит так, чтобы оно точно выдержало. Потратив больше железа, чем можно было бы, но железа-то куча, его не жалко, а прикипевшую заглушку надо открутить как можно быстрее.
ptr128
15.12.2023 19:55Простите, если я Вас чем-то задел или обидел. Никаких претензий к Вам не имею. Вы сделали что могли, как смогли и получили требуемый результат. Вы молодец!
Он может либо вспомнить вузовский учебник по сопромату и посчитать как учили в вузе - на бумажке в несколько итераций и потом повторить для каждого нового изделия, либо накидать простую программу, которая будет считать это быстро.
Ну программу писать для этого, на мой взгляд, излишество. Когда мне потребовалось перепроверить проект нового дома, который мне строят, я всё пересчитал в Maxima. Благо после того, как в ней получились общие формулы, считать по ним, подменяя переменные, можно многократно. И правильно, что пересчитал. По ряду мест строители перезаложились в несколько раз, а по ряду - наоборот, запас был ниже допустимого.
так, чтобы оно точно выдержало
Но при конструировании такое не проходит, так как лишняя масса, особенно движущихся деталей, начинает тянуть за собой остальное.
прикипевшую заглушку надо открутить как можно быстрее
По моему опыту, это не тот случай, где сила всё решает. WD-40, слесарный молоток и терпение тут дает намного лучший результат, чем оторванная головку болта, который даже экстрактором потом не достать - только высверливать. К тому же в данном случае излишняя масса существенно усложняет отжиг, закалку и отпуск, без правильного проведения которых в месте сварки даже с 40ХФА, не говоря уже о 50ХФА, гарантированы напряжения и трещины. Чему только в деревне не научишься )
konst90
15.12.2023 19:55Ну программу писать для этого, на мой взгляд, излишество. Когда мне потребовалось перепроверить проект нового дома, который мне строят, я всё пересчитал в Maxima
Это тоже вариант (правда, я обычно беру Mathcad), и первые разы я так и делал, но программа получилось более гибкой. А следующей итерацией стало затолкать это в прочностную программу (ANSYS), и кроме развесовки я получил возможность видеть формы колебаний.
оторванная головку болта, который даже экстрактором потом не достать - только высверливать
Не, с заглушкой было несколько иначе. Там была коническая резьба, диаметром около 40 мм, и в заглушке - шестигранное углубление под ключ 22 мм. Завернуто оно (20 лет назад и на фумку) было так, что ударный гайковерт с моментом 500 Нм эту заглушку не взял. Тогда наш слесарь просто взял шестигранный пруток, приварил к нему другой пруток так что получился вороток, и всё это мы провернули двумя метровыми трубами. И сила таки решила, и оно выдержало.
ptr128
15.12.2023 19:55я обычно беру Mathcad
Ну для частных целей покупать лицензию на MathCAD - это тоже излишество. Я согласен, что он удобней и функциональней Maxima, но мне такие дебри просто ни к чему. К тому же Maxima замечательно живет на смартфоне и планшете, чего не скажешь о MathCAD
взял шестигранный пруток, приварил к нему другой пруток
Так в этом и проблема, что слизать в круг шестигранник из обычного прутка можно даже полуметровым рычагом. Сам убедился. Нужна хром-ванадиевая сталь. Лучше 50ХФА, но можно, как в китайских инструментах, ограничиться 40ХФА. А вот ее варить можно, только с отжигом, закалкой и отпуском, чтобы при быстром нагреве и остывании не образовалось напряжений и трещин. Так что Вам просто крупно повезло.
ударный гайковерт с моментом 500 Нм эту заглушку не взял
И не возьмет. Это Вам любой опытный автомеханик скажет. Аналогичные заглушки в картерах дифференциалов именно так прикипают. Масло то меняется там раз в 100-150 тыс. пробега. Так что приезжают к ним автомобили, где эти заглушки лет по 10 не трогали. Особенно на заднем дифференциале сливная пробка всю грязь собирает. А сорвешь резьбу - будешь менять чуть ли не весь дифференциал. Поэтому именно слесарный молоток тут в помощь. Пять-десять минут обстукивания с поливанием WD-40 - и заглушка начинает идти. Главное не торопиться.
Zara6502
15.12.2023 19:55мне правда интересно, а как много программистов в СССС и РФ изучали в вузе ЯП до состояния профи?
я в вузе изучал Бейсик, Clipper/FoxPro, C, Pascal, Delphi, ASM, просто я учился в двух разных вузах, разные преподы. Но ни у одного не было цели научить нас программированию как таковому. И уже работая я изучал то что мне было нужно.
ВУЗ это же про методики обучения, про умение читать литературу, анализировать, системно мыслить.
И даже сегодня я вижу много молодых людей, которые в мир программирования зашли через питона или C# сразу в ООП и что они программируют совсем иначе и чаще всего сильно лучше меня. Мне кажется это правильно.
ptr128
15.12.2023 19:55В МИЭТ была неплохая кафедра прикладной математики. Уже на первом курсе курсовая была по распознаванию образов на ЕС-1033 (FORTRAN и PL/I). Много математики уже было на FORTRAN, вот и получался такой бутерброд.
программируют совсем иначе и чаще всего сильно лучше меня
Это уже опыт. Но вроде бы лучше программируя, такие часто сыпятся на задачах, требующих более глубоких знаний. Например, недавно пришлось самому писать класс на С# для поддержки Java BigDecimal в Protobuf/Confluent, так как это оказалось быстрее, чем объяснять разработчику, чем дополнительный код отличается от прямого и big-endian от little-endian. А задача откровенно разовая.
php7
15.12.2023 19:55ВУЗ это же про методики обучения, про умение читать литературу, анализировать, системно мыслить.
У нас даже был предмет о каких-то методиках, но всем на него было пофиг.
Вот какие методики Вы недавно применяли? Вы научились им в вузе? Или они применяются неосознанно?
Что такое уметь читать литературу, а что такое не уметь?
Умение системно мыслить - а это не скорее черта характера? Или когда черта характера - это чересчур?
Zara6502
15.12.2023 19:55Вот какие методики Вы недавно применяли
Не уверен что это именно так работает. Это выработанное бессознательное. Человек с высшим берёт в правую руку палку, встает в позу, а человек со средним образованием много прыгает в боксерской позе. Условно.
Вы научились им в вузе?
Любой предмет - это методика работы с чем-то. Да, я учился в вузе, а значит я учился методикам.
Или они применяются неосознанно?
Думаю да.
Что такое уметь читать литературу, а что такое не уметь?
Ну как же, а "Смотрю в книгу и вижу фигу"? Книга, особенно для вузов, это структурированный документ, с ним учат работать, эти навыки позднее помогают работать с неструктурированными документами. Находить соответствия, выделять главное и т.д.
Умение системно мыслить
Мне кажется это приобретаемый навык. В моем случае я всё в жизни воспринимаю как решение алгоритмической задачи, а всё что не поддается такой классификации (даже не смогу вспомнить что именно, например отношения людей), то мне уже даётся сложно.
Wesha
15.12.2023 19:55Отношения людей — это тоже алгоритмическая задача, просто её решение сильно усложнено тем, что в ней участвует огромное число скрытых параметров, все из которых узнать невозможно в принципе. Например, одна девушка признавалась, что в раннем детстве некий парень её как-то там обидел. При этом он был блондином — и поэтому теперь для любого блондина у неё сразу по умолчанию -100 баллов к привлекательности. Если некий блондини сейчас попытается к ней подкатиться, то с вероятностью 99,99% он пойдёт лесом — но понять "но почему???" никогда не сможет.
Zara6502
15.12.2023 19:55у меня все усатые +100 к харизме и доброжелательности, все бородаты и усатые +150, а все бородатые и без усов -100. Объяснения тоже нет.
profFortran
15.12.2023 19:55Алгоритмы, безусловно, нужны. Но не нужно заучивать их наизусть и задрачивать до мозолей LeetCode и прочие HackerRank'и только для того, чтобы пройти очередное собеседование, а потом забыть, как страшный сон. Потому что никогда тебе не придётся писать какую-нибудь быструю сортировку вручную (мне за почти 15 лет работы в разных компаниях над разными проектами не приходилось реализовывать ни один из алгоритмов, упомянутых у Кнута или Кормена).
На предложение очередного доморощенного экзаменатора, мнящего себя хрен пойми кем, написать какой-нибудь алгоритм я обычно отвечаю, что вот сейчас достану с полки Кормена или Кнута (прям над монитором стоят вместе с Уорреном и Скиеной, только голову подними и руку протяни), почитаю и напишу, а наизусть как стихотворение, извиняйте, не учил.
И математика нужна ровно также: не нужно помнить наизусть правило Лопиталя (голова лопнет, если наизусть помнить все формулы и теоремы из вышмата, да ещё вкупе с алгоритмами). Нужно знать, что оно есть и в каком справочнике/учебнике его найти, если вдруг понадобится.
SpiderEkb
15.12.2023 19:55Все верно. Главное - знать что не знаешь. Тогда при необходимости сможешь узнать.
Совсем не обязательно знать все алгоритмы "изнутри" (уметь их реализовать самостоятельно). Но знать какие бывают, понимать в целом как оно работает и представлять основные их особенности и граничные условия для применения желательно хотя бы для того, чтобы в каждом конкретном случае выбрать наиболее подходящий.
n43jl
15.12.2023 19:55Все зависит от цели. Если цель попасть в FAANG или что-то похожее, то говорить что не нужны leetcode или hackerrank - это очень плохой совет. Так как один из этапов собеседований именно будет оно.
aamonster
15.12.2023 19:55Кнут нужен на уровне знания, какие алгоритмы и структуры есть и где их применять, да. Чтобы как минимум сходу выбрать подходящий, как максимум – пролистать соответствующий раздел. Главное – чтобы человек там, где не разбирается, не лепил что попало.
murkin-kot
15.12.2023 19:55Непрекращающиеся разговоры на тему "надо/ненадо" свидетельствуют о следующих фактах:
Уборщицы выступают за узкую специализацию - я уборщица и больше ничего от меня не требуйте!
Дворники шестого разряда указывают уборщицам на редкие ситуации, когда махать шваброй реально нужно уметь.
Руководители клининговой конторы считают бабло и понятия не имеют о глупых (по мнению руководства) разговорах персонала.
Если кто-то хочет ограничить свои знания - ну пожалуйста, кто же против? Зачем им возражать? Но возражения появляются с завидной периодичностью. Почему так?
Потому что дух ограниченности, при его массовом распространении, убивает интерес у дворников шестого разряда. И дворники негодуют. Плюс дворники хотят, что бы их оценивали выше уборщиц. Но нужно обоснование. И вот оно - я знаю алгоритм махания шваброй, а уборщица не знает! То есть дворники нашли простой критерий, как им выделиться на фоне уборщиц. Осталось доказать начальству, что этот критерий обязателен к применению. В гуглах и прочих амазонах уже получилось, а что, остальные дворники, рыжие что-ли?
Немного по другому - всё сводится к обычному доминированию. Я хочу быть выше (по деньгам, статусу, всему остальному). Как мне выделиться? Я умею в алгоритмы! Но кому это нужно?
Итак, стремление к доминированию привело броуновское движение дворников к согласию по главному тезису - мы лучшие (это аксиома), а значит мы должны доминировать (это тезис). Доказательство - мы знаем, что такое алгоритм. Всё по шаблону - дано, условия, решение. Вот какие мы молодцы.
Ну и что, если знание алгоритмов действительно не нужно уборщицам? Ведь вопрос же не в поиске эффективного решения для какого-то там начальства (и правда, зачем оно нам?), проблема же в доминировании.
ЗЫ.
Мне самому неприятно, что нами правят уборщицы. Но извините, ставить доминировать вместо них тех, кто подменяет эффективность в широком смысле формальным определением весьма узко трактуемого понятия, есть ситуация типа "менять шило на мыло". Даже если все гуглы на свете приняли диктат дворников.
ptr128
15.12.2023 19:55На мой взгляд, не надо приравнивать знание алгоритмов к зубрёжке их на литкоде. В моей практике нужны две вещи. Во-первых, представление о том, какие алгоритмы применимы в конкретной ситуации, чтобы за пять минут нагуглить нужный, даже если деталей не помнишь. Назовем это математической и алгоритмической базой. Во-вторых, требуется умение рассчитать сложность алгоритма и выбрать из нагугленных наиболее эффективный, опять в конкретной ситуации. Просто чтобы не тратить время в пустую, кодируя все варианты и сравнивая их.
Что касается даже сортировки, то, во-первых, ряд задач, требующих на первый взгляд сортировки, эффективней решить и без неё. Например, для поиска нужных элементов в массиве можно его отсортировать и применить двоичный поиск, а можно создать хеш таблицу. И для каких-то задач эффективней будет первое, а для каких-то - второе. Во-вторых, для разных наборов данных разные алгоритмы могут очень сильно выигрывать или проигрывать в эффективности относительно друг друга. Например, применять QuickSort для почти отсортированных данных - не лучшая идея. Например, timesort тут может оказаться в разы эффективней. При этом совершенно не требуется кодировать алгоритм сортировки. Почти все уже давно закодированы. Нужно уметь выбрать наиболее эффективный.
Вот что я считаю "знанием алгоритмов". Теперь меня можно покусать и попытаться переубедить.
nivorbud
15.12.2023 19:55Ну, таким макаром можно дойти и до того, что программисту и знание четырех арифметических операций не нужно. Давно вы в столбик числа складывали/умножали/делили? Вот то-то. Однако, это нонсенс - программист без умения складывать, умножать, вычитать, делить. Хотя в некоторых профессиях такое часто встречается.
Вернемся к бинарному поиску. Да, вам скорей всего никогда не потребуется изобретать этот велосипед, но... хотя бы поверхностное знание сути этого алгоритма полезно для выбора алгоритма, для понимания будущих проблем (зависимость от объема данных).
Пример: У вас есть список объектов, вы знаете, что список этот пока небольшой и заморочки не нужны, вы принимаете решение сделать простой линейный поиск, но... в уме подразумеваете, что в случае чего вы сможете резко ускориться (и знаете на сколько), применив бинарный поиск, но пока это излишне.
Вопрос: понадобилось вам знание алгоритма бинарного поиска? С одной стороны, в реализации вы его его не применили, но с другой стороны - в анализе ситуации вы его учли и отбросили сознательно, взвесив все за и против.
Zara6502
15.12.2023 19:55Давно вы в столбик числа складывали/умножали/делили?
Ежесекундно.
Да, вам скорей всего никогда не потребуется изобретать этот велосипед
Наоборот, велосипеды изобретаются постоянно, как раз незнание этому способствует.
для понимания будущих проблем (зависимость от объема данных)
Я с большим объемом данных пересекался только однажды, изобрел свой велосипед, проблема закрыта. Про BigO узнал в 45 лет на Хабре. До того дня программировал, и после этого знания в моей программерской жизни ничего не поменялось, разве что когда делаю два FOR по N то знаю что это O(N*N). Что бинарный поиск это бинарный поиск никогда не знал, узнал тоже тут, но именно таким поиском пользовался сам еще с 90-х, сам придумал. Но только если данных больше некоторого значения, иначе проще линейно.
Вопрос: понадобилось вам знание алгоритма бинарного поиска? С одной стороны, в реализации вы его его не применили, но с другой стороны - в анализе ситуации вы его учли и отбросили сознательно, взвесив все за и против
Когда я пишу программы то примерно в 80% случаев я реализую наивный подход во всем. Программу заставляю работать, а потом, когда реализация готова занимаюсь оптимизацией, но только если это реально что-то даст. Например есть ли разница в работе программы 0.002 мс или 0.4 мс? Так-то разница в 200 раз, но вы дольше будете запускать программу, чем она будет выполняться. Мест, где написание софта объемно, критично и ответственно - весьма хватает, но еще больше тех мест, где это не важно абсолютно, именно поэтому "взвесив все за и против" выбирается почти всегда наивный подход. Времена 8-битных машин далеко позади, там счёт шёл на каждый такт ЦПУ, сейчас за этим нужно следить только в строго обозначенных направлениях. Например неповоротливость сайта куда сильнее зависит от того, что в него напихали видео на 500 мб и анимашек на джаве и CSS всяких, чем от того как именно вы выводите текст на экран через p, div или table.
denim
15.12.2023 19:55Убеждать себя что алгоритмы не нужны это как пардон мочиться против ветра - вроде все получается, но есть какой-то странный сайд эффект. Хочешь писать код в достойном месте за хорошие деньги - с 99% вероятностью тебя попросят решить что нибудь из литкода, за вас уже все давно решили
php7
15.12.2023 19:55Иногда хз откуда дует ветер, его попросту нет.
Ну обходится человек без алгоритмов, что тут такого.
php7
15.12.2023 19:55Кому-то наверно нужны.
Кому-то не нужны.
Не было бы вопроса, если бы всем были нужны или всем не нужны.
Кому-то в одной степени, кому-то в другой.
StjarnornasFred
15.12.2023 19:55Удивительно странный вопрос с учётом того, что программирование - это написание программ, а программа - это и есть совокупность алгоритмов. Так что знание и понимание алгоритмов как дисциплины - не просто полезный, но строго обязательный навык. Это всё равно что спросить "нужно ли водителю знать ПДД" или "должен ли врач знать анатомию".
Zara6502
15.12.2023 19:55вы немного запутались, автор во фразе "нужно ли знать алгоритмы" говорит о знании определенных алгоритмов для решения конкретных задач - поиск, сортировка, сжатие и т.п. То есть классы задач, которые являются универсальными алгоритмами.
А вот то о чем говорите вы - это создание неуниверсального алгоритма. Если бы написание вами программы было универсально, то мы давно имели бы в библиотеке std всю вашу программу. Но в реальности в библиотеки попадают в основном умножения матриц, поиски и т.п. Так что ваше описание уместно, но не в тему.
MasterPeaceMC
15.12.2023 19:55Алгоритмы - и есть программист. Программист - это и есть алгоритмы, квинтесенция алгоритмов, газонокосильщик алгоритмов.
GospodinKolhoznik
15.12.2023 19:5590-е это не начало компьютерной эры человечества, более того, к тому времени отрасль уже успела пройти кризис видеоигр 80х, а многие вкусные и легкодоступные плоды отрасли уже были съедены. В плане научной карьеры в computer science уже почти ничего не оставалось для новых открытий, а в плане бизнеса отношение заработанных денег к деньгам, затраченным на разработку ПО тоже уже прошло свой пик.
Да, тогда всё было ещё далеко не так плачевно, как сейчас, океан всё ещё был голубым, а не багровым и работа программиста ещё была творческой, а не рабским трудом на скрам-галере, но это был уже не золотой век, скорее серебряный.
vitiok78
15.12.2023 19:55Почему же программисту всё же надо знать, или хотя бы быть знакомым с алгоритмами и структурами данных?
Поясню при помощи аналогии. В 19-м веке медицина уже серьёзно развивалась, хирурги делали уже довольно сложные операции, прекрасно зная строение человеческого тела. Но всё равно эпидемии внутри больниц уносили огромное количество жизней. Например, если в родильном отделении у кого-то из женщин начиналась родильная горячка, то эпидемия в среднем уносила жизни 60% женщин в этом отделении. И вот один венгерский врач сделал открытие: если тупо мыть руки и стерилизовать инструменты перед тем, как покопаться у очередной беременной в интересном месте, то процент смертей резко снизился с 60% до 1%.
К чему я это? А к тому, что вам могут дать такую задачу, которую за 5 минут можно эффективнейшим образом решить с помощью какого-то известного алгоритма. Но... Вы алгоритмы не изучали, и поэтому даже не подозреваете, что такой метод существует. И гуглить не будете, потому что не знаете, что это поможет, не знаете, как сформулировать запрос. В итоге вы весь рабочий день изобретаете свой велосипед, который, скорей всего, будет далёк от эффективности известного алгоритма. И да, ваш велосипед точно так же может быть в 60 раз хуже, как и эта ситуация с роженицами.
Поэтому, совет: структуры данных изучите основательно, потому что они очень часто будут вам встречаться, а с алгоритмами хотя бы ознакомьтесь, чтобы в нужный момент ваш мозг подсказал вам, что в этой конкретной задаче можно использовать вот этот конкретный алгоритм, реализацию которого и загуглить быстренько...
Aldelt
15.12.2023 19:55Прикольная статейка, заставляет задуматься над интересными мыслЯми, и при этом написана довольно интересно. Автор статьи может вполне ходить на лекции в школы или вузы с данной статьёй и уверен дети будут слушать, для школьников некоторые места могут быть сложными для осмысления, но их не сложно переработать в более простые.
А я сам пошёл думать как использовать полученную информацию и переосмысливать всё содеянное раньше)
TimMoor
15.12.2023 19:55Алгоритмы, безусловно, как и любые знания нужны и не только программистам. Сказать мягче, знание, что есть алгоритм или похожий алгоритм, уж точно не помешает. А сам алгоритм можно всегда найти, как здесь писали, либо в книге, либо на просторах инета.
Автор же все свои "наивные" с его точки зрения алгоритмы реализовывал с помощью самых передовых алгоритмов, например, сортировки, зашитых в компиляторах. Это как пользование сотовым телефоном, нажал наивно пальцем по монитору или кнопке и готово, можно вести диалог. Никаких наук знать не надо, тем более зачем изучать.
И, да, ему не довелось применить какой-либо алгоритм для убыстрения своих задач. Следует только посетовать, что не попалась ему действительно сложная задача, в которой нужно не изобретать "наивный" алгоритм, а применить существующий из огромного набора.
Навскидку, нахождение НОД (наибольший общий делитель) двух чисел можно решать "наивным" алгоритмом, разложив на множители каждое число и выбрав одинаковые. А можно применить алгоритм Евклида. Для небольших чисел разница во скорости - мизерная, а для больших - существенная. Ну и от железа многое зависит, для современных компьютеров разница даже для достаточно больших чисел будет небольшая. Вот и возникает иллюзия - алгоритмы не нужны!
когда я вижу взрослого дядю, который не может в это «вдуплить».
Обучал программированию и школьников, и взрослых. Нередко встречаются люди с, я бы назвал (да простят меня профессионалы), "алгоритмическим кретинизмом", по аналогии с географическим. Линейный алгоритм даже с условным переходом объяснить, еще куда ни шло, а вот цикл... не "вдупляют" хоть тресни. Не страшно! Можно пойти в юристы, или на худой конец в HR-ы :).
starik-2005 Автор
15.12.2023 19:55А с чего Вы взяли что автору не довелось использовать алгоритмы для убыстрения своих задачь? Как минимум три раза удалось. И да, я использовал квиксорт в проекте флорист2 (ну помимо описанного двоичного поиска).
heartdevil
15.12.2023 19:55Я думаю, вопрос нужно или не нужно знать алгоритмы и структуры данных, как и ответ почти на все любые другие вопросы, лежит где-то по середине. Все это нужно знать, но в меру. Мера зависит от вашей работы. В науке все это нужно знать, в клепании вебсайтов все это не нужно. Тут дело же в том, умеет ли разработчик думать в правильном русле, когда надо.
К примеру две ситуации:
1) Разработчики которые не хотят изучать алгоритмы, говорят, а вот когда надо тогда разберемся. На самом деле, разобраться с проблемой требующей знания алгоритмов или там структур данных -- не тривиальная задача. Вы может и разберетесь, но на уровне "черного ящика". Возможно, этого будет и достаточно, а возможно и нет, и тогда без мат. базы вы пойдете спрашивать как раз тех, кто сечет. А может быть еще хуже. Вы даже не поймете, где проблема.
2) Разработчики которые секут в алгоритмах, но имею мало опыта в промышленном программировании. Вот они могут никогда не встретить задач, требуюищх их квалификации при работе, но отсутствие опыта - это прямолинейный процесс. Человек, который изучал алгоритмы и наработал такую вот мат. часть, скорее всего, спокойно наберет такой же опыт в промышленном программирвоании, которого ему не хватает. А вот, человек, который имеет опыт в промышленном программировании, далеко не факт, что сможет в алгоритмы и структуры данных.
То есть, один, как бы "доказал" что умеет думать, а второй доказал,что имеет опыт. И вот иметь такой ахеренный опыт, который итервьюера приведет в восторг, ну это надо еще умудриться получить в жизни.
Leetc0deMonkey
15.12.2023 19:55Печально конечно наблюдать за деградацией индустрии. 20-30 лет назад придумывались высокоуровневые ЯП чтобы упрощать программирование. Придумали Java и GC чтобы программист целиком посвящал себя решению задач бизнеса, а не заморочкам с выделением памяти и т.п. Придумали Delphi чтобы освободить дорогостоящих высококвалифицированных программистов от нудного формошлёпства. Сами C, asm никуда при этом не девались и продолжали решать свои низкоуровневые задачи. Но что-то поломалось в индустрии и она развернулась вспять. Сначала все начали неявно лепить свои реализации недоСУБД. Ессно если обрабатывать стомиллионов записей там где их обрабатывать не положено, то это будет тормозить. "Решили" эту проблему тем что программист бизнес-логики должен лично знать алгоритмы. Дальше что? Джонсоны перекладывать на C будем? Или чтобы быстро отрисовать красную кнопку программист должен будет знать физику кремния, как 50 лет назад?
haqreu
Просто оставлю ссылку:
https://ru.wikipedia.org/wiki/Сортировка_вставками