Lamaster: Прям вообще как два проекта. Независимых. Версии отдельно контролировались, соответственно. Весьма неудобно, если различий в коде не много и 100% это не лучший способ.
За Антену спасибо, погуглю.
Между сложением и вычитанием нет никакой разницы. А - Б это то же самое, что и А + (-Б). Т.е. вычитаешь; если установлен CF, значит произошло "переполнение" (мы ведь суммируем два беззнаковых числа, где отрицательное записано в дополнительном коде).
По идее, проверка флага будет эффективнее сравнения двух операндов. Ну и логически это более правильно.
Александр Худяков: Тогда вторая будет определённо эффективнее, если удастся решить проблему с драйверами. Как решить не подскажу. Весь опыт общения с Quadro карточками это перепрошитый первый GeForce MX, гордо пишущий в настройках, что он не ультра-бюджетный зелёныш, а крутой кадовский девайс.)
IllusionTurtle: > шли первыми они и выполнялись быстрее
А вот это легко объяснимо. echo пишет в html файл. Циклы большие. Чем больше написал, тем дальше писать дольше будет (при перераспределении памяти нужно бОльшие объёмы копировать будет).
Сергей: Смотря какие игры. И смотря какие обновления. Более того, многие данные даже не нужно передавать, потому что поведение пользователя "предсказывается", так что "реальное время" не всегда реально... В идеале, нужно передавать пакеты минимального объёма, т.е. на минимально возможном уровне OSI. Короче, попробуй установить TCP или UDP соединение и проверить скорость взаимодействия, а потом думай дальше.
Quadro (как и FireGL) нужны только для GPU вычислений с двойной точностью. В остальном обычные Geforce оказываются не хуже и гораздо дешевле. Конкретно под фотошоп лучше выбрать ту карту, у которой бОльшая разрядность шины. Объём видеопамяти не столь важен. Если аппаратное ускорение отключено и не используются плагины, типа PixelBender, то вообще практически безразлично, какая карта и больший профит будет от использования SSD диска для временных файлов фотошопа.
В общем случае - нет.
В качественном коде ненулевой указатель указывает на объект допустимого типа. При разрушении указатель обнуляется, чтобы больше не указывать на объекты.
becks: Если брать остаток от деления на простое число, то вероятность коллизий ооооочень низкая. С учётом того, что GUID всего вдвое больше остатка, то на практике вероятность коллизий почти нулевая. Главное, чтобы делитель 65 битным был простым числом, тогда остаток будет 64 бита.
uvelichitel: Я не знаю возможностей golang. Если разруливать коллизии (про несколько деревьев уже писали в первом ответе), то достаточно ксорить все символы строки. Если коллизии постараться избежать, то md5, но там много битовых операций. Если golang умеет в деление больших чисел, то можно остаток от деления на простое число считать. Ради словаря в 500 слов нет смысла заморачиваться и можно обычное дерево строить (8 сравнений строк в среднем потребуется). Даже ради 10000 слов особого смысла нет (всего 14 сравнений потребуется).
uvelichitel: Я понял. Дороговизна хэш-функции зависит от того, что за хэш функция. Можно хоть CRC считать, хоть банально ксорить буквы (но не надо)...
Сортированный массив имеет смысл делать только если заранее известно количество разных слов (а это не известно). Так что строй дерево и не парься, тем более памяти полно.
uvelichitel: "дешевле" только по использованию памяти и времени поиска в дереве. Хэш - сравнительно небольшое бинарное число (4-8 байт). Слова в юникоде будут иметь гораздо больший объём и сравниваться будут посимвольно. Т.е. чем больше длина слов и, чем больше вообще слов (больше высота дерева), тем больше будет выгода от хэширования.
Не знаком со спецификой golang, может на нём и нет разницы, но на настоящих языках программирования с числами работа происходит существенно быстрее, чем со строками.
Алексей Михайлусов: Слабо знаком с системой исключений Java. Не исключаю, что придётся создавать новый объект Scanner. Если нарушен инвариант, то другого выбора может не быть.
Сергей Соколов: Жаль, что не повторяются. Но! Раз данных много и числа не повторяются, то чем этих данных больше, тем меньше становится вариантов распределения разниц, между числами! В пределе, у тебя останется всего одна разница, равная "1".
Вариант из UPD обеспечит от почти никакого, до почти четырёхкратного сжатия, что само по себе неплохо. Но! Чем больше данных, тем меньше вариантов инкрементов. Так что для них вполне имеет смысл динамически строить дерево Хаффмана. Только я пока не сильно представляю, как его передавать в файле. Возможно, уменьшить блоки до трёх чисел и в свободном байте кодировать либо код Хаффмана, либо что реальные инкременты записываются. Тогда, чем больше будет размер файлов, тем более эффективно будет сжатие инкрементов работать. Опять же, в пределе, каждый блок из 3-4 чисел будет сжат в один бит. Это когда вся последовать будет различаться на единичку.)
На практике, твоего решения должно быть достаточно, если трёхкратное сжатие тебя устроит.
Сергей Соколов: Я потому и говорю о потоковом сжатии, а не об отдельном зиповании (для эксперимента это было быстрее и я всё-равно не знаю php). Я говорю об архивировании данных на лету, когда ты посылаешь байт в поток вывода, он не просто пишется на диск, а предварительно архивируется (т.е. в поток может и не попасть, пока хотя бы один байт не сформируется). Только не знаю, как это сделать на php и можно ли вообще так сделать.
Если есть много повторяющихся данных, то есть смысл попробовать RLE компрессию. Это когда сперва пишешь количество одинаковых чисел, а потом само число. При чтении они будут записаны нужное число раз. Но это сработает только если бОльшая часть чисел повторяется хотя бы по два раза. Мне опять стало интересно, я сейчас это на своём тестике проверю, что получится. У меня много повторяющихся чисел там.
Сергей Соколов: Для эксперимента написал программку, которая генерирует 100 миллионов чисел, отсортировал по возрастанию и сохранил как есть и разницу между соседними. Получилось два 400 мегабайтных файла. Сжал зипом с настройками по умолчанию, получилось 115 мегабайт для полного файла и 81 мегабайт для файла с разницами. У меня была "плохая" случайность чисел, поэтому различие между полными числами и разницами не существенная. Чем больше у тебя объём данных и чем случайнее числа, тем больше будет разница между двумя вариантами. Так что я всё-таки рекомендую именно потоковое сжатие.
Если ты будешь как-то более хитро обрабатывать данные, например, сохранять разницу в виде 1-3 байтов и флаг того, сколько байтов используется (два бита), то ты лишь увеличишь энтропию и данные будут гораздо хуже сжиматься архиваторами. Без архивирования, в лучшем случае, получится каждый 32 битный int уменьшить до 10 бит. Т.е. на треть. В моём примере это было бы 133 мегабайта. При этом код будет сложным и медленным. И вообще, на php есть возможность работы на уровне битов?
Сергей Соколов: Я на 100% уверен, что в php есть сжатие/распаковка потоковых данных чем-нибудь типа зипа. Код Хаффмана применённый непосредственно к последовательности данных будет мало эффективен, особенно, если кодировать по 32 битному числу. В том же зипе кодом Хаффмана кодируется только словарь (если не ошибаюсь), а данные кодируются прогрессивным алгоритмом (не помню названия), в котором кодируемые блоки постепенно увеличиваются в размере... В общем, я настоятельно не советую изобретать велосипед. php не для этого придумали, а чтобы использовать готовое.
За Антену спасибо, погуглю.