Вы пытаетесь исправить изначально провальную тут идею рекурсии
Я просто описал как меня учили и как я учил. На чем вы предлагаете учить рекурсию? У меня сходу разве что ханойская башня всплывает из простого.
И главный вывод - который должен сделать ученик - что рекурсию использовать не надо
Есть еще пара выводов следом за главным) Если стоит тз "использовать рекурсию" - предупреди заказчика что тз некорректно, потом выжми из алгоритма что можно (в примере с Фибоначчи - кэшируй значения). Если есть уверенность что это место не станет узким - используй простое решение. Рекурсия пишется проще всего.
Массив фиксированной длины для бесконечных последовательностей? К тому же Вы забываете что это учебная задача)
Поэтому я и говорю что это отличный пример для оптимизации.
1. решить задачу рекурсией.
2. решить итеративно на 3х переменных
3. уйти в длинную арифметику.
4. развернуть часть цикла в п2 чтобы сократить количество перестановок
5. предварительно посчитанная таблица значений
6. таблица контрольных точек значений от которых идём алгоритмом из п4.
Если длинная арифметика ещё слишком рано на этом этапе обучения - формулируем задачу как "найти последние 9 цифр числа Фибоначчи с номером 1..2^32". Готовая таблица значений для этой задачи если что займёт 16Gb. памяти.
При этом нет однозначного ответа на вопрос "какой алгоритм быстрее?". Быстрее пишется рекурсия, по соотношению затраты/профит - итеративный, быстрее без ограничений памяти - таблица. Это так же некорректно как считать быстрой быструю сортировку Хоара из этой статьи.
Пример с числами Фибоначчи в разделе "рекурсия" как мне кажется следует подавать только под соусом "как не надо делать" а лучше подать этот пример в разделе "оптимизация" с последующим объяснением "как надо делать и почему".
Потому что программист со школы/универа должен понимать что fibonachi(50) в вашей реализации создаст кучу (~2млрд) вызовов и повешает комп (мой ноут справился за 170сек на JS и за 52сек на сях).
Уместнее ряда Фибоначчи тут бы смотрелся факториал или разложение на множители, но тоже с оговорками.
но как?я не знаю ни одного серверного компонента с afr хотя бы 5%, у большинства же afr сильно меньше 1%.
Я насчитал ~1.1%выходов из строя за 9 месяцев когда надо менять сервак целиком (трехзначное число наблюдаемых объектов), а 8.5% получается потому что поставляется достаточно большая номенклатура разных моделей.
да, разумеется. но чем крупнее фирма, тем меньше таких ситуаций.
это не спасает если количество железяк конкретной модели в РФ 1-2-10штук
логичнее по возможности выбирать commodity оборудование
бюджет согласован 2 года назад, проект прошел экспертизу год назад а сейчас оказывается что надо было выбирать модульный матричный коммутатор из масс маркета) при этом в этом же масс маркете рынок видеокартами не могут наполнить)
Я не говорю что такая ситуация у всех - возможно это специфика нашего сектора рынка, но конкретно по ближайшему объекту например куплено и доставлено 15 единиц из 20 по одной из позиций. Клиента не волнует где мы возьмем еще 5, завод и поставщиков тоже не волнует. Заменим на аналог - хорошо, поставим модель вдвое дороже - еще лучше. При этом замечу что некоторые заводы имеют квоту на каждую страну - если условный Казахстан вдруг начнет вместо 10 железяк в год заказывать 100 - поставки довольно быстро встанут. Если выйти из нашего сектора в чистый IT - предполагаю что все не так просто с библиотеками, лезвиями, сетью уровня ядра.
Да вроде об одном. Вы написали что резерва 3-5% хватит чтобы комфортно жить в условиях параллельного импорта, я написал что в нашем конкретном случае - не хватает.
Не поленился и посчитал - у нашей конторы текущий резерв составляет 1.7% по конкретной позиции (сервера), комфортный резерв по этой же позиции с учетом текущих сроков поставки составляет 8.5%. Проблема даже не в том что надо увеличить размеры склада ЗИП в 4-5 раз, проблема в том за счет чего закупить этот объем оборудования. Даже если "забыть" про всех старых клиентов и рассматривать только сейчас заключаемых - на первых контрактах стоимость ЗИПа составит 15-25%. Прибавьте к этому стоимость двойной таможни и двойной доставки.
Конечно если вы последние 5 лет занимаетесь поставкой одной модели сервера с одной памятью с одной моделью HDD - вам достаточно иметь один сервер, 2 плашки памяти и 10 дисков. Но наша математика так не работает. Быть может в комментах кто-то еще посчитает свою статистику.
никто покупая 10 серверов не покупает ещё 10 в резерв, достаточно и одного.
И кстати непосредственно клиенты вполне себе покупают. Мы стараемся уложиться в 10% избыточности если она требуется, но есть объекты с запасом 20%, 100%, 300% (одно устройство работает, 3 в резерве на самом объекте).
Бывает что одна редкая железяка идет клиенту, такую же нам надо иметь в ЗИП - и вот 3-5% превращается опять в 100%.
имея резерв в 3-5% можно спокойно пережить многомесячные сроки поставок
Как показывает наша личная практика (мы не совсем про сервера но близко) - нельзя. Склады в мск и регионах быстро исчерпались в итоге худший простой с февраля по сентябрь.
У нас есть рекомендованный производителем список чего и сколько должно лежать на центральном и региональном складе, он не выполнялся даже в допандемийные времена потому что это замороженные деньги. На складе балластом лежит зип под оборудование снятое с производства, но ходовые позиции могут в любой момент кончится, раньше это можно было решить срочной поставкой, сейчас по ряду позиций мы до сих пор поставок обеспечить не можем и сидим на остатках склада.
Отдельная боль - позиции собираемые заводом на заказ под клиента.
Надо или возвращать результат вычислений из программы
И получить overhead на обман компилятора и работать это будет пока компилятор не поумнеет и не поймет что вы возвращаете результат в никуда.
или говорить компилятору не делать оптимизаций
не делать всех оптимизаций? тогда мы получаем benchmark совсем другого неоптимизированного кода. КМК это повод для warning но никак не для слепой оптимизации.
Дак в статье и написано что нужно "обманывать" компилятор чтобы программа работала как положено. Стирание памяти это не только пароли, но и часть защиты от отладки\взлома например. Что касается записи на диск - видимым будет результат последней записи, значит предыдущие 10 проходов можно оптимизировать, а если следом DeleteFileA дергается то и последний проход не нужен.
Я понимаю когда undefined behavior, тут я не совсем согласен с логикой, но да, мы имеем то что имеем.
Ваша сборка хороша и имеет право, но кмк стоит учитывать ряд моментов.
HP DL360G5 - 3-5тыр
полка MSA20 - 5-10тыр
Возможно я не силен в гугле, но таких низких ценников найти не могу. Ну и давайте не забывать что оно будет очень сильно БУ и с ограниченной гарантией, проработает возможно еще 30 лет а может нет и тогда вопрос доступности запчастей.
X5460 (процы прекрасно тянут plex и прочие задачи)
Основное преимущество - цена. Для хранилки/шлюза не принципиально, для виртуализации или видео - проц 2007 года я бы не взял.
Главный вопрос шум - не у всех есть возможность изолировать полноразмерную стойку в серверной кладовке/гараже а у некоторых еще и очень чуткий сон.
Я наверное что-то делаю не так, но диски дома меняю без выключения и в корпусе без hot-swap, энергопотребление смотрю на UPS да и host систему на домашнем серваке ставил 1 раз; на работе iLo/IPMI не пользовался с момента установки системы. Иметь корзину/iLo/ECC/dual psu хорошо, но гнаться за этим дома?...
Я просто описал как меня учили и как я учил. На чем вы предлагаете учить рекурсию? У меня сходу разве что ханойская башня всплывает из простого.
Есть еще пара выводов следом за главным) Если стоит тз "использовать рекурсию" - предупреди заказчика что тз некорректно, потом выжми из алгоритма что можно (в примере с Фибоначчи - кэшируй значения). Если есть уверенность что это место не станет узким - используй простое решение. Рекурсия пишется проще всего.
Забыл упомянуть формулу Бине - на ней можно показать опасность округления и длинную нецелочисленную арифметику.
Массив фиксированной длины для бесконечных последовательностей? К тому же Вы забываете что это учебная задача)
Поэтому я и говорю что это отличный пример для оптимизации.
1. решить задачу рекурсией.
2. решить итеративно на 3х переменных
3. уйти в длинную арифметику.
4. развернуть часть цикла в п2 чтобы сократить количество перестановок
5. предварительно посчитанная таблица значений
6. таблица контрольных точек значений от которых идём алгоритмом из п4.
Если длинная арифметика ещё слишком рано на этом этапе обучения - формулируем задачу как "найти последние 9 цифр числа Фибоначчи с номером 1..2^32". Готовая таблица значений для этой задачи если что займёт 16Gb. памяти.
При этом нет однозначного ответа на вопрос "какой алгоритм быстрее?". Быстрее пишется рекурсия, по соотношению затраты/профит - итеративный, быстрее без ограничений памяти - таблица. Это так же некорректно как считать быстрой быструю сортировку Хоара из этой статьи.
Пример с числами Фибоначчи в разделе "рекурсия" как мне кажется следует подавать только под соусом "как не надо делать" а лучше подать этот пример в разделе "оптимизация" с последующим объяснением "как надо делать и почему".
Потому что программист со школы/универа должен понимать что fibonachi(50) в вашей реализации создаст кучу (~2млрд) вызовов и повешает комп (мой ноут справился за 170сек на JS и за 52сек на сях).
Уместнее ряда Фибоначчи тут бы смотрелся факториал или разложение на множители, но тоже с оговорками.
Я насчитал ~1.1%выходов из строя за 9 месяцев когда надо менять сервак целиком (трехзначное число наблюдаемых объектов), а 8.5% получается потому что поставляется достаточно большая номенклатура разных моделей.
это не спасает если количество железяк конкретной модели в РФ 1-2-10штук
бюджет согласован 2 года назад, проект прошел экспертизу год назад а сейчас оказывается что надо было выбирать модульный матричный коммутатор из масс маркета) при этом в этом же масс маркете рынок видеокартами не могут наполнить)
Я не говорю что такая ситуация у всех - возможно это специфика нашего сектора рынка, но конкретно по ближайшему объекту например куплено и доставлено 15 единиц из 20 по одной из позиций. Клиента не волнует где мы возьмем еще 5, завод и поставщиков тоже не волнует. Заменим на аналог - хорошо, поставим модель вдвое дороже - еще лучше. При этом замечу что некоторые заводы имеют квоту на каждую страну - если условный Казахстан вдруг начнет вместо 10 железяк в год заказывать 100 - поставки довольно быстро встанут. Если выйти из нашего сектора в чистый IT - предполагаю что все не так просто с библиотеками, лезвиями, сетью уровня ядра.
Да вроде об одном. Вы написали что резерва 3-5% хватит чтобы комфортно жить в условиях параллельного импорта, я написал что в нашем конкретном случае - не хватает.
Не поленился и посчитал - у нашей конторы текущий резерв составляет 1.7% по конкретной позиции (сервера), комфортный резерв по этой же позиции с учетом текущих сроков поставки составляет 8.5%. Проблема даже не в том что надо увеличить размеры склада ЗИП в 4-5 раз, проблема в том за счет чего закупить этот объем оборудования. Даже если "забыть" про всех старых клиентов и рассматривать только сейчас заключаемых - на первых контрактах стоимость ЗИПа составит 15-25%. Прибавьте к этому стоимость двойной таможни и двойной доставки.
Конечно если вы последние 5 лет занимаетесь поставкой одной модели сервера с одной памятью с одной моделью HDD - вам достаточно иметь один сервер, 2 плашки памяти и 10 дисков. Но наша математика так не работает. Быть может в комментах кто-то еще посчитает свою статистику.
И кстати непосредственно клиенты вполне себе покупают. Мы стараемся уложиться в 10% избыточности если она требуется, но есть объекты с запасом 20%, 100%, 300% (одно устройство работает, 3 в резерве на самом объекте).
Бывает что одна редкая железяка идет клиенту, такую же нам надо иметь в ЗИП - и вот 3-5% превращается опять в 100%.
Как показывает наша личная практика (мы не совсем про сервера но близко) - нельзя. Склады в мск и регионах быстро исчерпались в итоге худший простой с февраля по сентябрь.
У нас есть рекомендованный производителем список чего и сколько должно лежать на центральном и региональном складе, он не выполнялся даже в допандемийные времена потому что это замороженные деньги. На складе балластом лежит зип под оборудование снятое с производства, но ходовые позиции могут в любой момент кончится, раньше это можно было решить срочной поставкой, сейчас по ряду позиций мы до сих пор поставок обеспечить не можем и сидим на остатках склада.
Отдельная боль - позиции собираемые заводом на заказ под клиента.
И получить overhead на обман компилятора и работать это будет пока компилятор не поумнеет и не поймет что вы возвращаете результат в никуда.
не делать всех оптимизаций? тогда мы получаем benchmark совсем другого неоптимизированного кода. КМК это повод для warning но никак не для слепой оптимизации.
Дак в статье и написано что нужно "обманывать" компилятор чтобы программа работала как положено. Стирание памяти это не только пароли, но и часть защиты от отладки\взлома например. Что касается записи на диск - видимым будет результат последней записи, значит предыдущие 10 проходов можно оптимизировать, а если следом DeleteFileA дергается то и последний проход не нужен.
Я понимаю когда undefined behavior, тут я не совсем согласен с логикой, но да, мы имеем то что имеем.
Вас послушать дак любой benchmark (алгоритма или железа) или wipe data является мёртвым кодом.
А supermicro вкурсе что многосокетные платы не взлетели?
Ваша сборка хороша и имеет право, но кмк стоит учитывать ряд моментов.
Возможно я не силен в гугле, но таких низких ценников найти не могу. Ну и давайте не забывать что оно будет очень сильно БУ и с ограниченной гарантией, проработает возможно еще 30 лет а может нет и тогда вопрос доступности запчастей.
Основное преимущество - цена. Для хранилки/шлюза не принципиально, для виртуализации или видео - проц 2007 года я бы не взял.
Главный вопрос шум - не у всех есть возможность изолировать полноразмерную стойку в
сервернойкладовке/гараже а у некоторых еще и очень чуткий сон.Я наверное что-то делаю не так, но диски дома меняю без выключения и в корпусе без hot-swap, энергопотребление смотрю на UPS да и host систему на домашнем серваке ставил 1 раз; на работе iLo/IPMI не пользовался с момента установки системы. Иметь корзину/iLo/ECC/dual psu хорошо, но гнаться за этим дома?...