А мысленное представление что руки расположены на уровне поясницы, вероятно позволит меньше концентрироваться на движениях для уравновешивания миски с супом, отчего равновесие только выиграет.
Теперь понял, что имел в виду автор (по его тексту выходило, что держать кружку и представлять описанное — не обязательно одновременно).
Взял кружку, представил (ну или попытался представить). Какая-то ерунда получается: вместо того, чтобы концентрироваться на кружке, внимание сосредоточено на другом. Результат одинаковый — пролил)
Вообще, если кипяток нести, как-то надёжнее получается (не хочется проливать кипяток на пальцы).
То, что человек себе представляет, называется "фантазией". Чтобы приблизиться к истине, нужно приложить несколько другие усилия. Хотя бы акселерометром воспользоваться.
Сравниваем в каком из случаев сделать это проще.
В этом комменте говорится, что по опыту — должно быть не проще. Слова против опыта?
Теперь представьте себе, что ваш плечевой пояс расположен на уровне таза, плечевые суставы на уровне тазобедренных.
Ок, представил.
Проверьте результат. Насколько проще стало нести сосуд с водой, не расплескивая её?
Проверить КАК? Математическая модель, компьютерная модель, биоинженерия или что ?
UPD. Все же сделайте урок, прежде чем писать комментарий.
Какой урок? Переставить руки? А это вообще возможно? Если вам это удалось, видео было бы более информативно. Симуляция тоже.
Надеюсь, вы понимаете, что мысленный эксперимент хорош в философии, а на практике нужно либо чёткое следование математическим методам для построения адекватной мат.модели (т.е. объяснения), либо наблюдение (это немного хуже для достоверности).
То, что появилось в результате мысленного эксперимента, не подкреплённого "серьёзной" логикой и математикой, к реальности отношения может не иметь. Философам этого может быть достаточно, но в статье вопрос практический, и мысленными экспериментами для выявления истины здесь не обойтись.
Соответственно интересным является вопрос о том, можно-ли не нарушая положения теории информации передать сообщение объёмом меньше, чем минимальный объём, который может быть достигнут при самом лучшем сжатии данных.
Насколько хорошо ваше "самое лучшее сжатие данных"?
По опыту знаю, что если обработать исходные данные примитивным сжатием с учётом специфики данных (дельта-кодированием, или просто удалить повторяющиеся нули, наподобие RLE; или в некоторых случаях записать матрицы по столбцам, а не по строкам), то архиваторы начинают справляться лучше (иногда — сильно лучше). Так что, если ваше "самое лучшее сжатие" не обеспечивает теоретического минимального объёма, то ответ — "можно".
Чтобы получить близкий к теоретически минимальному объём, нужно кодировать сообщения с существенным учётом контекста.
Как минимум, если это речь — нужно кодировать семантику, а не слова (что-то вроде Лингва Технис у Адептус Механикус, хотя это вымышленный язык).
Например, «Поздравляю тебя, Шарик, ты балбес!», может кодироваться как ( :обращение-к=Шарик :истинность=:сарказм :я :поздравляю :тебя ( :ты :есть :балбес))
где : слово — некоторые понятия из известного обоим сторонам словаря. Подобным способом можно однозначно и без потерь закодировать любое выражение языка, любую мысль. (а вот мой пример получился неоднозначным)
Контекстное кодирование может дополнительно уменьшить объём данных, например, если речь идёт о том, произошли ли события А, В, С,D то достаточно 4х бит, если есть дополнительные известные обоим сторонам причинно-следственные связи, то может быть достаточно меньшего числа бит.
Арифметическое кодирование дополнительно может упаковать сообщения с нецелым количеством бит информации.
А слова из букв идеально не сжать, по крайней мере без знания языка архиватором. Они сами по себе имеют избыточность; для архиватора, не имеющего хорошей модели языка, сложно её обработать корректно и полностью.
Это зря. Не рекомендую такой подход. У GPU совершенно другая архитектура, CPU-код очень плохо ложится на неё. Если задача не разбита на несколько тысяч одновременно работающих нитей (в несколько раз больше, чем ядер) — видеокарта будет работать неэффективно. Туда же относятся особенности ветвлений.
В общем случае, архитектуру "железа" следует иметь в виду.
(Конечно, есть случаи, когда 10х будет достаточно, тогда можно просто скопировать код. Но чаще получить 200х вместо 10х будет лучше)
Получить по сравнению с одним ядром CPU 10-кратное ускорение на видеокарте с 1500 ядрами как-то слишком неэффективно. На других задачах у меня, как правило, получалось 20х на 200 ядрах, без особых оптимизаций. Согласитесь, 150-кратное замедление по сравнению с "теорией" — это много.
Нужно попробовать учесть специфику CUDA (выполнение программы варпами и некоторую нелюбовь к ветвлениям):
Для определения, является ли число sum пятой степенью целого числа, вместо бинарного поиска можно бы попробовать double r = pow(sum,0.2) ; bool isPower5 = abs((uint32)(r+0.5)-r) < EPS; Не уверен, что возведение в степень действительно будет быстрее, но вдруг.
Самое важное: нити в вашей программе получают блоки работы разного объёма, поэтому в конце будут работать лишь несколько (а не несколько тысяч, как поддерживает GPU) варпов, на которые свалилась бОльшая часть работы. Остальная часть GPU будет простаивать. Нужно разбить задачу на блоки примерно равного объёма, например, как-то пронумеровавать их, или обсчитывать меньшими кусками (вызывать ядро много раз), чтобы равномерно загрузить GPU. На OpenMP было бы достаточно написать #pragma omp sсhedule(dynamic,n), на CUDA, наверно, можно попробовать рекурсивно вызывать ядро из того же ядра, CUDA вроде бы это сейчас поддерживает.
Если брать научные статьи, в англоязычной введение будет страниц на 5, с обстоятельным описанием ранее достигнутых результатов, и только потом собственно то, ради чего статья. В русских статьях введение от пары слов до нескольких абзацев, и потом сразу "по делу" (чтобы всё понять, надо быть автором этой статьи). То ли традиции, то ли отсутствие денег (за публикацию автор обычно постранично платит).
А ещё в некоторых (не научных) книгах американских авторов "вступление" бывает таким долгим, что после этих 50 страниц бла-бла-бла про то, как автор ехал куда-то и ходил к кому-то, читать книгу уже не хочется. Специфика менталитета что ли? (к слову, обычно вступления не настолько длинные).
У автора одному ключу соответствует довольно большой список записей.
Возможно, "обычная" СУБД в этом случае из-за фрагментации списков записей с одним ключом будет тормозить при добавлении, да и при поиске (зависит от последовательности добавления; вероятно, перед поиском БД можно дефрагментировать).
О том, как раскидать миллиард записей по файлам? Так это почти тривиально не такая уж сложная задача.
Предоставить сообществу код? Но тогда хотелось бы видеть лицензию и комментарии в коде (единственный — комментарий репозитория "Key/value(s) database capable for effective storage of billions of records" — мало о чём говорит). Вообще, текущая ревизия — неплохой пример того, что т. н. "самодокументируемый код" плохо понятен. Описание "алгоритмов" тоже не слишком подробно.
И самое главное — где результаты замеров скорости записи и поиска? Сколько ключей, сколько записей на один ключ, какой их объём?
Интересно было бы увидеть скорость с использованием других ФС и других алгоритмов сжатия. gzip всё-таки не самый быстрый (и не самый сильный) компрессор.
Тема интересна, но освещена недостаточно подробно.
Неужели для консольной программы писать графический инсталлятор со всякими Далее-Далее-Готово?
Это не относится к только консольным программам, но можно взять генератор инсталляторов (InnoSetup etc) и написать только небольшой конфиг к нему (есть даже графические утилиты для "написания" таких конфигов). Полученный инсталлятор, как правило, можно запустить и в "тихом" режиме.
Ассемблер вернётся когда Закон Мура прекратит своё действие.
Вряд ли. В глобальном плане эффективнее по трудозатратам вкладываться в продвинутые оптимизаторы. В наш век интернета Один раз реализуется некоторая оптимизация в компиляторе — и её могут использовать все.
А продвинутых программистов, знающих все тонкости (или достаточно тонкостей, чтобы выиграть у оптимизатора), из-за увеличения сложности систем очень мало, и работают они медленнее компилятора.
Теперь понял, что имел в виду автор (по его тексту выходило, что держать кружку и представлять описанное — не обязательно одновременно).
Взял кружку, представил (ну или попытался представить). Какая-то ерунда получается: вместо того, чтобы концентрироваться на кружке, внимание сосредоточено на другом. Результат одинаковый — пролил)
Вообще, если кипяток нести, как-то надёжнее получается (не хочется проливать кипяток на пальцы).
То, что человек себе представляет, называется "фантазией". Чтобы приблизиться к истине, нужно приложить несколько другие усилия. Хотя бы акселерометром воспользоваться.
В этом комменте говорится, что по опыту — должно быть не проще. Слова против опыта?
Ок, представил.
Проверить КАК? Математическая модель, компьютерная модель,
биоинженерияили что ?Какой урок? Переставить руки? А это вообще возможно? Если вам это удалось, видео было бы более информативно. Симуляция тоже.
Надеюсь, вы понимаете, что мысленный эксперимент хорош в философии, а на практике нужно либо чёткое следование математическим методам для построения адекватной мат.модели (т.е. объяснения), либо наблюдение (это немного хуже для достоверности).
То, что появилось в результате мысленного эксперимента, не подкреплённого "серьёзной" логикой и математикой, к реальности отношения может не иметь. Философам этого может быть достаточно, но в статье вопрос практический, и мысленными экспериментами для выявления истины здесь не обойтись.
А ещё оно целое и положительное.Насколько хорошо ваше "самое лучшее сжатие данных"?
По опыту знаю, что если обработать исходные данные примитивным сжатием с учётом специфики данных (дельта-кодированием, или просто удалить повторяющиеся нули, наподобие RLE; или в некоторых случаях записать матрицы по столбцам, а не по строкам), то архиваторы начинают справляться лучше (иногда — сильно лучше). Так что, если ваше "самое лучшее сжатие" не обеспечивает теоретического минимального объёма, то ответ — "можно".
Чтобы получить близкий к теоретически минимальному объём, нужно кодировать сообщения с существенным учётом контекста.
Как минимум, если это речь — нужно кодировать семантику, а не слова (что-то вроде Лингва Технис у Адептус Механикус, хотя это вымышленный язык).
Например, «Поздравляю тебя, Шарик, ты балбес!», может кодироваться как
( :обращение-к=Шарик :истинность=:сарказм :я :поздравляю :тебя ( :ты :есть :балбес))где : слово — некоторые понятия из известного обоим сторонам словаря. Подобным способом можно однозначно и без потерь закодировать любое выражение языка, любую мысль. (а вот мой пример получился неоднозначным)
Контекстное кодирование может дополнительно уменьшить объём данных, например, если речь идёт о том, произошли ли события А, В, С,D то достаточно 4х бит, если есть дополнительные известные обоим сторонам причинно-следственные связи, то может быть достаточно меньшего числа бит.
Арифметическое кодирование дополнительно может упаковать сообщения с нецелым количеством бит информации.
А слова из букв идеально не сжать, по крайней мере без знания языка архиватором. Они сами по себе имеют избыточность; для архиватора, не имеющего хорошей модели языка, сложно её обработать корректно и полностью.
Наверно, при кодировании без потерь номер паттерна будет иметь ту же длину, что и сам паттерн.
Вариация идеи: Для здоровых людей проще сделать некое Универсальное Блюдо со всеми элементами, здоровый организм разберётся..
Но в bash есть и C-b.
В tmux можно нажать C-a дважды, чтобы послать одиночный C-a программе. Со screen конечно неудобно будет, но в bash'е — приемлемо.
Сочетание Ctrl+b в tmux, имхо, неудобное для пальцев.
Несложно заменить его на Ctrl+a, добавив в
/etc/tmux.confстрокиА попробуйте внешний цикл на CPU вынести?
Это зря. Не рекомендую такой подход. У GPU совершенно другая архитектура, CPU-код очень плохо ложится на неё. Если задача не разбита на несколько тысяч одновременно работающих нитей (в несколько раз больше, чем ядер) — видеокарта будет работать неэффективно. Туда же относятся особенности ветвлений.
В общем случае, архитектуру "железа" следует иметь в виду.
(Конечно, есть случаи, когда 10х будет достаточно, тогда можно просто скопировать код. Но чаще получить 200х вместо 10х будет лучше)
«Они следят за мной с помощью моей аппаратуры!»((((
Получить по сравнению с одним ядром CPU 10-кратное ускорение на видеокарте с 1500 ядрами как-то слишком неэффективно. На других задачах у меня, как правило, получалось 20х на 200 ядрах, без особых оптимизаций. Согласитесь, 150-кратное замедление по сравнению с "теорией" — это много.
Нужно попробовать учесть специфику CUDA (выполнение программы варпами и некоторую нелюбовь к ветвлениям):
double r = pow(sum,0.2) ; bool isPower5 = abs((uint32)(r+0.5)-r) < EPS;Не уверен, что возведение в степень действительно будет быстрее, но вдруг.#pragma omp sсhedule(dynamic,n), на CUDA, наверно, можно попробовать рекурсивно вызывать ядро из того же ядра, CUDA вроде бы это сейчас поддерживает.Есть такое.
Если брать научные статьи, в англоязычной введение будет страниц на 5, с обстоятельным описанием ранее достигнутых результатов, и только потом собственно то, ради чего статья. В русских статьях введение от пары слов до нескольких абзацев, и потом сразу "по делу" (чтобы всё понять, надо быть автором этой статьи). То ли традиции, то ли отсутствие денег (за публикацию автор обычно постранично платит).
А ещё в некоторых (не научных) книгах американских авторов "вступление" бывает таким долгим, что после этих 50 страниц бла-бла-бла про то, как автор ехал куда-то и ходил к кому-то, читать книгу уже не хочется. Специфика менталитета что ли? (к слову, обычно вступления не настолько длинные).
Автор той статьи сводит её к формуле без использования массивов.
Да, это не тривиально. Ради этого стоило писать статью. Думаю, и на хабре её бы высоко оценили.
Тогда либо первому юрлицу придётся платить налог с продаж, либо второму — НДС (но в своей стране). Процент, думаю, будет примерно тот же.
У автора одному ключу соответствует довольно большой список записей.
Возможно, "обычная" СУБД в этом случае из-за фрагментации списков записей с одним ключом будет тормозить при добавлении, да и при поиске (зависит от последовательности добавления; вероятно, перед поиском БД можно дефрагментировать).
А уникальных ключей сколько?
Не вполне понятно, для чего эта статья.
О том, как раскидать миллиард записей по файлам? Так это
почти тривиальноне такая уж сложная задача.Предоставить сообществу код? Но тогда хотелось бы видеть лицензию и комментарии в коде (единственный — комментарий репозитория "Key/value(s) database capable for effective storage of billions of records" — мало о чём говорит). Вообще, текущая ревизия — неплохой пример того, что т. н. "самодокументируемый код" плохо понятен. Описание "алгоритмов" тоже не слишком подробно.
И самое главное — где результаты замеров скорости записи и поиска? Сколько ключей, сколько записей на один ключ, какой их объём?
Интересно было бы увидеть скорость с использованием других ФС и других алгоритмов сжатия. gzip всё-таки не самый быстрый (и не самый сильный) компрессор.
Тема интересна, но освещена недостаточно подробно.
Это не относится к только консольным программам, но можно взять генератор инсталляторов (InnoSetup etc) и написать только небольшой конфиг к нему (есть даже графические утилиты для "написания" таких конфигов). Полученный инсталлятор, как правило, можно запустить и в "тихом" режиме.
Вряд ли. В глобальном плане эффективнее по трудозатратам вкладываться в продвинутые оптимизаторы.
В наш век интернетаОдин раз реализуется некоторая оптимизация в компиляторе — и её могут использовать все.А продвинутых программистов, знающих все тонкости (или достаточно тонкостей, чтобы выиграть у оптимизатора), из-за увеличения сложности систем очень мало, и работают они медленнее компилятора.