Для пол-терабайта в первую неделю, мне кажется, можно и потребовать дополнительные деньги. Это уже чисто коммерческий вопрос — сколько взять, чтобы отсечь халявщиков системы «выкачал и отключился», но не ограничить перспективных.
Та же Воля даёт «гиперскорость» без ограничения вообще и без учёта в обычный трафик на 1 сутки за ~0.2 USD.
Пример:
День 1: только подключились, запаса 0. В полночь добавили 33GB, потратили за сутки 2, остаток 31.
День 2: В полночь добавили 33GB, потратили за сутки 10, остаток 54.
День 3: В полночь добавили 33GB, потратили за сутки 60, остаток 27.
…
День N+1: Было остатка 900GB, в полночь добавили 33GB, потратили за сутки 933GB, остаток 0.
… и так далее…
Но, если остаток на момент добавления превышает 1000GB — он урезается вниз до 1000GB. То есть неограниченное накопление невозможно, выше месячного лимита не растёт.
Ну а если потрачено до нуля — там уже меры как в исходной статье — ограничили до 64Kbit/s или похожего.
Подобная ситуация была несколько лет назад с «Воля-кабель» — ввели ограничения на месячный трафик под предлогом «гарантии честного использования». В основном прошло тихо, но часть клиентов ушла — например, мой шеф сурово на них обиделся и перешёл к конкуренту.
В предложенном (представим себе, что эти ограничения таки осмысленны и будут введены) самое неверное это дробление по месяцу. По-нормальному должна быть система token bucket с пределом пусть тот же 1TB и начислением порции не реже раза в сутки. 33GB в сутки, 1.375GB в час — насколько часто смогут, настолько пусть и будет. В таком случае превышение затормозит использование на короткое время, беспроблемное для большинства; и это не помешает «рывком» взять те же 1TB, если надо, и есть неиспользованное.
Один огромный недостаток — объяснять эту схему не-ITшнику сложно ;( так что вводить её только по желанию клиента. (Ой, сочувствую тому биллингу.)
Control & status передаются в FPU и обратно без всякого стека. Значит, могли, если хотели.
Тут всё-таки идеологические соображения. Но непонятно, какие именно.
Да, но при жёсткой дисциплине на их использование. Например, сложение-вычитание с разным m недопустимо; при умножении и делении надо уточнять m результата; присвоение с другим m тоже недопустимо без явной конверсии с указанием правила округления… В сумме таких правил накапливается столько, что часто легче явно вести в целых, а масштаб (то самое m) подразумевать контекстом.
> А теперь, внимание, вопрос: как вы собрались «менять модель на более устойчивую», если оригинальное явление обладает неустойчивостью? Которую мы, собственно, и исследуем?
Для неустойчивых явлений должна быть устойчивая модель анализа собственно неустойчивости. Методы для этого в общем известны, хотя там много уникальной теоретической работы в каждом случае.
> Понятно, что когда у вас явление неустойчиво малые модификации кода могут приводить к тому, что результаты будут меняться — тут ничего страшного нет, ещё раз повторюсь, мы исследуем явление, которое само по себе неустойчиво. Но когда результаты меняются без модификации кода — это просто неприятно и неудобно…
Может, не кода, а исходных данных? Хотя в задаче о свёртке белка входные данные самого белка дискретны, малые модификации не получатся — их надо вводить по ходу процесса свёртки.
Но когда результаты радикально меняются от сверхмалых изменений входных параметров или промежуточных значений — это признак того, что надо менять модель, и тут проблемы процессоров как раз пошли на пользу — явление опознано.
Вообще, тут надо подобные микроошибки как раз вводить в расчётные программы, для детекта неустойчивости.
Если на разных FPU белок сворачивается в разные стороны, значит, вычисления очень чувствительны к погрешностям такого порядка (~1ulp), а это уже признак, что им надо или повышать точность значений (double недостаточно), или менять модель на более устойчивую. При устойчивой модели такие различия могут сбить младшие разряды (нарушение духа IEEE754 — результаты должны быть воспроизводимы на любом железе), но не привести к принципиально различным результатам.
> Завтра Вы купите новый процессор, и в нём FPU будет реализован по-другому.
С этим безусловно согласен. Но термин «непредсказуемый» мне тут откровенно не нравится, потому что слишком сильно намекает на варианты типа «сразу повторили ту же операцию, а результат другой».
Считаю тогда, что разногласий тут нет.
Не только. Большинство изученных нервных датчиков, IIRC, передают сигнал как логарифм входного воздействия (при этом собственно уровень такого сигнала после логарифмирования передаётся как частота импульсов).
> И да, я нигде не говорил о том, что x87 в разы медленнее
OK, у Вас было «весьма медленнее». Это эмоциональная оценка, но по-моему таки «весьма» это «не менее чем в разы» (иначе это несущественно по сравнению с прочими обстоятельствами).
> Я говорил, что он просто медленнее, вы и сами это признали.
Более точно — что уже начался период, что он хоть и немного, но медленнее.
Далее khim@ настаивает, что это будет нарастать, а я неизбежно соглашаюсь ;(
Сам себе поправлю (сбили с толку этим «необходима точность 0.5 ulp или лучше») — не «необходима точность», а «получается точность». Необходимая по IEEE754 — идеальная точность, но с округлением.
Непредсказуемым от этого результат в стиле FPU не становится, но нестандартным — вполне может.
Мнэээ… это, мягко говоря, не то, что Вы описывали раньше. Вы говорили про «непредсказуемое» значение младшего бита. В данной же документации, кроме этих слов, сказано ещё одно:
> The functions are guaranteed to be monotonic, with respect to the input operands, through the domain supported by the instruction.
Всё вместе наводит на несколько иное понимание — результат конкретной функции для конкретного аргумента всегда один и тот же, но все эти результаты вместе — могут показывать систематическое смещение относительно идеального значения.
Кроме того, это всё явно описано для максимальной точности (64 бита мантиссы). Уже для double (53 бита) эти ошибки становятся несущественными, потому что менее 1/2048 от ulp.
Для совсем глубокой раскопки можно было бы поискать, как именно эти систематические ошибки отличаются для разных моделей FPU. Но важно ли это, с учётом предыдущего абзаца?
Вот просто потрясающий пример, как можно из одних и тех же данных делать противоположные выводы. ;)
Денормализованные — это не ужас, и не повод тратить тысячи тактов на ерунду. Алгоритмы для этого отработаны уже годами, максимум потерь в аппаратной реализации — два такта на результат. И если у SSE, сделанного через 20 лет после FPU, есть проблема с денормализованными — это значит, что внутри там взята всё та же тупая реализация времён судорожного клепания K-C-S.
А то, что Вы видите флаг справляться с ними в случае SSE, и не видите в случае FPU — это уже фирменный стиль Intel, который просто отказался помочь пользователям FPU, с мотивацией типа «нефиг, пусть быстрее сбегают на SSE».
Стек — да, безусловно (какой безумец его ввёл в x87?)
Latency — да, там в таблицах видно, что обычно на такт-два больше.
Ещё они могли тут иметь в виду проблемы с денормализованными. SSE тормозит на заметно меньшем количестве случаев с денормализованными, чем FPU; вообще же это дикий позор, что за 30+ лет с KCS реализации это не исправили.
Но в среднем это всё-таки даже не разы.
> То есть, если x87 и AVX FP обрабатываются портом 0, это не значит, что за это отвечает одна и та же логика.
В общем случае — да. Но с учётом обычной прямой логики (насколько она применима к Intel) и сложности такого блока — это уже ближе к конспирологии.
Не буду дальше вглубляться — у нас ни у кого точных данных нет — закроем на этом.
> И если посмотреть на что-нибудь свежее, типа Skylake (схема 2-1 приведённого Вами документа), то там вообще не говорится про x87 и MMX.
Skylake у меня есть, мерил — в соседнем комментарии. Максимум найденной разницы — около 1.4 раза. Могли усложнить их выборку — факт. Но это ещё даже не разы. Посмотрим на следующие версии…
По сравнению с чем?
Если с супермелкими изделиями вроде Atom — ok, может быть (приму пока сам не померю).
Если с более новыми поколениями — «меня терзают смутные сомнения» (tm)
Вот есть лаптоп с «Intel® Pentium® CPU 4405U @ 2.10GHz» (Skylake, но урезанный до мобильной версии, SSE весь есть, AVX отсутсвует).
Решение СЛАУ по Гауссу, прямолинейное; матрица 1000*1000 случайных чисел; Ubuntu 16.04; gcc5; -O3.
32 бита, FPU, double: 3.6 сек.
32 бита, FPU, long double: 5.5 сек (явно, затраты на cache misses)
32 бита, SSE, double: 3.2 сек. (код показывает частичную векторизацию)
64 бита, SSE, double: 2.3 сек.
64 бита, FPU, long double: 4.6 сек.
Как-то всё равно не укладывается в Вашу концепцию «FPU стал в разы медленнее», максимум подтверждаемого именно для отношения SSE/FPU это где-то 1.4 раза, при тщательном исследовании наверняка будет ещё меньше.
И я уверен, что для всех уровней процессоров от хорошего лаптопа и выше это сохранится ещё долго.
> Инструкции из набора x87 это legacy, в процессорах эти инструкции работают весьма медленно.
На десктопных и серверных процессорах это пока что не так. (Коллега khim@ говорил про проблемы на Atom и Bobcat, надо уточнять.) Я рядом показывал результаты от его теста после устранения проблем передачи параметров, разницы вообще не было.
Для сравнения стащил очень прямолинейный расчёт СЛАУ по Гауссу, матрица 1000*1000, случайные коэффициенты; i3-4170 (Haswell).
FPU+double: 4.6сек; FPU+long double: 5.5 сек — соответствует оценке влияния кэширования; SSE: 3.6 сек — с тем, что в выхлопе clang есть лёгкая векторизация.
Это ближе к тому, что времена собственно вычисления не отличаются.
> В документации описаны ситуации, когда младший бит мантиссы результата принимает непредсказуемое значение. К сожалению, прямо сейчас я не смогу предоставить ссылку на конкретный раздел документации, но если интересно, завтра могу уточнить.
Прошу таки уточнить, и заодно к каким версиям это относится. Где-то до 387-го у них было ещё много странностей, но потом вроде всё вычистили?
P.S. Есть один момент, в котором я полностью согласен, что x87 это legacy: это его неуместный стек регистров. Кому и зачем это стукнуло в голову — ХЗ, но это не единственная, мягко говоря, странность Intel. Но сейчас и его помеху снизили до минимума.
Та же Воля даёт «гиперскорость» без ограничения вообще и без учёта в обычный трафик на 1 сутки за ~0.2 USD.
День 1: только подключились, запаса 0. В полночь добавили 33GB, потратили за сутки 2, остаток 31.
День 2: В полночь добавили 33GB, потратили за сутки 10, остаток 54.
День 3: В полночь добавили 33GB, потратили за сутки 60, остаток 27.
…
День N+1: Было остатка 900GB, в полночь добавили 33GB, потратили за сутки 933GB, остаток 0.
… и так далее…
Но, если остаток на момент добавления превышает 1000GB — он урезается вниз до 1000GB. То есть неограниченное накопление невозможно, выше месячного лимита не растёт.
Ну а если потрачено до нуля — там уже меры как в исходной статье — ограничили до 64Kbit/s или похожего.
Так вариант, что я описываю, позволяет разово взять аж до месячного лимита.
В предложенном (представим себе, что эти ограничения таки осмысленны и будут введены) самое неверное это дробление по месяцу. По-нормальному должна быть система token bucket с пределом пусть тот же 1TB и начислением порции не реже раза в сутки. 33GB в сутки, 1.375GB в час — насколько часто смогут, настолько пусть и будет. В таком случае превышение затормозит использование на короткое время, беспроблемное для большинства; и это не помешает «рывком» взять те же 1TB, если надо, и есть неиспользованное.
Один огромный недостаток — объяснять эту схему не-ITшнику сложно ;( так что вводить её только по желанию клиента. (Ой, сочувствую тому биллингу.)
Тут всё-таки идеологические соображения. Но непонятно, какие именно.
Я читал — одна лицензия на G.729 на оба порта устройства, соответственно, не более одного разговора одновременно.
Для неустойчивых явлений должна быть устойчивая модель анализа собственно неустойчивости. Методы для этого в общем известны, хотя там много уникальной теоретической работы в каждом случае.
> Понятно, что когда у вас явление неустойчиво малые модификации кода могут приводить к тому, что результаты будут меняться — тут ничего страшного нет, ещё раз повторюсь, мы исследуем явление, которое само по себе неустойчиво. Но когда результаты меняются без модификации кода — это просто неприятно и неудобно…
Может, не кода, а исходных данных? Хотя в задаче о свёртке белка входные данные самого белка дискретны, малые модификации не получатся — их надо вводить по ходу процесса свёртки.
Но когда результаты радикально меняются от сверхмалых изменений входных параметров или промежуточных значений — это признак того, что надо менять модель, и тут проблемы процессоров как раз пошли на пользу — явление опознано.
Вообще, тут надо подобные микроошибки как раз вводить в расчётные программы, для детекта неустойчивости.
С этим безусловно согласен. Но термин «непредсказуемый» мне тут откровенно не нравится, потому что слишком сильно намекает на варианты типа «сразу повторили ту же операцию, а результат другой».
Считаю тогда, что разногласий тут нет.
OK, у Вас было «весьма медленнее». Это эмоциональная оценка, но по-моему таки «весьма» это «не менее чем в разы» (иначе это несущественно по сравнению с прочими обстоятельствами).
> Я говорил, что он просто медленнее, вы и сами это признали.
Более точно — что уже начался период, что он хоть и немного, но медленнее.
Далее khim@ настаивает, что это будет нарастать, а я неизбежно соглашаюсь ;(
Непредсказуемым от этого результат в стиле FPU не становится, но нестандартным — вполне может.
> The functions are guaranteed to be monotonic, with respect to the input operands, through the domain supported by the instruction.
Всё вместе наводит на несколько иное понимание — результат конкретной функции для конкретного аргумента всегда один и тот же, но все эти результаты вместе — могут показывать систематическое смещение относительно идеального значения.
Кроме того, это всё явно описано для максимальной точности (64 бита мантиссы). Уже для double (53 бита) эти ошибки становятся несущественными, потому что менее 1/2048 от ulp.
Для совсем глубокой раскопки можно было бы поискать, как именно эти систематические ошибки отличаются для разных моделей FPU. Но важно ли это, с учётом предыдущего абзаца?
Денормализованные — это не ужас, и не повод тратить тысячи тактов на ерунду. Алгоритмы для этого отработаны уже годами, максимум потерь в аппаратной реализации — два такта на результат. И если у SSE, сделанного через 20 лет после FPU, есть проблема с денормализованными — это значит, что внутри там взята всё та же тупая реализация времён судорожного клепания K-C-S.
А то, что Вы видите флаг справляться с ними в случае SSE, и не видите в случае FPU — это уже фирменный стиль Intel, который просто отказался помочь пользователям FPU, с мотивацией типа «нефиг, пусть быстрее сбегают на SSE».
Latency — да, там в таблицах видно, что обычно на такт-два больше.
Ещё они могли тут иметь в виду проблемы с денормализованными. SSE тормозит на заметно меньшем количестве случаев с денормализованными, чем FPU; вообще же это дикий позор, что за 30+ лет с KCS реализации это не исправили.
Но в среднем это всё-таки даже не разы.
В общем случае — да. Но с учётом обычной прямой логики (насколько она применима к Intel) и сложности такого блока — это уже ближе к конспирологии.
Не буду дальше вглубляться — у нас ни у кого точных данных нет — закроем на этом.
> И если посмотреть на что-нибудь свежее, типа Skylake (схема 2-1 приведённого Вами документа), то там вообще не говорится про x87 и MMX.
Skylake у меня есть, мерил — в соседнем комментарии. Максимум найденной разницы — около 1.4 раза. Могли усложнить их выборку — факт. Но это ещё даже не разы. Посмотрим на следующие версии…
По сравнению с чем?
Если с супермелкими изделиями вроде Atom — ok, может быть (приму пока сам не померю).
Если с более новыми поколениями — «меня терзают смутные сомнения» (tm)
Вот есть лаптоп с «Intel® Pentium® CPU 4405U @ 2.10GHz» (Skylake, но урезанный до мобильной версии, SSE весь есть, AVX отсутсвует).
Решение СЛАУ по Гауссу, прямолинейное; матрица 1000*1000 случайных чисел; Ubuntu 16.04; gcc5; -O3.
32 бита, FPU, double: 3.6 сек.
32 бита, FPU, long double: 5.5 сек (явно, затраты на cache misses)
32 бита, SSE, double: 3.2 сек. (код показывает частичную векторизацию)
64 бита, SSE, double: 2.3 сек.
64 бита, FPU, long double: 4.6 сек.
Как-то всё равно не укладывается в Вашу концепцию «FPU стал в разы медленнее», максимум подтверждаемого именно для отношения SSE/FPU это где-то 1.4 раза, при тщательном исследовании наверняка будет ещё меньше.
И я уверен, что для всех уровней процессоров от хорошего лаптопа и выше это сохранится ещё долго.
На десктопных и серверных процессорах это пока что не так. (Коллега khim@ говорил про проблемы на Atom и Bobcat, надо уточнять.) Я рядом показывал результаты от его теста после устранения проблем передачи параметров, разницы вообще не было.
Для сравнения стащил очень прямолинейный расчёт СЛАУ по Гауссу, матрица 1000*1000, случайные коэффициенты; i3-4170 (Haswell).
FPU+double: 4.6сек; FPU+long double: 5.5 сек — соответствует оценке влияния кэширования; SSE: 3.6 сек — с тем, что в выхлопе clang есть лёгкая векторизация.
Это ближе к тому, что времена собственно вычисления не отличаются.
> В документации описаны ситуации, когда младший бит мантиссы результата принимает непредсказуемое значение. К сожалению, прямо сейчас я не смогу предоставить ссылку на конкретный раздел документации, но если интересно, завтра могу уточнить.
Прошу таки уточнить, и заодно к каким версиям это относится. Где-то до 387-го у них было ещё много странностей, но потом вроде всё вычистили?
P.S. Есть один момент, в котором я полностью согласен, что x87 это legacy: это его неуместный стек регистров. Кому и зачем это стукнуло в голову — ХЗ, но это не единственная, мягко говоря, странность Intel. Но сейчас и его помеху снизили до минимума.