Здравствуйте, Евгений Музыченко, Вы писали:
M>>в ядре вполне может быть востребованной операцией.
ЕМ>В ядре эта операция востребована только при проверке адресов, а такие проверки сопутствуют только достаточно редким и/или масштабным операциям. Разница между проверкой одного разряда и сравнением с переменной там даже в тестах будет ниже статистических погрешностей.
Не буду спорит, не располагаю информацией.
M>>заранее всё пытаться предусмотреть — это даёт высокую степень вероятности, что продукт так никогда и не выйдет.
ЕМ>Да, когда предусматривание требует сколько-нибудь заметных затрат. А затраты на обоснованный выбор фиксированной границы — 640, 512 или 736 — по определению больше затрат на реализацию через переменную и системный запрос. Только выбор наобум может быть дешевле.
Здравствуйте, netch80, Вы писали:
N>Где это у нас автоматический перенос программ?
В винде. 32-разрядная программ автоматически идет под 64-разрядной виндой в той же линейной модели, а 16-разрядная идет под 32-разрядной в искусственно создаваемой 16-разрядной модели.
N>A0000-BFFFF видеопамять всех видов N>C0000-DFFFF область расширителей N>E0000-FFFFF BIOS (да, занимал сильно больше 64KB, начиная ещё с AT)
Это все устаканивалось почти десяток лет, а изначально выбор границы в 640 кб был практически произвольным. В итоге, как известно, в одних машинах было множество неиспользуемых дыр в АП, а в других все служебное не влезало в 384 кб, и приходилось переключать.
N>Ну да, с запасом.
Да, выбранным практически наугад.
N>И не надо вспоминать про "хватит всем", этот миф давно развенчан.
Миф — то, что это было сказано Гейтсом. Реальность — то, что примерно в том же смысле цифра была озвучена на каком-нибудь совещании, в качестве наиболее приемлемой оценки. Хотя фиксации конкретной цифры вовсе не требовалось.
N>Вот я и пытаюсь понять, где у тебя граница между "ряд основных" и "подавляющее большинство остальных".
Логика предельно проста, она такая же, как и в программировании: если конкретная величина заранее неизвестна, то она оформляется в виде переменной. Если затраты на работу с переменной чрезмерно велики, то для оптимизации используются приемы вроде констант или макросов. Если константа самоочевидна (единица как минимальное натуральное число, двойка как основание двоичной системы и т.п.), то нет смысла вводить переменные или константы One/Two.
N>когда стало _легко_ делать вариабельные адреса, то это стали делать.
Когда было тяжело сделать один вариабельный адрес на всю систему?
N>Заметь, MCA, на которой это впервые появилось, это ~1987. PCI это 1991. Прогресс был стремительным за это время, и возможность перешла из дорогого сегмента в общий. Но и то — вначале PCI имел подпорки для AGP, для ATA и ещё для чего-то, отдельными требованиями в стандарте. А это такая же фиксация.
N>описания северного моста, то у него на корневой PCI шине дофига фиксированных устройств
Да и ради бога — это не добавляет сколько-нибудь заметных неудобств в процесс аппаратного проектирования/сопряжения в целом, где многое завязано на физические параметры. Ситуация, в которой северный мост вдруг изымается из одной системы и встраивается в другую, маловероятна. Ситуация, в которой это происходит с программой, почти неизбежна.
N>не из какого-то упрямства, а в порядке поиска границ. Ты сам допускаешь, что какие-то значения должны быть константными. Но чётких критериев разграничения не дал.
Это границы разумного.
N>Какие нафиг N и какие M?
M — объем адресного пространства, доступного пользователю, N — объем АП ядра.
N>Чему они могли бы быть равны?
Конкретным объемам, доступным в данной системе. Во времена, когда 2 Гб стало не хватать уже много кому, объем всего ядра не превышал нескольких десятков мегабайт. Соответственно, M было бы равно 3.9 Гб, а N — 0.1 Гб. 3.9 Гб для прикладных процессов, за совершенно ничтожную цену.
N>Вот потому и делали 2:2, 3:1 и для особых извращенцев — 3.5:0.5
А могли бы сразу добавить один конфигурационный параметр для границы, и избежать частных случаев навсегда.
N>расскажи, в чём именно непродуманность.
В упор не понимаю, что еще нужно рассказать. Но есть отчетливое впечатление, что Вы упорно косите под дурачка.
N>Им соответствует функциональность типа "возить до 4 человек весом до 100 кг с грузом в объёме до двух обычных чемоданов, со скоростью до 150 км/ч". А какого размера будет при этом машина — это уже как раз вопрос реализации.
И какова вероятность, что ширина машины будет превышать ее длину? А вероятность того, что в ряду будет сидеть нецелое количество пассажиров?
EM>>Неоправданной фиксацией было бы, например, искусственное, произвольное разделение багажника на секции
N>У меня что в старой, что в новой машине такое разделение есть. Под основным дном багажника место для запасного колеса.
У Вас не то разделение. Разделение, о котором я говорю — это стенка поперек багажника по всей его высоте, чтобы Ваш электронасос положить в одну из секций. Изначально она стоит посредине, но за конечную плату ее можно передвинуть на полметра в сторону. Места в малой секции все равно будет больше, чем нужно для насоса, но класть туда что-то еще будет запрещено ПДД.
N>я туда рядом с колесом закидываю всякие мелочи типа ключей, но не смог впихнуть электронасос для колёс.
А то колесо в каждой машине разного размера, да?
N>Для типового применения всё сделано правильно.
Если бы делали так же, как сделано в NT, то вместо багажника у Вас был бы прицеп, в котором одиноко болталось бы одно запасное колесо. В премиальных моделях этих колес было бы четыре, но размер прицепа всегда был бы одинаковым.
N>Большинство наших розеток ограничены 10A.
Но Вы же знаете, почему, да?
N>Я всё-таки не вижу, где эти ограничения были бы настолько неоправданны, что заставили бы страдать индустрию без причины на длительный срок.
Ну, раз никто не страдал по поводу нехватки сперва 640 кб, потом двух гигабайт, а затем трех, то надо признать, что XMS/EMS, PAE и тому подобное создавались, внедрялись и переделывались из чистого энтузиазма, без малейшей производственной надобности.
N>как только упирались в них, достаточно быстро находился вариант решить проблему переходом за следующий порог, который при этом был в разы дальше.
То есть, классика: сперва создаем проблему, затем героически ее решаем.
N>чтобы без порога вообще — такого не бывало, потому что мы в реальном мире.
Реальность мира диктует только размер переменной для хранения границы доступного АП: в 32-разрядных системах — четыре байта, в 64-разрядных — восемь.
Re[6]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Marty, Вы писали:
M>Микроконтроллеры сейчас тоже не на рассыпухе, но для них ты это оставляешь
Микроконтроллеры, в большинстве своем — сильно ограниченные изделия, где при гигантских тиражах ощутимы даже небольшие излишества. Я уже как-то говорил, что Ваши любимые STM32 — капля в море всех МК, выпускаемых и применямых по миру.
Ну и сравните вероятность, с которой программа, сделанная для МК одной модели, без доработки вдруг окажется в другой, с вероятностью такой миграции с одной винды на другую.
Re[7]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Микроконтроллеры сейчас тоже не на рассыпухе, но для них ты это оставляешь
ЕМ>Микроконтроллеры, в большинстве своем — сильно ограниченные изделия, где при гигантских тиражах ощутимы даже небольшие излишества. Я уже как-то говорил, что Ваши любимые STM32 — капля в море всех МК, выпускаемых и применямых по миру.
Наши любимые STM32 — это большая часть мира микроконтроллеров. Потому что не надо сравнивать какой-нибудь пик, который один раз запрограммировал инженер-железячник, и который ушел в миллионную серию, и STM32, для которых размер серии измеряется единицами, десятками, может быть сотнями или тысячами штук, на которых пилятся всевозможные изделия самого разного вида.
В количестве произведённых единиц пик или msc51 конечно уделает STM, но не по разнооборазию решаемых задач.
ЕМ>Ну и сравните вероятность, с которой программа, сделанная для МК одной модели, без доработки вдруг окажется в другой, с вероятностью такой миграции с одной винды на другую.
А МК одной модели — это как? В текущей конторе есть ровно два вполне конкретных МК, на которых пилят всё, один из семейства F4, другой из F1. Вот вообще конкретные версии, F429II и ни шагу влево вправо. В предыдущей конторе — это могли быть STM32F1/F3/F4/L0, причем в любой их версии, начиная от количества оперативы и флеша, и заканчивая наличием доступной периферии.
Здравствуйте, Marty, Вы писали:
M>Наши любимые STM32 — это большая часть мира микроконтроллеров.
Какого именно мира? Как вы его измеряете?
M>не надо сравнивать какой-нибудь пик, который один раз запрограммировал инженер-железячник, и который ушел в миллионную серию
И применений таких пиков по миру — десятки тысяч минимум. Столько же AVR'ов, еще больше Holtek'ов и прочих.
M>STM32, для которых размер серии измеряется единицами, десятками, может быть сотнями или тысячами штук, на которых пилятся всевозможные изделия самого разного вида.
И сколько это будет, если все перемножить?
M>В количестве произведённых единиц пик или msc51 конечно уделает STM, но не по разнооборазию решаемых задач.
А что, распространенность в мире обсуждаемой винды измеряется разнообразием решаемых на ней задач? Подавляющее большинство экземпляров обслуживает браузер, игры и что-нибудь офисное.
M>А МК одной модели — это как?
Это с одинаковой конфигурацией выводов, портов, памяти, таймеров, ЦАП/АЦП и прочего.
Re[9]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Наши любимые STM32 — это большая часть мира микроконтроллеров.
ЕМ>Какого именно мира? Как вы его измеряете?
На них решается большинство задач
M>>не надо сравнивать какой-нибудь пик, который один раз запрограммировал инженер-железячник, и который ушел в миллионную серию
ЕМ>И применений таких пиков по миру — десятки тысяч минимум. Столько же AVR'ов, еще больше Holtek'ов и прочих.
Не путай количество экземпляров с количеством применений
M>>STM32, для которых размер серии измеряется единицами, десятками, может быть сотнями или тысячами штук, на которых пилятся всевозможные изделия самого разного вида.
ЕМ>И сколько это будет, если все перемножить?
Полагаю, гораздо больше, чем однотипных изделий хоть какого типа
M>>В количестве произведённых единиц пик или msc51 конечно уделает STM, но не по разнооборазию решаемых задач.
ЕМ>А что, распространенность в мире обсуждаемой винды измеряется разнообразием решаемых на ней задач? Подавляющее большинство экземпляров обслуживает браузер, игры и что-нибудь офисное.
Я потерял нить беседы, если честно
M>>А МК одной модели — это как?
ЕМ>Это с одинаковой конфигурацией выводов, портов, памяти, таймеров, ЦАП/АЦП и прочего.
Тогда те же STM32F4 — это сотни, если не тысячи разных вариантов
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Где это у нас автоматический перенос программ?
ЕМ>В винде. 32-разрядная программ автоматически идет под 64-разрядной виндой в той же линейной модели, а 16-разрядная идет под 32-разрядной в искусственно создаваемой 16-разрядной модели.
Ну вот ты сам себе и ответил, что та 16-битная была уже искусственно созданной. В случае же 32/64 это тоже намеренно оставленный переходник. Могли и не оставлять, но тогда переключение между legacy и long (в их терминах) было бы сильно дороже.
А в исходниках ты тем более так легко не сделаешь.
N>>A0000-BFFFF видеопамять всех видов N>>C0000-DFFFF область расширителей N>>E0000-FFFFF BIOS (да, занимал сильно больше 64KB, начиная ещё с AT) ЕМ>Это все устаканивалось почти десяток лет, а изначально выбор границы в 640 кб был практически произвольным.
Да. А теперь обрати внимание, что первые PC могли иметь вообще 16KB памяти. Даже меньше одного сегмента. Это самая дешёвая конфигурация. А память тогда (1981) стоила 8.8$/kB, то есть 64 обходилось бы в 560$ тогдашних (а для теперешних надо умножить на 5-7).
Итого посчитай по нынешнему: 2800$/64KB. 28000$/640KB.
Никто такой памяти не ставил до середины 80-х, и то только самые толстые.
Вот примерно с 1986-87 стало возможно заполнить эти 640 полностью для большинства, когда цена реально драматически упала (1986 это 300$/MB, 1987 уже 150 — о таком прогрессе сейчас можно только тоскливо мечтать).
Конечно, сидя в СССР за занавесом мы с тобой эту историю пропустили. И теперь тебе кажется, что эта граница могла быть достигнута с самого начала.
А тогда думали иначе. При том, что архитектуры более широкого плана были известны давно, про 386-й с момента его выхода (1985) знал каждый в теме, это не считалось проблемой. Кому мало этой памяти — идите в расширители и в 32 бита.
Вот почему окончательный переход с реального режима и MS-DOS застрял фактически лет на 10 (когда с Win95 стали забывать про DOS), вот это действительно серьёзный повод обсудить. То ли расчёты прогресса оказались поспешными, то ли авторы софта застыли в кривой позе и потеряли время непонятно на чём. Ну Microsoft экспериментировал с Xenix, это да. NT они начали рисовать году в 87, судя по первым копирайтам.
Тут я бы послушал, какие грабли и где были расставлены. У кого есть ссылки с хорошим описанием, поделитесь.
EM> В итоге, как известно, в одних машинах было множество неиспользуемых дыр в АП, а в других все служебное не влезало в 384 кб, и приходилось переключать.
Я согласен с тем, что область видеопамяти надо было бы переместить повыше, тогда мы бы упёрлись не в 640, а в 768K или даже выше (если взять видеорежим попроще). Тут недоработали. Но опять же со взглядом из 1981 считалось, что прежде чем упёрлись бы в этот предел, архитектура поменялась бы так, что он перестал бы быть важным.
Кстати, ещё один момент тут — Intel при проектировании 286 мог сделать, что эти области мапятся в верхний предел адресного пространства. Это было сделано ещё в PDP-11: 16-битные адреса с 0b111 вначале получали для обеих размерностей (18 и 22 бита) все старшие единицы, если выключен DAT. Но Intel как всегда протупил на ровном месте, и мы получили проблему в виде legacy 1MB блока.
N>>Ну да, с запасом. ЕМ>Да, выбранным практически наугад.
А тогда и невозможно было иначе. Что оно составило больше половины адресного пространства — уже было успехом для последующей работы. Могли и 256KB ограничиться, а дальнейшее позанимать на разные разности. Может, это было бы и лучше в том плане, что переход на следующую разрядность прошёл бы более ровным путём.
N>>Вот я и пытаюсь понять, где у тебя граница между "ряд основных" и "подавляющее большинство остальных". ЕМ>Логика предельно проста, она такая же, как и в программировании: если конкретная величина заранее неизвестна, то она оформляется в виде переменной. Если затраты на работу с переменной чрезмерно велики, то для оптимизации используются приемы вроде констант или макросов. Если константа самоочевидна (единица как минимальное натуральное число, двойка как основание двоичной системы и т.п.), то нет смысла вводить переменные или константы One/Two.
Спроецируем на IBM PC. Если я тебя понял правильно, то пока мы не можем ничего сделать с 20-битной адресацией, нам нужно было бы сделать какую-то ячейку в, как было принято, BIOS data area с указанием, где сидит видеопамять (так как это у нас основная граница). Пусть в первых версиях она сидела от 0xA0000. Но пришло время ужаться — убрали неиспользуемый кусок в ROM extension area и в extended BIOS и посадили память, например, 0xE8000. В результате имеем уже не 640KB, а 928KB. Так?
И тогда я скажу в третий, наверно, раз за этот комментарий, что когда шёл стремительный прогресс (быстрее того 2 раза за 1.5-2 года что по закону Мура), эффект типа "в 2 раза" никого не интересовал, цикл от идеи до внедрения это 3-5 лет и потому эффект нужен такой, чтобы давал минимум 16 раз, а лучше 256. Вот переход на 24 бита адреса в 286 и 32 в 386 это сила, а 928 вместо 640 это ни о чём. И таки я очень рекомендую вернуться к вопросу, почему MS-DOS с реальным режимом умерли не в 1985, а в 1995 ("умерли" тут в смысле "перестали вкладываться новые силы в разработку под них с нуля").
N>>когда стало _легко_ делать вариабельные адреса, то это стали делать. ЕМ>Когда было тяжело сделать один вариабельный адрес на всю систему?
Какой именно из? Их там несколько.
N>>не из какого-то упрямства, а в порядке поиска границ. Ты сам допускаешь, что какие-то значения должны быть константными. Но чётких критериев разграничения не дал. ЕМ>Это границы разумного.
Вот и вопрос в согласовании понятия "разумное", при условии, что ты, похоже, не понимаешь, в какой обстановке всё это происходило. И нет, я не про политику.
N>>Чему они могли бы быть равны? ЕМ>Конкретным объемам, доступным в данной системе. Во времена, когда 2 Гб стало не хватать уже много кому, объем всего ядра не превышал нескольких десятков мегабайт. Соответственно, M было бы равно 3.9 Гб, а N — 0.1 Гб. 3.9 Гб для прикладных процессов, за совершенно ничтожную цену.
И снова упускаешь две вещи.
1) Это ещё период заметного роста свойств, хоть и не такой безумный, как в 80-х. Приложения, которым не хватает 2GB, но хватает 3.9GB, очень редки — это узкая полоса. Большинству или достаточно меньше (99+%), или не хватает уже 4GB (1-%). Основное направление развития уже давно это переход на 64 бита, причём Windows на x86 в этом смысле глубокая отсталая провинция. Юниксы начали переходить ещё в 90-х, у нас была машинка на Alpha в 1999. MIPS64 появился в 1999, ну нам не достался SystemZ — это 2000. Когда там первая Windows на amd64? 2005?
2) Вся архитектура ядер оптимизирована на случай, когда всю оперативную память плюс адресное пространство ввода-вывода можно полностью отобразить на ту часть общего адресного пространства, что отведена ядру. В случае 2+2 и оперативной памяти до 1.5GB это выполняется. В случае, например, 4GB RAM уже нет. При 3+1, 3.5+0.5 — тоже нет. При невыполнении этого главного условия начинаются частые переключения страниц и перегонки между ними. В Linux явно ругались на это, что надо вводить так называемые bounce buffers. Затраты времени на эти операции. И зачем оно такое для менее 1% пользователей, если при переходе на 64 это снова не будет нужно?
Повторюсь, ты тут один-к-одному провинциал из села, который не видел выше двухэтажного дома, начинаешь рассказывать, как строить пятиэтажные тем, кто только что закончил квартал как минимум 9- и 16-этажных, а в планах следующий на 25. Сконцентрировавшись на Windows, ты тут пропустил, где в этом плане шёл прогресс задолго до.
N>>Вот потому и делали 2:2, 3:1 и для особых извращенцев — 3.5:0.5 ЕМ>А могли бы сразу добавить один конфигурационный параметр для границы, и избежать частных случаев навсегда.
Не нужно. См. выше.
N>>расскажи, в чём именно непродуманность. ЕМ>В упор не понимаю, что еще нужно рассказать. Но есть отчетливое впечатление, что Вы упорно косите под дурачка.
Спасибо. Я не буду столь же интенсивен в плане личных качеств, но см. выше про провинциала. Проблемы, которые кажутся вам критичными, не являлись такими для большинства или по крайней мере не планировались такими.
[skip аналогии, которые пошли не туда и не актуальны вообще]
N>>Я всё-таки не вижу, где эти ограничения были бы настолько неоправданны, что заставили бы страдать индустрию без причины на длительный срок.
ЕМ>Ну, раз никто не страдал по поводу нехватки сперва 640 кб, потом двух гигабайт, а затем трех, то надо признать, что XMS/EMS, PAE и тому подобное создавались, внедрялись и переделывались из чистого энтузиазма, без малейшей производственной надобности.
Нет, это уже демагогия с вашей стороны. А вот на что рекомендую обратить внимание по каждой этой технологии, это во сколько раз они расширяли возможности.
N>>как только упирались в них, достаточно быстро находился вариант решить проблему переходом за следующий порог, который при этом был в разы дальше. ЕМ>То есть, классика: сперва создаем проблему, затем героически ее решаем.
"Героически" было только по причине неоправданной задержки с MS-DOS, и я уже в 4-й раз вынужден сказать, что именно её продлённое существование тут является ключом и вопросом на полезное обсуждение (хотя бы в историческом плане).
Даже задержка создания общедоступной 64-битной Windows, по сравнению с Linux, NetBSD и прочими, которые к моменту выхода amd64 в железе были полностью готовы — не насколько интересна и существенна.
N>>чтобы без порога вообще — такого не бывало, потому что мы в реальном мире. ЕМ>Реальность мира диктует только размер переменной для хранения границы доступного АП: в 32-разрядных системах — четыре байта, в 64-разрядных — восемь.
И снова не учитываете, что действия типа "а сейчас мы забабахаем все 64 бита на физический адрес!" приведут просто к тому, что подорожавший на 20% продукт не выиграет соревнования с конкурентами.
Здравствуйте, Евгений Музыченко, Вы писали:
aik>>А причина может быть простая — одним битом удобно управлять трафиком на системной шине: нет бита == RAM, есть бит == MMIO, и это, например, прибито гвоздями в железе.
ЕМ>В каких-нибудь микроконтроллерах это может быть и удобным, но не в вычислительных же (в широком смысле) системах.
Ну так и при проектировании процессора тоже может быть удобным.
Просто на тот момент это была заведомо большая величина, и проектировщику на тот момент наверное казалось совсем без разницы, 2 или 3Гб, все-равно овердофига.
А если кто и задумывался о будущем, вполне справедливо мог рассудить, что к тому времени и архитектура другая будет.
Просто никто не впрягается менять архитектуру, пока сильно не прижмет.
Re: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Сперва были и 640 кб доступной обычной памяти, и жестко заданные адреса областей внешних устройств, хотя все это можно было запихать в BIOS, и возвращать конкретные адреса по запросам. Затем в 32-разрядной винде было 2+2 Гб, которые героическими усилиями переделали в 3+1. В 64-разрядной винде снова 8+8 Тб. Сейчас читаю про макось — и там тоже сплошные явно определенные константы.
Я тут книжку читаю, про AS/400. Вот там сделано правильно.
Почему в других частях IT это иначе? Потому что:
1) Там нет умных людей
2) Там нет человека с железной палкой
3) Там умным людям железную палку не дают
4) Там умные люди железную палку брать не желают
Re[3]: Откуда такая неизбывная приверженность к константам?
Вот у меня ноутбук на ALT Linux с 16 гигами ОЗУ. Появляется сообщение о нехватке памяти, если одновременно запущены Telegram, Postgres, Kafka в Докере, браузер Chromium с несколькими вкладками и Java приложение в IDEA (т.е. стандартное рабочее окружение). И затем обязательно что-то падает, обычно это браузер. Огромное спасибо тем, кто решил, что одному процессу нормально жрать несколько гигов, а у блогов и форумов вроде Хабры должны быть такие же системные требования как у Фотошопа. Впрочем, JavaScript это в целом раковая опухоль интернета...
«Закон Вирта» — шуточное высказывание Никлауса Вирта (1995) в духе законов Паркинсона: «программы становятся медленнее куда шустрее, чем компьютеры становятся быстрее»[1][2], используемое для демонстрации нарастающих проблем с производительностью программного обеспечения, несмотря на прогресс аппаратного.
Мннение Андрея Столярова, бывшего преподавателя МГУ, автора лучших русскоязычных учебников по программированию:
Только сначала надо всех вебщиков перестрелять к чёртовой бабушке, поскольку браузеры и "современный" веб на таких машинах не работают. Остальное работает нормально, у меня до сих пор eeepc901 в эксплуатации.
У Гугла есть свои вполне определённые цели, и чтобы их достичь, нужно кроме всего прочего заставить весь мир то и дело "обновлять" браузеры. В 2010 году я прекрасно пользовался браузерами 8-10-летней (на тот момент) давности, и всё работало; сейчас в инете постоянно попадаются сайты, не желающие работать с браузером, которому меньше года, и один из основных таких -- поганый ютЪюбик. А ещё Гуглу очень нужно сделать так, чтобы браузеров было как можно меньше — выкинуть с рынка всех независимых разработчиков, и перманентное повышение сложности протоколов и форматов явно делается специально для этого.
Несомненно, https тут лишь один из многих инструментов, что не исключает.
Редко сейчас вижу (особенно среди программистов) тех, кто способен думать, а не радоваться всему подряд. Сколько визгу было на тему новых версий флэша, JS`а, HTML5, WebAssembly, Java, Python и т.п. Только со временем приходит осознание, того что вреда от всего этого больше, чем пользы. Причем осознается это обычно в тот момент, когда покупаешь новый компьютер и понимаешь, что "быстрее" не стало. Все ушло на компенсацию большей прожорливости тех же самых программ.
Я недавно проводил эксперимент. Я работал за P4 с 512 МБайт ОЗУ и Slackware (тогда еще 14.2). На этом железе работало все, что мне надо. Все, кроме "современного" браузера. Поэтому как минимум я не один, кто ощущает регресс в сфере софтовыдреста современных "программистов".
Для тех серверов, где необходимо полностью загружать в память БД, должны использоваться специальные аппаратные архитектуры. Не те, что стоят на массовых персональных компьютерах у обычных пользователей. Раньше были мейнфреймы, например.
Как запру я тебя за железный замок, за дубовую дверь окованную,
Чтоб свету божьего ты не видела, мое имя честное не порочила…
М. Лермонтов. Песня про царя Ивана Васильевича, молодого опричника и удалого купца Калашникова
Re[2]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Слава, Вы писали:
С>Я тут книжку читаю, про AS/400. Вот там сделано правильно.
По AS/400 вроде бы существует только одна описательная книжка от Френка Солтиса и она на 99% состоит из технической рекламы. И там не сказано, что, в современных терминах, это одна JVM/.NET виртуальная машина, растянутая на всю физическую машину (или виртуалку) с контролем доступа между юзерами, собственным языком исполнения, похожим на байткоды JVM и .NET с точностью до переименования команд (и теми же методами исполнения — AOT и JIT), реляционной базой данных вместо файловой системы (для особо некоторых можно подключить и FS), и посоленной сверху терминологией IBM везде вместо средне-привычной по индустрии. Фактически, её описание, для современных ITшников, можно было бы свести к полстраницы вместо тех двести или сколько там спама в этой книге.
Можно, конечно, сказать, что это всё "правильно" по сравнению с голым железом и его ограничениями, но работает-то она поверх того же голого железа (POWER разных поколений). Ну понятно, что в JVM, если ты не лезешь в unsafe, пофиг, сколько битности в указателе. Но уже целочисленные типы данных имеют те же ограничения, что и везде.
С>Почему в других частях IT это иначе? Потому что:
С>1) Там нет умных людей С>2) Там нет человека с железной палкой С>3) Там умным людям железную палку не дают С>4) Там умные люди железную палку брать не желают
"В других частях IT" в первую очередь была жесточайшая конкуренция за ресурсы и даже пара процентов имела значение. И когда наконец сложились условия, чтобы Java выстрелила, это случилось, и она сделала то же самое по сути что та же AS/400, только поверх более привычной среды. Автоматическое управление памятью — на месте и в полный рост. Хочешь всё делать через БД? Пожалуйста, тебе все интерфейсы, только без загоняния той же "железной палкой" в прокрустово ложе. Миллионы энтерпрайз-программистов ничего больше не знают и счастливы. Что ещё нужно?
А IBM умела в те времена (и в какой-то мере умеет и сейчас) заставить купить даже заведомо неэффективное на порядки (как было с AS/400 вплоть до ~2000 года) по принципу "никого не увольняют за покупку от IBM". Хакер с портфелем и круглой печатью сильнее хакера с клавиатурой.
Здравствуйте, Worminator X, Вы писали:
WX>Вот у меня ноутбук на ALT Linux с 16 гигами ОЗУ. Появляется сообщение о нехватке памяти, если одновременно запущены Telegram, Postgres, Kafka в Докере, браузер Chromium с несколькими вкладками и Java приложение в IDEA
Я правильно угадал, что больше всего жрет браузер? У себя я еще не видел более жручего приложения (в игры не играю, фото/видео не монтирую).
WX>Огромное спасибо тем, кто решил, что одному процессу нормально жрать несколько гигов
Я не пробовал Chromium, но Chrome и Firefox уже давно создают процессы десятками. Ну ограничите Вы память на один процесс — они запустят их втрое-впятеро, и в итоге сожрут еще больше, ибо накладные расходы вырастут.
WX>у блогов и форумов вроде Хабры должны быть такие же системные требования как у Фотошопа. Впрочем, JavaScript это в целом раковая опухоль интернета...
Это полностью поддерживаю.
WX>Мннение Андрея Столярова
Столярова нужно воспринимать очень осторожно и взвешенно. Он грамотный мужик, у него много разумных высказываний, но на каждое разумное он приводит по нескольку таких, что уши вянут. Ему вообще плохо даются компромиссы, он больше сторонник крайностей.
WX>Для тех серверов, где необходимо полностью загружать в память БД, должны использоваться специальные аппаратные архитектуры. Не те, что стоят на массовых персональных компьютерах у обычных пользователей. Раньше были мейнфреймы, например.
Что в тех мейнфреймах было "специально аппаратного" для поддержки полной загрузки БД в память, чего нет хотя бы в i486?
Re[18]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Sharowarsheg, Вы писали: S>Не помню, чтобы что-то куда-то не помещалось. MultiEdit с дос навигатором помещались везде.
Да ну? Помню, послушал в универе нескольких сокурсников, насколько-де крут DOS Navigator, поставил — через пол-дня снёс нафиг из-за его аппетитов по conventional memory, приходилось выходить в голый DOS, запускать что тебе нужно, далее возвращаться в "навигатор", иначе Not enough memory или недостаточно файловых хэндлов.
пояснение
когда-то давно-двано был файлик config.sys с разными параметрами, кто не застал, рекомендую почитать как ваши деды выживали (ц).
P.S. Хотя с точки зрения оболочки — да, прям много фишек напихано было по сравнению с Нортоном. Было б доступно пару мегов вместо 640К для conventional memory — ценнейшая была бы вещица.
Re[5]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Я правильно угадал, что больше всего жрет браузер? У себя я еще не видел более жручего приложения (в игры не играю, фото/видео не монтирую).
Так они тоже не сами к этому пришли. Лучше переформулировать, что жрёт не браузер, а сайты в нём.
WX>>у блогов и форумов вроде Хабры должны быть такие же системные требования как у Фотошопа. Впрочем, JavaScript это в целом раковая опухоль интернета... ЕМ>Это полностью поддерживаю.
Я честно не думаю, что от замены JS на что-то другое, менее тупое, тут стало бы сильно легче.
Главное таки это возможность сделать толстый сайт и не получить немедленной реакции на это, как в случае установки локальной программы. Каждый месяц по чуть-чуть, по паре процентов увеличивать объём кода и работы на клиентской стороне — и через пять лет существующих процессора и памяти перестаёт хватать и характеристики надо удваивать. Потом придёт следующий сайт... Нет, веб тут в целом сам по себе болезнь, а не конкретное средство его локального оживляжа.
ЕМ>Что в тех мейнфреймах было "специально аппаратного" для поддержки полной загрузки БД в память, чего нет хотя бы в i486?
+1. Меня этот пассаж тоже удивляет.
The God is real, unless declared integer.
Re[6]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, netch80, Вы писали:
N>Так они тоже не сами к этому пришли. Лучше переформулировать, что жрёт не браузер, а сайты в нём.
Это вечная проблема перекладывания ответственности. "Наркоторговцы не виноваты — они лишь отвечают на возрастающий спрос, работайте с потребителями".
N>Я честно не думаю, что от замены JS на что-то другое, менее тупое, тут стало бы сильно легче.
Сильно легче стало бы не от замены, а от изначального ограничения активности ваб-страницы чем-нибудь вроде расширенного CSS, где реализован разумный набор средств взаимодействия (те же спойлеры, деревья, простые реакции на действия пользователя и т.п.). Для подавляющего большинства информационных сайтов этого бы хватило, а кому надо интерактивности — делайте приложения, хоть нативные под ОС, хоть универсальные под единую VM, роль которой сейчас исполняют браузеры.
Хреново ведь стало вовсе не от того, что появился JS, а от того, что его впихнули в заведомо неподходящее средство. Человеку нужно средство доступа к базовым сетевым сервисам, а в нагрузку он получает еще один компьютер. То же самое случилось и с телефонами — человеку нужно средство связи, а в нагрузку он получает кучку средств доставки рекламы и привязки к поставщикам услуг.
N>веб тут в целом сам по себе болезнь
Болезнь — не веб, а его превращение в балаган.
Re[6]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, netch80, Вы писали:
N>Никто такой памяти не ставил до середины 80-х, и то только самые толстые.
Я у Чена наткнулся на описание реального косяка с Win 95, которая отказывалась грузиться, если памяти было больше 480 Мб. То, что для "первичной кучи" отводился блок фиксированного размера, это еще ладно, но то, что наличие памяти, описание которой не влезало в этот блок, приводило к отказу в загрузке — это уже за пределами разумного. Это, блин, уровень студента-второкурсника.
Re[7]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Никто такой памяти не ставил до середины 80-х, и то только самые толстые.
ЕМ>Я у Чена наткнулся на описание реального косяка с Win 95, которая отказывалась грузиться, если памяти было больше 480 Мб. То, что для "первичной кучи" отводился блок фиксированного размера, это еще ладно, но то, что наличие памяти, описание которой не влезало в этот блок, приводило к отказу в загрузке — это уже за пределами разумного. Это, блин, уровень студента-второкурсника.
Remember, Windows 95’s target machine was a 4MB 386SX and a powerful machine had 16MB.
...
One of my friends got 96MB of memory on his machine to test that we didn’t tank under “insanely huge memory configurations” and we all drooled.
Re[7]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, Евгений Музыченко, Вы писали:
N>>Никто такой памяти не ставил до середины 80-х, и то только самые толстые. ЕМ>Я у Чена наткнулся на описание реального косяка с Win 95, которая отказывалась грузиться, если памяти было больше 480 Мб. То, что для "первичной кучи" отводился блок фиксированного размера, это еще ладно, но то, что наличие памяти, описание которой не влезало в этот блок, приводило к отказу в загрузке — это уже за пределами разумного. Это, блин, уровень студента-второкурсника.
Да, хороший пример — хоть и к обсуждаемому вопросу относится весьма боком.
Он такой был далеко не единственный. Например, до времён где-то первой XP, видимый размер ATA дисков обрезался до остатка от деления на 32GB. Причём молча (просто видело мелкую цифру).
Сейчас основной вопрос в скорости реакции на такое. В до-интернетовские времена, когда невозможно было быстро раздавать обновления, лечить могли годами.
А в целом сам стиль кодирования на C/C++ провоцирует на такие ошибки.
The God is real, unless declared integer.
Re[8]: Откуда такая неизбывная приверженность к константам?
Здравствуйте, netch80, Вы писали:
N>видимый размер ATA дисков обрезался до остатка от деления на 32GB.
N>в целом сам стиль кодирования на C/C++ провоцирует на такие ошибки.
Да ладно. В каком языке есть хоть какая-то защита от неправильного применения хоть деления с остатком, хоть обычного деления?
С 480 Мб для Win 95 косяк был не в том, что выбрали фиксированный разумно достаточный размер пула, а то, что вместо игнорирования "лишней" памяти получился отказ в загрузке всей системы. Если и ставился вопрос "а вдруг памяти окажется до хренища?", то ответ "в таком случае надо выйти из ситуации корректно" явно не фигурировал.
Re[8]: Откуда такая неизбывная приверженность к константам?
П>One of my friends got 96MB of memory on his machine to test that we didn’t tank under “insanely huge memory configurations” and we all drooled.
То есть, если Вам вдруг приспичит подключить к одной машине, скажем, 25 или 50 последовательных портов, и система откажется грузиться, Вы воспримете это, как должное?
