Я не говорил хорошо или плохо, я писал про эффективность использования аппаратно програмной платформы.
Вот 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, да и не будет никто вменяемый этим заниматься. То есть он просто станет нишевым
Потому что именно свертка с дельта-функцией дает мгновенное значение сигнала, а перемножение даст импульс бесконечной амплитуды.
А соседнее значение результата дискретизации откуда возьмётся при свёртке?
И насчёт Котельникова - его теорема была про восстановление сигнала, а не про его дискретизацию. Поэтому Найквист подходит для дискретизации узкополосных сигналов, а Котельников не очень, требует переформулирования.
Тогда я ещё больше удивлён статьёй. И термины вроде корректные по отдельности, а вместе больше напоминает какое то ими жонглирование.
Ну к примеру - дискретизация это свёртка сигнала с весовой фунцией, в идеале дельта функцией. Почему свёртка, а не перемножение на периодическую дельта функцию? И зачем тут вообще понятие весовая функция и свёртка? Для научности?
Что такое ширина пространственного спектра сигнала, например? Я такой термин встречал только в приложениях пространственно-временной обработки, самое простое из которых это ширина диаграммы направленности фар. Вот там, кстати, да - пространственный спектр это свёртка спектра выборок пространства (элемента антенны) и самой решетки.
В инженерных приложениях влияние апертуры увх я встречал только у коллег, которые разрабатывали стробоскоб для 1 нс диапазона, и то для них более сложным было борьба с джиттером, а не с апертурой ключей. В остальных случаях, а это диапазоны 70 и 140 МГц, никаких проблем с влиянием апертуры не было кроме, опять таки, джиттера, а было это аж 25 лет назад при использовании коммерчески доступных ацп.
Зачем под функциями корреляции маскировать стандартные параметры ацп типа полосы? Понятно что они связаны, но полоса входного сигнала это число, а вот его автокорреляционную функцию ещё оценить надо суметь.
Ни разу не слышал про интегрирующую дискретизацию, да ещё в контексте повышения частоты преобразования.
Ну а про повышение частоты дискретизации выше Найквиста и существование оптимума из за шума - ну ведь явное жонглирование разными фактами. В любой мурзилке по применению АЦП всё это давно расписано - поставьте фнч (или фпч), рассчитайте спады ачх и насколько эти шумы и внеполосные сигналы будут влиять на с/ш в полосе сигнала, выберете частоту дискретизации с этим запасом чтобы сохранить динам диапазон, можете выбрать её выше, но тогда поставьте цифровой фильтр, чтобы подавить внеполосовые внешние шумы и шум квантования для расширения динам диапазона, - всё, ничего нового там уже давно нет.
Статья претендует на открытие какой то сакральной истины, но в чём она заключена непонятно, имхо
Динамическая погрешность дискретизации в этом случае может быть оценена отношением апертурного времени к времени корреляции. Действительно, при φ(t) = δ(t) апертурное время и апертурный сдвиг устройства дискретизации равны нулю и динамическая погрешность отсутствует при любой скорости изменения входного сигнала. Для реальных весовых функций, когда τφ ≠ 0, динамическая погрешность отсутствует только при дискретизации постоянных сигналов.
Мне кажется автор никогда не работал с АЦП. Апертурное время никаких динамических искажений не привносит ни для постоянного, ни для переменного входного сигнала. "Задержка" отсчёта не является искажением. Источником динамических искажений являются внутренние и внешние факторы, влияющие на апертурную дрожь - джиттер, приводящие к изменению момента фиксации выборки. Это и вызывает ошибку дискретизации, растущую с частотой входного сигнала
Единственная проблема тп, которую я выявил за 6 лет эксплуатации двухэтажного дома с дровяным (брикетным) отоплением - это долгий прогрев. Точность поддержания температуры не больше 0,2 градуса, если не полон дом гостей - с ними теплее)
Вот вчера вечером было -10, сегодня утром -26 и вода в теплоаккумуляторе к 8 остыла, в 11 утра температура стала ниже нормы на 0,2 градуса. Так что нормально всё с тп при достаточном для них утеплении.
Да в том то и проблема, что потоки выполнения это не абстракция задач, а их имплементация. И, в свою очередь, имплементация разновидности процесса в большинстве ос. А для планировщика один из типов сущностей, которыми он управляет.
Я не говорил хорошо или плохо, я писал про эффективность использования аппаратно програмной платформы.
Вот 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 в контексте Телеграм звучат бредово
Тогда на выходе каждый отсчёт будет сумма значений сигнала с весами этой дискретизирующей функции.
А соседнее значение результата дискретизации откуда возьмётся при свёртке?
И насчёт Котельникова - его теорема была про восстановление сигнала, а не про его дискретизацию. Поэтому Найквист подходит для дискретизации узкополосных сигналов, а Котельников не очень, требует переформулирования.
Тогда я ещё больше удивлён статьёй. И термины вроде корректные по отдельности, а вместе больше напоминает какое то ими жонглирование.
Ну к примеру - дискретизация это свёртка сигнала с весовой фунцией, в идеале дельта функцией. Почему свёртка, а не перемножение на периодическую дельта функцию? И зачем тут вообще понятие весовая функция и свёртка? Для научности?
Что такое ширина пространственного спектра сигнала, например? Я такой термин встречал только в приложениях пространственно-временной обработки, самое простое из которых это ширина диаграммы направленности фар. Вот там, кстати, да - пространственный спектр это свёртка спектра выборок пространства (элемента антенны) и самой решетки.
В инженерных приложениях влияние апертуры увх я встречал только у коллег, которые разрабатывали стробоскоб для 1 нс диапазона, и то для них более сложным было борьба с джиттером, а не с апертурой ключей. В остальных случаях, а это диапазоны 70 и 140 МГц, никаких проблем с влиянием апертуры не было кроме, опять таки, джиттера, а было это аж 25 лет назад при использовании коммерчески доступных ацп.
Зачем под функциями корреляции маскировать стандартные параметры ацп типа полосы? Понятно что они связаны, но полоса входного сигнала это число, а вот его автокорреляционную функцию ещё оценить надо суметь.
Ни разу не слышал про интегрирующую дискретизацию, да ещё в контексте повышения частоты преобразования.
Ну а про повышение частоты дискретизации выше Найквиста и существование оптимума из за шума - ну ведь явное жонглирование разными фактами. В любой мурзилке по применению АЦП всё это давно расписано - поставьте фнч (или фпч), рассчитайте спады ачх и насколько эти шумы и внеполосные сигналы будут влиять на с/ш в полосе сигнала, выберете частоту дискретизации с этим запасом чтобы сохранить динам диапазон, можете выбрать её выше, но тогда поставьте цифровой фильтр, чтобы подавить внеполосовые внешние шумы и шум квантования для расширения динам диапазона, - всё, ничего нового там уже давно нет.
Статья претендует на открытие какой то сакральной истины, но в чём она заключена непонятно, имхо
Мне кажется автор никогда не работал с АЦП. Апертурное время никаких динамических искажений не привносит ни для постоянного, ни для переменного входного сигнала. "Задержка" отсчёта не является искажением. Источником динамических искажений являются внутренние и внешние факторы, влияющие на апертурную дрожь - джиттер, приводящие к изменению момента фиксации выборки. Это и вызывает ошибку дискретизации, растущую с частотой входного сигнала
Единственная проблема тп, которую я выявил за 6 лет эксплуатации двухэтажного дома с дровяным (брикетным) отоплением - это долгий прогрев. Точность поддержания температуры не больше 0,2 градуса, если не полон дом гостей - с ними теплее)
Вот вчера вечером было -10, сегодня утром -26 и вода в теплоаккумуляторе к 8 остыла, в 11 утра температура стала ниже нормы на 0,2 градуса. Так что нормально всё с тп при достаточном для них утеплении.
Ну, то есть нет, да?)
А что с графиками точность вс сложность для аналога и цифры? Опровергли уже?)
Да в том то и проблема, что потоки выполнения это не абстракция задач, а их имплементация. И, в свою очередь, имплементация разновидности процесса в большинстве ос. А для планировщика один из типов сущностей, которыми он управляет.
Вроде серьезная статья, а такие вольности)
Ну а вот я первый раз узнал из статьи, что вытесняющая, как и кооперативная многозадачности как понятия вообще связаны с нитями)