Вы, мне кажется, не поняли смысла поста на который отвечаете - при сохранении такого вектора развития нашего интернета эти бпла лет через 10-15 будет нечем сбивать, не дай бог конечно
Отлично сформулировано. Тоже хотел с подобными рассуждениями высказаться, пару раз начинал, но со второго предложения скатывался на "идиоты" и "кретинизм"
А проигрыш классических алгоритмов был из за изменения весов инструкций в алгоритме, на коротких бпф оказывалось, что стоимость настройки адресов в каждом цикле перевешивала выигрыш от экономии операций умножения. В частности оказывалось, что переход с радикса 2 на 4 мог давать большую скорость вычислений при опрпделенрых длинах преобразования.
В принципе Ваш пример тоже про это - если попытаться переписать бпф для многоядерного интела, от классического варианта тоже вряд ли что останется
Я не говорил хорошо или плохо, я писал про эффективность использования аппаратно програмной платформы.
Вот gimp возьмите - там на виндовсе уже поддерживается многоядерность? Я тут фотки старые отсканированные разрезал, так и не смог в винде ничего с ними сделать, зато под линуксом почти без тормозов. Так это только ос разные, не аппаратура.
Конечно разработчики сапров больше задумываются о производительности, пока в клауд не уходят... Но тем не менее, они много оптимизированных под неск поколений процессоров вариантов библиотек поставляют? Ну к примеру под размеры кешей или количество ядер? Насколько они заморачиваются на автоконфигурировании своих пакетов под конфигурацию железа и насколько эффективно у них это получается? Тоже проще требования к железу поднять
Есть давняя проблема в том, что программисты разрабатывают и пишут алгоритмы, сложность которых растёт быстрее, чем эффективность использования существующего железа. Я забыл цифры, но условно возможности 286 процессора использовались процентов на 60 при появлении 386, в котором стало использоваться только 30 процентов. Не успели достичь 60 процентов на 386, как появился 486. Не думаю, что сейчас ситуация другая.
Или другой пример - в 70-80 существовали мат библиотеки ещё на фортране, оптимизированные для машин, где, условно, умножение было медленнее сложения в 10-20 раз. Когда появились сигнальные процессоры, у которых операция умножения со сложением и инкрементами адресов выполнялись за один цикл, эффективность этих алгоритмов существенно изменилась и, к примеру, бпф на 64 работало с такой же скоростью, как и дпф в лоб, а на 32 и меньше даже медленее.
То что происходит, плата за сложность и переносимость. Возьмите какую нить сапр с жизненным циклом лет 20 - под каждый новый чип и платформу выпускать аппаратно зависимый рантайм? То есть на старой платформе он работает с ммх и sse2, на текущей уже авх или как там его, а через 2 года появится порт на супер5дматрикс экстеншен в облаке, и все эти 10 портов надо фиксить, расширять, тестировать ещё 15 лет? Потому что то что эффективно сейчас при портировании может перестать таковым быть.
В общим да, купить ещё один сервак это ответ современной индустрии. Ну или жёсткий лимит ресурсов
Конференция в техническом плане это ресурс, который складывает стримы участников, давит шумы, переключает громкость и требует внимания к загрузке системы - условно если на коле 100 участников, и все слушают одного, то всё легко, а если это 5-8 человек которые ведут диалог, то это может оказаться жопой для системы. Поэттму да, конференции вредны)
16 лет писал на java 5,6,8 на энтерпрайз - ни разу не написал main, никогда не использовал date, spring boot, слово maven видел только в 3d party. Stream использовал однократно, через год, увидев своё авторство класса долго вспоминал, как меня туда занесло и зачем. Не работал с файлами - только через аудио, сокетами - только через jni с проприентарными протоколами, с бд - только через ejb. И самое чудовищное, наверно - не использовал строк, кроме логов, и о боже - json только видел) Критические секции были как правило в 3 сущностях с двумя пересекающимися синхронизациями, если коллеги не решали что нибудь ещё засинхронизировать.
В общем java я так и не изучил, видимо, зато был в числе нескольких человек, кто представлял как эта вся хрень работает)
И да, нас тоже пытались сделать единичками универсальных ресурсов, но что то у них не получилось
Телеграм это популярный мессенджер. Без приседаний и шаманства не получится перестроить телефон на работу с mesh, да и не будет никто вменяемый этим заниматься. То есть он просто станет нишевым
Потому что именно свертка с дельта-функцией дает мгновенное значение сигнала, а перемножение даст импульс бесконечной амплитуды.
А соседнее значение результата дискретизации откуда возьмётся при свёртке?
И насчёт Котельникова - его теорема была про восстановление сигнала, а не про его дискретизацию. Поэтому Найквист подходит для дискретизации узкополосных сигналов, а Котельников не очень, требует переформулирования.
Вы, мне кажется, не поняли смысла поста на который отвечаете - при сохранении такого вектора развития нашего интернета эти бпла лет через 10-15 будет нечем сбивать, не дай бог конечно
Отлично сформулировано. Тоже хотел с подобными рассуждениями высказаться, пару раз начинал, но со второго предложения скатывался на "идиоты" и "кретинизм"
А не проще минимизировать применение fpga в космических применениях?)
Не, intel в 90 не мог в dsp)
А проигрыш классических алгоритмов был из за изменения весов инструкций в алгоритме, на коротких бпф оказывалось, что стоимость настройки адресов в каждом цикле перевешивала выигрыш от экономии операций умножения. В частности оказывалось, что переход с радикса 2 на 4 мог давать большую скорость вычислений при опрпделенрых длинах преобразования.
В принципе Ваш пример тоже про это - если попытаться переписать бпф для многоядерного интела, от классического варианта тоже вряд ли что останется
Ну да, всё верно, именно эту книжку я наверное и читал тогда)
Я думаю что скоро угандошат весь интернет и наступит тишина. И лет через несколько кто то, возможно, одумается. Или нет
Его и сейчас сделать проблема для людей с невысокими доходами и/или живущими не в крупных городах.
Я не говорил хорошо или плохо, я писал про эффективность использования аппаратно програмной платформы.
Вот gimp возьмите - там на виндовсе уже поддерживается многоядерность? Я тут фотки старые отсканированные разрезал, так и не смог в винде ничего с ними сделать, зато под линуксом почти без тормозов. Так это только ос разные, не аппаратура.
Конечно разработчики сапров больше задумываются о производительности, пока в клауд не уходят... Но тем не менее, они много оптимизированных под неск поколений процессоров вариантов библиотек поставляют? Ну к примеру под размеры кешей или количество ядер? Насколько они заморачиваются на автоконфигурировании своих пакетов под конфигурацию железа и насколько эффективно у них это получается? Тоже проще требования к железу поднять
Есть давняя проблема в том, что программисты разрабатывают и пишут алгоритмы, сложность которых растёт быстрее, чем эффективность использования существующего железа. Я забыл цифры, но условно возможности 286 процессора использовались процентов на 60 при появлении 386, в котором стало использоваться только 30 процентов. Не успели достичь 60 процентов на 386, как появился 486. Не думаю, что сейчас ситуация другая.
Или другой пример - в 70-80 существовали мат библиотеки ещё на фортране, оптимизированные для машин, где, условно, умножение было медленнее сложения в 10-20 раз. Когда появились сигнальные процессоры, у которых операция умножения со сложением и инкрементами адресов выполнялись за один цикл, эффективность этих алгоритмов существенно изменилась и, к примеру, бпф на 64 работало с такой же скоростью, как и дпф в лоб, а на 32 и меньше даже медленее.
То что происходит, плата за сложность и переносимость. Возьмите какую нить сапр с жизненным циклом лет 20 - под каждый новый чип и платформу выпускать аппаратно зависимый рантайм? То есть на старой платформе он работает с ммх и sse2, на текущей уже авх или как там его, а через 2 года появится порт на супер5дматрикс экстеншен в облаке, и все эти 10 портов надо фиксить, расширять, тестировать ещё 15 лет? Потому что то что эффективно сейчас при портировании может перестать таковым быть.
В общим да, купить ещё один сервак это ответ современной индустрии. Ну или жёсткий лимит ресурсов
У них просто бюджет на следующую трёхлетку спадает, вот и..
Парикхмахеры почти в зеленой зоне. Что то анекдот вспомнил
Изобрели брадобрейный автомат
но как, у людей же лица у всех разные, у вспх есть особенности..
да, но только первый раз!
ТАк что табличка корректна только для существующих подходов, которые можно и поменять
Конференция в техническом плане это ресурс, который складывает стримы участников, давит шумы, переключает громкость и требует внимания к загрузке системы - условно если на коле 100 участников, и все слушают одного, то всё легко, а если это 5-8 человек которые ведут диалог, то это может оказаться жопой для системы. Поэттму да, конференции вредны)
Ну как бы да, на собеседованиях фреймворки аргумент. Но с фреймвоками без грёбаного энтерпрайза тоже придёшь джуниором - парадокс)
16 лет писал на java 5,6,8 на энтерпрайз - ни разу не написал main, никогда не использовал date, spring boot, слово maven видел только в 3d party. Stream использовал однократно, через год, увидев своё авторство класса долго вспоминал, как меня туда занесло и зачем. Не работал с файлами - только через аудио, сокетами - только через jni с проприентарными протоколами, с бд - только через ejb. И самое чудовищное, наверно - не использовал строк, кроме логов, и о боже - json только видел) Критические секции были как правило в 3 сущностях с двумя пересекающимися синхронизациями, если коллеги не решали что нибудь ещё засинхронизировать.
В общем java я так и не изучил, видимо, зато был в числе нескольких человек, кто представлял как эта вся хрень работает)
И да, нас тоже пытались сделать единичками универсальных ресурсов, но что то у них не получилось
TPAlgorithmService - интересно, как и на чём у вас он сделан
Вот тема - огонь))
Телеграм это популярный мессенджер. Без приседаний и шаманства не получится перестроить телефон на работу с mesh, да и не будет никто вменяемый этим заниматься. То есть он просто станет нишевым
Тоже про это подумал, потому что рассуждения про mesh в контексте Телеграм звучат бредово
Тогда на выходе каждый отсчёт будет сумма значений сигнала с весами этой дискретизирующей функции.
А соседнее значение результата дискретизации откуда возьмётся при свёртке?
И насчёт Котельникова - его теорема была про восстановление сигнала, а не про его дискретизацию. Поэтому Найквист подходит для дискретизации узкополосных сигналов, а Котельников не очень, требует переформулирования.