По частоте заправок судить не очень правильно. Я, например, зимой просто езжу медленнее и у меня заметно расход падает. Какова тут доля кондиционера -- определить сложно.
Труба с теплоносителем не может нигде разогреться сильнее, чем температура теплоносителя на входе. А кабель постоянно выделяет тепло, каждым метром. Если отвод тепла плохой (например, сверху шкаф стоит или одеяло упало на пол), то под ним будет локальный очаг разогрева)
К сожалению, на самом деле это не работает, потому что в нашей методике парсинга используется поиск с возвратом, особенно при принятии решения в функциях either(), maybe() и choice(). При обработке either() парсинг какое-то время может выполняться успешно, а потом внезапно завершиться неудачно. Когда такое происходит, всё откатывается назад и проверяется другая ветвь парсинга.
Поиск с возвратом можно написать с использованием continuations, но они не включены в штатный питон, тут stackless python в помощь.
Хорошая статья, но опущен важный момент -- дизайн слайдов. По опыту (научных презентаций) могу сказать, что скверно сверстанные слайды могут легко испортить весь доклад. Самая частая ошибка -- слишком мелкий текст или важный текст, размещенный внизу слайда (эту часть экрана многие могут вообще не видеть). Обычно я аспирантам советую сначала сверстать слайды так, как им нравится, а потом просто увеличить все шрифты в два раза)
Мы занимаемся ГД/МГД-моделированием на сетках и открыли для себя этот эффект довольно давно -- оказалось, что если создать небольшой массив, скопировать туда данные с сетки, обработать их и скопировать результат в результирующую сетку, это может дать прирост производительности в разы, хотя, казалось бы, лишние копирования. Обычно эта "кэш-сетка" у нас одномерная, так как мы делаем прогонки вдоль осей, для вычисления потоков.
Когда-то я ударился в эксперименты и решил написать генератор кода, который на входе получал бы уравнения в матричном виде и на выходе давал бы распаралеленную программу. В итоге идея не взлетела (по причине моего слабого понимания некоторых вещей на тот момент), но позволила мне дешево поэкспериментировать с разными методами распаралеливания, так как оно все равно делалось автоматически. Так я с удивлением узнал, что spatial decomposition + MPI дает бОльшую производительность, чем чистый OpenMP на одном процессоре, несмотря на обмены MPI, за счет эффекта маленькой сетки. В итоге я пришел к тому, что нужно брать одномерные столбцы/строки из трехмерной сетки, объединять их в пучки подходящего размера и отправлять на счет, часть в CPU, часть в GPU, чтобы загрузить вообще всё. Но я не смог тогда справиться с синхронизацией и в результате половина мощностей всегда простаивала. А в те редкие моменты, когда она не простаивала, узел кластера зависал из-за перегрева или из-за какой-то другой причины, связанной с перегрузом :)
Я бы предложил разбить сетку на куски, помещающиеся в кэш ядра, потом эти куски обрабатывать параллельно, используя SIMD на нижнем уровне, тогда можно выдоить практически всю производительность из процессоров. Подозреваю, автоматический параллелизатор интеловского фортрана так и делает, по этой причине он и дал выигрыш в одном из тестов.
А всякие пометки делать? Когда слушаешь научный доклад или лекцию, например. Даже когда читаешь сложный текст, иногда надо что-то выписывать для памяти, чтобы не скакать туда-сюда по содержанию.
Только не в этом случае. Вращающаяся Земля -- неинерциальная система отсчета. Даже сидя в запертой комнате, не видя Солнца, можно определить, что Земля вращается.
Не совсем так. В научной работе не должно быть "висящих в воздухе" утверждений (ну, кроме самых тривиальных, может быть), на каждое должно быть или обоснование (если это результат автора) или ссылка на источник. Не обязательно на первоисточник, но это считается хорошим тоном. В любой науке.
Собственно, понимание того, что такое программатор, как раз и нужно, чтобы люди не думали, что его вырезают из дерева. Иначе можно и до карго-культа легко дойти.
Собственно, понимание того, что такое программатор, как раз и нужно, чтобы люди не думали, что его вырезают из дерева. Иначе можно и до карго-культа легко дойти.
Не пробовали смотреть в сторону Progressive Web App (PWA)? Если не нужен прямой доступ к железу, вполне себе неплохая заявка на кроссплатформенность.
По частоте заправок судить не очень правильно. Я, например, зимой просто езжу медленнее и у меня заметно расход падает. Какова тут доля кондиционера -- определить сложно.
Автор еще скромно не показал электрощит в детской. А ведь это самое интересное!
Труба с теплоносителем не может нигде разогреться сильнее, чем температура теплоносителя на входе. А кабель постоянно выделяет тепло, каждым метром. Если отвод тепла плохой (например, сверху шкаф стоит или одеяло упало на пол), то под ним будет локальный очаг разогрева)
К сожалению, на самом деле это не работает, потому что в нашей методике
парсинга используется поиск с возвратом, особенно при принятии решения в
функциях
either()
,maybe()
иchoice()
. При обработкеeither()
парсинг какое-то время может выполняться успешно, а потом внезапно
завершиться неудачно. Когда такое происходит, всё откатывается назад и
проверяется другая ветвь парсинга.
Поиск с возвратом можно написать с использованием continuations, но они не включены в штатный питон, тут stackless python в помощь.
Хорошая статья, но опущен важный момент -- дизайн слайдов. По опыту (научных презентаций) могу сказать, что скверно сверстанные слайды могут легко испортить весь доклад. Самая частая ошибка -- слишком мелкий текст или важный текст, размещенный внизу слайда (эту часть экрана многие могут вообще не видеть). Обычно я аспирантам советую сначала сверстать слайды так, как им нравится, а потом просто увеличить все шрифты в два раза)
Ну примерно, но в астрофизических применениях. Вязкость у нас своеобразная, не такая как в уравнениях Навье-Стокса.
Мы занимаемся ГД/МГД-моделированием на сетках и открыли для себя этот эффект довольно давно -- оказалось, что если создать небольшой массив, скопировать туда данные с сетки, обработать их и скопировать результат в результирующую сетку, это может дать прирост производительности в разы, хотя, казалось бы, лишние копирования. Обычно эта "кэш-сетка" у нас одномерная, так как мы делаем прогонки вдоль осей, для вычисления потоков.
Когда-то я ударился в эксперименты и решил написать генератор кода, который на входе получал бы уравнения в матричном виде и на выходе давал бы распаралеленную программу. В итоге идея не взлетела (по причине моего слабого понимания некоторых вещей на тот момент), но позволила мне дешево поэкспериментировать с разными методами распаралеливания, так как оно все равно делалось автоматически. Так я с удивлением узнал, что spatial decomposition + MPI дает бОльшую производительность, чем чистый OpenMP на одном процессоре, несмотря на обмены MPI, за счет эффекта маленькой сетки. В итоге я пришел к тому, что нужно брать одномерные столбцы/строки из трехмерной сетки, объединять их в пучки подходящего размера и отправлять на счет, часть в CPU, часть в GPU, чтобы загрузить вообще всё. Но я не смог тогда справиться с синхронизацией и в результате половина мощностей всегда простаивала. А в те редкие моменты, когда она не простаивала, узел кластера зависал из-за перегрева или из-за какой-то другой причины, связанной с перегрузом :)
Отличная статья, спасибо!
Я бы предложил разбить сетку на куски, помещающиеся в кэш ядра, потом эти куски обрабатывать параллельно, используя SIMD на нижнем уровне, тогда можно выдоить практически всю производительность из процессоров. Подозреваю, автоматический параллелизатор интеловского фортрана так и делает, по этой причине он и дал выигрыш в одном из тестов.
Если бы не было чат-бота, я бы не смог написать эту статью!
Зачем критику? Есть "краткие пересказы" -- 5 минут и ты образованный человек!
Я всё жду, когда уже кто-то догадается сделать формальный язык программирования для составления промптов и история завершит очередной виток)
А всякие пометки делать? Когда слушаешь научный доклад или лекцию, например. Даже когда читаешь сложный текст, иногда надо что-то выписывать для памяти, чтобы не скакать туда-сюда по содержанию.
Только не в этом случае. Вращающаяся Земля -- неинерциальная система отсчета. Даже сидя в запертой комнате, не видя Солнца, можно определить, что Земля вращается.
Не совсем так. В научной работе не должно быть "висящих в воздухе" утверждений (ну, кроме самых тривиальных, может быть), на каждое должно быть или обоснование (если это результат автора) или ссылка на источник. Не обязательно на первоисточник, но это считается хорошим тоном. В любой науке.
Такой персонаж есть на любом сайте, где разрешены комментарии. В колхозе -- колхозник, на Хабре -- программист. В сообществе, так сказать, необходим.
Именно по этой причине современный софт имеет настолько низкое качество.
Собственно, понимание того, что такое программатор, как раз и нужно, чтобы люди не думали, что его вырезают из дерева. Иначе можно и до карго-культа легко дойти.
Собственно, понимание того, что такое программатор, как раз и нужно, чтобы люди не думали, что его вырезают из дерева. Иначе можно и до карго-культа легко дойти.
Хорошо. Тогда поясните, как вы представляете вырезание программатора из дерева?