Я бы попробовал сделать тот же анализ при помощи очень старого и очень доброго SQL. Если все данные в одной таблице то ClickHouse точно так же сработает за миллисекунды (на практике видел это на 4 TB данных). А если в запросе нужно совместить несколько таблиц, то я ожидаю что классический PostgreSQL сможет найти более эффективный план запроса и сделать join быстрее чем самый быстрый Rust но "в лоб".
Вот чуть более полный бенчмарк, где Polars сравнивают с ClickHouse https://h2oai.github.io/db-benchmark/. ClickHouse там оказывается в полтора раза медленнее, действительно. Однако тест проходит лишь на 50 GB данных, хотя даже для одного сервера Clickhouse это не ощутимая нагрузка, не говоря уже о кластере.
Наверно, если портировать какой-нибудь неплохой SQL движок на Rust, то будет совсем хорошо. Например https://surrealdb.com/ так делают, но с нуля (и пока что без оптимизации запросов)
Я как раз недавно замерял - на localhost выдаёт 30 отдельных Select в одном потоке. Если запустить 32 потока по числу процессоров, то получается 400 отдельных запрос-ответов. Каждую миллисекунду. Т.е. 400'000 запросов в секунду на базе 0.3 ТБ. Если послать большие аналитические запросы, то будет ещё быстрее - один поток агрегирует 9 миллионов строк в секунду. Не ClickHouse, конечно, но для бизнес-данных этого достаточно с лихвой.
Я бы купил такую обёртку вокруг PG, просто чтобы предоставить привычный GUI Экселя для бизнес-аналитиков. Кстати, возможно, MS Access может интегрироваться с внешними БД?
Классная идея! Хотя Pivot в Excel считается уже очень продвинутой технологией, всё равно база пользователей больше, чем у любого другого инструмента.
На мой взгляд, такой адаптер будет полезнее даже не BigData, а для обычных SQL движков. Если в фирме уже есть ClickHouse, это скорее всего означает что там есть необходимость, и возможность (профессионалы, которые установили и заполняют).
Но ведь есть несравнимо больше компаний, где данные прекрасно умещаются в Postgres! И там как раз есть потребность в понятном GUI.
> Так как чуть ли не каждый слот памяти заворачивается в атом, то реализация атомов должна быть максимально быстрой и компактной.
Сразу напомнило Datomic — это очень приятная база данных, похожая на RDF, OrientDB или Node4j — только с ещё более простыми и фундаментальными концепциями
А вы пробовали использовать не движение камеры, а перемещение объекта? Ведь в реальности оба движения происходят одновременно.
Я представляю, что в таком случае смещение будет ещё нагляднее: неподвижный «плоский» фон без движения и «выпуклый» объект. Тут же бонусом и отделение объекта от фона получится.
Насколько гласит легенда, некоторые хищники именно так и видят: им тяжело классифицировать неподвижные предметы.
Вашу систему уравнений, мне кажется, можно расширить, для каждого кадра видео:
новая точка i (t+1) = (старая точка i (t) + движение точки i (t) ) * движение камеры (t)
не уверен что за операция там вместо звёздочки — умножение или сложение.
Добавим ограничения из физического мира:
— движение точки равномерно
— движение камеры равномерно (и есть априорная оценка)
— движение точки совпадает с движением её «группы» (принадлежность точки группе получаются кластеризацией точек по вектору движения)
В общем случае движение камеры это все 6 степеней свободы, а для точек достаточно 3.
И будет полноценный решатель: видео -> трёхмерная модель пространства и камеры :-)
Я как-то пользовался random-shuffle, но не понял, почему функция не возвращает новый gen? Получается, что эта функция — «тупик» для генератора случайных чисел? Как это обойти, если нужно, допустим, два случайных поля?
Эти два слова совершенно не вяжутся в одном предложении про безопасность.
Если вы сами знали о проблеме, и осознанно решили отложить исправление, то это кромешный ад.
А возможно линеаризовать эти уравнения?
Если представить её как модель в пространстве состояний, то многие свойства системы (те же гармоники) можно вычислить почти аналитически, вообще без интеграции по времени.
Ну да, в итоговом отчёте на конец месяца нужны именно две тонны.
А в операционном отчёте на любую конкретную дату, в т.ч. «на сегодня» — отдельно плюс и минус.
Разве не так?
Причём, большинство вещей может иметь (для транзакционной целостности) лишь положительный баланс. Какие-то (вроде выданных кредитов) — только отрицательный баланс.
Скорее наоборот, каждая валюта это отдельная сущность в базе! «Вещь», если хотите.
Деньги в кассе тоже совершенно отдельная вещь с суб-счетами по каждой валюте.
Этот весьма философский пункт я включил именно, чтобы избежать приведения всего «к общему знаменателю» денег в самой БД.
Так что ответы на ваш вопрос в такой системе полностью возможны. Решение о группировке и пересчёте принимается в момент составления отчёта, а не записи в БД. Просто бухгалтер не должен просить систему приводить всё к рублям, а оставить «как есть».
Более того, валюта в разной форме / счетах — это разные вещи. 100 руб в Сбербанке и 100 руб в ПСБ это разные вещи. Особенно они разные при обвале банка. Транзакция про будущую страховую выплату:
— 1 млн 200 тыс единиц «Рубль в банке Рога и Копыта» (произошло вчера)
+ 700 тыс единиц «Рубль в Сберьбанке» (произойдёт через 3 месяца)
Извините, если спутано объясняю, но в своей «методологии» я хотел избежать лишнего приведения всего в деньгам, а по-максимуму сохранять натуральные единицы.
Вот здорово! Бухгалтерский учёт без придурей. Ну и изучение ЯП до такого достойного уровня вызывает глубокое уважение!
Я для себя упрощал БУ так:
1. С помощью отрицательных чисел: у меня -2 яблока = я должен 2 яблока
Сумма каждой проводки аксиоматически принимается равной нулю, так что sum(Credit) = sum(Debit)
sum(Credit) — sum(Debit) = 0.
Какие-то счета удобнее вести, помножив всё уравнение на -1, но это нужно лишь для преставления пользователю.
А вы учитываете отрицательные значения?
2. Применения единиц измерения в расширенном физическом смысле.
Цена это коэффициент преобразования одной величины в другую.
2 яблока — 1 груша = 0 рублей (баланс операции обмена)
это можно решить, например, если ввести коэффициенты преобразования яблок и груш в рубли — их цены.
Таким образом, денежное представление баланса является лишь одним из возможных. Для управленческого учёта можно представлять базу сразу в натуральных единицах. Это как выбор единиц измерения для графиков — кг или граммы. Меняются коэффициенты и числа, но «суть» остаётся той же.
Возможно ли автоматическое аннотироване подходящих функций?
Допустим, в контексте того же LLVM. На этапе, когда все основные оптимизации (вроде выноса инвариантного кода за цикл) уже выполнены, но код ещё не векторизован — оптимизатор может попробовать оценить пригодность метода для каждого очевидного цикла…
Ещё круче может оказаться применимость для JVM или V8 — их JIT-компилятор уже умеет анализировать циклы и применяет loop unrolling для «небольших» циклов. Я могу представить, что туда можно дописать «else» и попробовать оценить применимость вашей опимизации к тому циклу.
// Просто мне кажется непродуктивным, что вы вынуждены решать уже решённые проблемы вроде вывода типов или других промежуточных оптимизаций, которые уже давно решены вне Python
Я бы попробовал сделать тот же анализ при помощи очень старого и очень доброго SQL. Если все данные в одной таблице то ClickHouse точно так же сработает за миллисекунды (на практике видел это на 4 TB данных). А если в запросе нужно совместить несколько таблиц, то я ожидаю что классический PostgreSQL сможет найти более эффективный план запроса и сделать join быстрее чем самый быстрый Rust но "в лоб".
Вот чуть более полный бенчмарк, где Polars сравнивают с ClickHouse https://h2oai.github.io/db-benchmark/. ClickHouse там оказывается в полтора раза медленнее, действительно. Однако тест проходит лишь на 50 GB данных, хотя даже для одного сервера Clickhouse это не ощутимая нагрузка, не говоря уже о кластере.
Наверно, если портировать какой-нибудь неплохой SQL движок на Rust, то будет совсем хорошо. Например https://surrealdb.com/ так делают, но с нуля (и пока что без оптимизации запросов)
Сколько строчек или мегабайт в
flights-data?Я как раз недавно замерял - на localhost выдаёт 30 отдельных Select в одном потоке. Если запустить 32 потока по числу процессоров, то получается 400 отдельных запрос-ответов. Каждую миллисекунду. Т.е. 400'000 запросов в секунду на базе 0.3 ТБ. Если послать большие аналитические запросы, то будет ещё быстрее - один поток агрегирует 9 миллионов строк в секунду. Не ClickHouse, конечно, но для бизнес-данных этого достаточно с лихвой.
Я бы купил такую обёртку вокруг PG, просто чтобы предоставить привычный GUI Экселя для бизнес-аналитиков. Кстати, возможно, MS Access может интегрироваться с внешними БД?
Классная идея! Хотя Pivot в Excel считается уже очень продвинутой технологией, всё равно база пользователей больше, чем у любого другого инструмента.
На мой взгляд, такой адаптер будет полезнее даже не BigData, а для обычных SQL движков. Если в фирме уже есть ClickHouse, это скорее всего означает что там есть необходимость, и возможность (профессионалы, которые установили и заполняют).
Но ведь есть несравнимо больше компаний, где данные прекрасно умещаются в Postgres! И там как раз есть потребность в понятном GUI.
Как-то не живо идёт аукцион
Они обычно выпускают два релиза в год.
Это лучше, т.к. нет путаницы с месяцами.
Убунту же пишет именно месяц: 14.04 (апрель), 14.10 (октябрь)
Сразу напомнило Datomic — это очень приятная база данных, похожая на RDF, OrientDB или Node4j — только с ещё более простыми и фундаментальными концепциями
А вы пробовали использовать не движение камеры, а перемещение объекта? Ведь в реальности оба движения происходят одновременно.
Я представляю, что в таком случае смещение будет ещё нагляднее: неподвижный «плоский» фон без движения и «выпуклый» объект. Тут же бонусом и отделение объекта от фона получится.
Насколько гласит легенда, некоторые хищники именно так и видят: им тяжело классифицировать неподвижные предметы.
Вашу систему уравнений, мне кажется, можно расширить, для каждого кадра видео:
новая точка i (t+1) = (старая точка i (t) + движение точки i (t) ) * движение камеры (t)
не уверен что за операция там вместо звёздочки — умножение или сложение.
Добавим ограничения из физического мира:
— движение точки равномерно
— движение камеры равномерно (и есть априорная оценка)
— движение точки совпадает с движением её «группы» (принадлежность точки группе получаются кластеризацией точек по вектору движения)
В общем случае движение камеры это все 6 степеней свободы, а для точек достаточно 3.
И будет полноценный решатель: видео -> трёхмерная модель пространства и камеры :-)
Да, исправление после этого поста произошло очень оперативно! Тут разработчики Яндекса молодцы, вопрсов нет.
В 23:16 появился пост, через полтора часа (ночью) появился комментарий «исправили». Это здорово и оперативно.
Эти два слова совершенно не вяжутся в одном предложении про безопасность.
Если вы сами знали о проблеме, и осознанно решили отложить исправление, то это кромешный ад.
АД
Вот ещё интересные мыли на эту тему: habrahabr.ru/post/244465/
Будет ли анализатор рассматривать эту переменную, в качестве константы? А если без final?
Если представить её как модель в пространстве состояний, то многие свойства системы (те же гармоники) можно вычислить почти аналитически, вообще без интеграции по времени.
А в операционном отчёте на любую конкретную дату, в т.ч. «на сегодня» — отдельно плюс и минус.
Разве не так?
Причём, большинство вещей может иметь (для транзакционной целостности) лишь положительный баланс. Какие-то (вроде выданных кредитов) — только отрицательный баланс.
Деньги в кассе тоже совершенно отдельная вещь с суб-счетами по каждой валюте.
Этот весьма философский пункт я включил именно, чтобы избежать приведения всего «к общему знаменателю» денег в самой БД.
Так что ответы на ваш вопрос в такой системе полностью возможны. Решение о группировке и пересчёте принимается в момент составления отчёта, а не записи в БД. Просто бухгалтер не должен просить систему приводить всё к рублям, а оставить «как есть».
Более того, валюта в разной форме / счетах — это разные вещи. 100 руб в Сбербанке и 100 руб в ПСБ это разные вещи. Особенно они разные при обвале банка. Транзакция про будущую страховую выплату:
— 1 млн 200 тыс единиц «Рубль в банке Рога и Копыта» (произошло вчера)
+ 700 тыс единиц «Рубль в Сберьбанке» (произойдёт через 3 месяца)
Извините, если спутано объясняю, но в своей «методологии» я хотел избежать лишнего приведения всего в деньгам, а по-максимуму сохранять натуральные единицы.
Я для себя упрощал БУ так:
1. С помощью отрицательных чисел: у меня -2 яблока = я должен 2 яблока
Сумма каждой проводки аксиоматически принимается равной нулю, так что sum(Credit) = sum(Debit)
sum(Credit) — sum(Debit) = 0.
Какие-то счета удобнее вести, помножив всё уравнение на -1, но это нужно лишь для преставления пользователю.
А вы учитываете отрицательные значения?
2. Применения единиц измерения в расширенном физическом смысле.
Цена это коэффициент преобразования одной величины в другую.
2 яблока — 1 груша = 0 рублей (баланс операции обмена)
это можно решить, например, если ввести коэффициенты преобразования яблок и груш в рубли — их цены.
Таким образом, денежное представление баланса является лишь одним из возможных. Для управленческого учёта можно представлять базу сразу в натуральных единицах. Это как выбор единиц измерения для графиков — кг или граммы. Меняются коэффициенты и числа, но «суть» остаётся той же.
Допустим, в контексте того же LLVM. На этапе, когда все основные оптимизации (вроде выноса инвариантного кода за цикл) уже выполнены, но код ещё не векторизован — оптимизатор может попробовать оценить пригодность метода для каждого очевидного цикла…
Ещё круче может оказаться применимость для JVM или V8 — их JIT-компилятор уже умеет анализировать циклы и применяет loop unrolling для «небольших» циклов. Я могу представить, что туда можно дописать «else» и попробовать оценить применимость вашей опимизации к тому циклу.
// Просто мне кажется непродуктивным, что вы вынуждены решать уже решённые проблемы вроде вывода типов или других промежуточных оптимизаций, которые уже давно решены вне Python