напишите уже какой-нибудь гайд, что ли, как за 300р поднять (и главное где, что бы можно было оплаичвать из РФ). и что бы разные протоколы если что - хоть shadow, хоть wire
А что такое "параллелизм не увеличится"? Положим, у меня есть топик и есть некоторое количество сервисов, которые читают. В общем случае, я не знаю, сколько сервисов будет (динамически поднимаются). Но нужно, что бы все сервисы получили одинаковый набор записей из топика. Что бы получить такой эффект гарантировано, что необходимо сделать? Создать много партиций (динамически создавать?) под каждый сервис-консюмер? Или просто всеми подключиться к одному топику (но там нужен номер партиции) и оно само все зачитает?
А если много партиций и сообщения раскладываются между ними, то как консьюмер, который читает из партиции №1 получит сообщения, которые попали в партицию №0?
Quazantron, а потом появился дебаггер Handy и все заиграло новыми красками. Помню даже написал редактор текстовый с шрифтом, где изменялись ширина каждому символу
Ну вот вопрос - а что быстрее, уменьшить передачу ненужных файлов по сети и проверку на их изменения, которые не будут в дальнейшем использоваться. Или все-таки быстро препроцессор запустить и уменьшить количество лишних файлов. Полагаю, что уже сделали эти замеры и свой быстрее. Ок.
А почему не заиспользовать llvm, который все распарсит и отдаст со всеми раскрученными макросами и все такое, а пришлось написать свой? Ну то есть выглядит, что backend clang как бы не студенческий проект на коленке, вроде...
Ну вот у меня проблема не найти и понять описание, а найти какая команда мне сделает то, что мне нужно. И в этом случае cheat.sh мне особо не поможет, а вот такой список - вполне
В-пятых, счетчик ходов. Это просто float переменная, добавляющая по 0.5 за каждый ход. Если переменная круглая, то ход белых. Если у нее есть дробная часть, то ход черных.
а вот это зачем? почему не простой int (uint, фиксированный 32, 64 - что хочется), и добавляем +1 (ну как обычно) и проверяем последний бит (четность). Быстро, безопасно в плане float и дробной части... понятно, наглядно... в общем, одни плюсы.
Ну странно, конечно. В официальной доке пишут, что EXPECT_EQ, если использовать на указателях будет сравнивать то, что они указывают на одну и ту же область памяти, но не саму память, а вот EXPECT_STREQ будет, как раз сравнивать память.
Либо что-то поменялось в их королевстве и они не изменили документацию, либо надо им писать с примерами...
Не смотрел код загрузчика. А там только сфера/круг работает? Логично было бы подгружать то, что актор может увидеть — например только то, что попадает в поле зрения камеры и уменьшить радиус круга. Таким образом, если брать еще алгоритм с пограничными чанками, то это может еще сильней уменьшить нагрузку. Но появится артефакт, если актор остановился, повернулся, то необходимо загружать те чанки, которые не попадали в круг.
Можно пойти дальше и вычислять скорость передвижения актора — чем она больше, тем более «вытянутой» получается область загрузки (что-то наподобие яйца, где в узкой части актор, смотрящий в направлении широкой части). И когда актор замедляется, то яйцо снова превращается в круг и подгружаются необходимые чанки.
Даже если добавят еще один байт (получив 16 бит), то следующая проблема должна наступить только при кратности 65536, чего, наверное, не достигнут, так как такой поезд на половину Европы растянется.
а я до второго дошел! ответив на первый неправильно, так как вообще-то там ошибка должна быть изза a3=5
а во втором еще веселей
нажал, что будет ошибка, но по причине синтаксиса, оказался прав (но по другой причине). видимо, какой-то джун писал и не проверял код.
Так все-таки возвращаться или «никогда больше не возвращаться»?
И получим мы после нескольких таких «невозвратов» веселый костыльный продукт, который через полгода такой разработки будет еле движим.
Если что-то пришло в голову во время ревью и времени/ресурсов нет запихнуть это в текущую версию — это должно быть сделано непременно в следующей, если с новой архитектурой согласны ведущие разработчики.
«Не возвращаться» — это путь в никуда.
Меня тут больше интересует момент, что «я знал, что надо будет писать на Perl...» и «я пошел учить Perl».
Человек только из колледжа, то есть это джуниор, то есть багажа большого нет и перл он не знает, но оффер-то есть? Видимо, где-то там иначе предлагают оффер.
напишите уже какой-нибудь гайд, что ли, как за 300р поднять (и главное где, что бы можно было оплаичвать из РФ). и что бы разные протоколы если что - хоть shadow, хоть wire
А что такое "параллелизм не увеличится"?
Положим, у меня есть топик и есть некоторое количество сервисов, которые читают. В общем случае, я не знаю, сколько сервисов будет (динамически поднимаются). Но нужно, что бы все сервисы получили одинаковый набор записей из топика.
Что бы получить такой эффект гарантировано, что необходимо сделать? Создать много партиций (динамически создавать?) под каждый сервис-консюмер? Или просто всеми подключиться к одному топику (но там нужен номер партиции) и оно само все зачитает?
А если много партиций и сообщения раскладываются между ними, то как консьюмер, который читает из партиции №1 получит сообщения, которые попали в партицию №0?
Сейчас анонсировали трансляцию только DirectX 12. Интересно, будет ли в дальнейшем трансляция OpenGL/Vulkan?
Так как это расширит количество игр, конечно же.
Quazantron, а потом появился дебаггер Handy и все заиграло новыми красками. Помню даже написал редактор текстовый с шрифтом, где изменялись ширина каждому символу
Ну вот вопрос - а что быстрее, уменьшить передачу ненужных файлов по сети и проверку на их изменения, которые не будут в дальнейшем использоваться. Или все-таки быстро препроцессор запустить и уменьшить количество лишних файлов. Полагаю, что уже сделали эти замеры и свой быстрее. Ок.
А почему не заиспользовать llvm, который все распарсит и отдаст со всеми раскрученными макросами и все такое, а пришлось написать свой? Ну то есть выглядит, что backend clang как бы не студенческий проект на коленке, вроде...
Ну вот у меня проблема не найти и понять описание, а найти какая команда мне сделает то, что мне нужно. И в этом случае cheat.sh мне особо не поможет, а вот такой список - вполне
Это не совсем так. Неизвестно, что будет делать тот или иной компилятор. В стандарте это описано как UB. http://eel.is/c++draft/expr.shift
У меня ощущение, что
Медленнее, чем
В любом случае пара операций на ход не критична.
Спасибо за статью, очень познавательно
а вот это зачем? почему не простой int (uint, фиксированный 32, 64 - что хочется), и добавляем +1 (ну как обычно) и проверяем последний бит (четность). Быстро, безопасно в плане float и дробной части... понятно, наглядно... в общем, одни плюсы.
Ну странно, конечно. В официальной доке пишут, что EXPECT_EQ, если использовать на указателях будет сравнивать то, что они указывают на одну и ту же область памяти, но не саму память, а вот EXPECT_STREQ будет, как раз сравнивать память.
Либо что-то поменялось в их королевстве и они не изменили документацию, либо надо им писать с примерами...
Надеялся, что быстро и на пальцах расскажут, как это работает под капотом, но оказалось, что это ещё один небольшой справочник про синтаксис
Можно пойти дальше и вычислять скорость передвижения актора — чем она больше, тем более «вытянутой» получается область загрузки (что-то наподобие яйца, где в узкой части актор, смотрящий в направлении широкой части). И когда актор замедляется, то яйцо снова превращается в круг и подгружаются необходимые чанки.
а во втором еще веселей
нажал, что будет ошибка, но по причине синтаксиса, оказался прав (но по другой причине). видимо, какой-то джун писал и не проверял код.
И получим мы после нескольких таких «невозвратов» веселый костыльный продукт, который через полгода такой разработки будет еле движим.
Если что-то пришло в голову во время ревью и времени/ресурсов нет запихнуть это в текущую версию — это должно быть сделано непременно в следующей, если с новой архитектурой согласны ведущие разработчики.
«Не возвращаться» — это путь в никуда.
Человек только из колледжа, то есть это джуниор, то есть багажа большого нет и перл он не знает, но оффер-то есть? Видимо, где-то там иначе предлагают оффер.