Здравствуйте, na1s, Вы писали:
N>Есть такие данные: N>unsigned char numChar[6];
N>теперь их надо преобразовать в uint64. Сейчас это делается так:
N>uint64 tmp = num.lsnChar[0]; N>tmp <<= 8; N>tmp += num.numChar[1]; N>tmp <<= 8; N>tmp += num.numChar[2]; N>tmp <<= 8; N>tmp += num.numChar[3]; N>tmp <<= 8; N>tmp += num.numChar[4]; N>tmp <<= 8; N>tmp += num.numChar[5]; N>А возможно ли как-нибудь ускорить процесс?
А что у тебя в каждом элементе массива?
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Здравствуйте, na1s, Вы писали:
N>Есть такие данные: N>unsigned char numChar[6];
N>теперь их надо преобразовать в uint64. Сейчас это делается так:
N>uint64 tmp = num.lsnChar[0]; N>tmp <<= 8; N>tmp += num.numChar[1]; N>tmp <<= 8; N>tmp += num.numChar[2]; N>tmp <<= 8; N>tmp += num.numChar[3]; N>tmp <<= 8; N>tmp += num.numChar[4]; N>tmp <<= 8; N>tmp += num.numChar[5];
N>А возможно ли как-нибудь ускорить процесс?
А тебе именно в таком порядке надо? Если можно и в обратном (т.е. [0] в младшем разряде), то можно так: uint64 tmp = *(uint64 *)lsnChar & (uint64)0x0000ffffffffffff;
Здравствуйте, vadimcher, Вы писали:
V>Здравствуйте, na1s, Вы писали:
N>>Есть такие данные: N>>unsigned char numChar[6];
N>>теперь их надо преобразовать в uint64. Сейчас это делается так:
N>>uint64 tmp = num.lsnChar[0]; N>>tmp <<= 8; N>>tmp += num.numChar[1]; N>>tmp <<= 8; N>>tmp += num.numChar[2]; N>>tmp <<= 8; N>>tmp += num.numChar[3]; N>>tmp <<= 8; N>>tmp += num.numChar[4]; N>>tmp <<= 8; N>>tmp += num.numChar[5];
N>>А возможно ли как-нибудь ускорить процесс?
V>А тебе именно в таком порядке надо? Если можно и в обратном (т.е. [0] в младшем разряде), то можно так: uint64 tmp = *(uint64 *)lsnChar & (uint64)0x0000ffffffffffff;
В том то и дело, что в обратном. А то по времени долго работает предыдущий кусок кода, а как соптимизировать без понятия.
Здравствуйте, na1s, Вы писали:
V>>А тебе именно в таком порядке надо? Если можно и в обратном (т.е. [0] в младшем разряде), то можно так: uint64 tmp = *(uint64 *)lsnChar & (uint64)0x0000ffffffffffff; N>В том то и дело, что в обратном. А то по времени долго работает предыдущий кусок кода, а как соптимизировать без понятия.
Здравствуйте, труженик села, Вы писали:
ТС>Здравствуйте, na1s, Вы писали:
V>>>А тебе именно в таком порядке надо? Если можно и в обратном (т.е. [0] в младшем разряде), то можно так: uint64 tmp = *(uint64 *)lsnChar & (uint64)0x0000ffffffffffff; N>>В том то и дело, что в обратном. А то по времени долго работает предыдущий кусок кода, а как соптимизировать без понятия.
ТС>и сильно долго работает в релизной сборке?
Здравствуйте, na1s, Вы писали:
N>Ну вызовов очень много это и дает такой результат
Если интерпретация данных как uint64 работает (с выравниванием и алиасингом проблем нет), просто даёт неправильный порядок, я бы попробовал интерпретировать их как два uint32 (или один uint64 на x64) и переставил бы в них байты через << >> и &, типа (i & 0xFF << 24) | (i& 0xFF00 << 8) | ...
N>Это вариант и другие подобные не совсем корректен, так как захватывает чужие 2 байта, что может привести к SIGSEGV.
N>Имхо, ускорить тут можно только переписав на асме.
Если руки не кривые, а скорость очень нужна -- не приведет. Здесь проблема в другом, что порядок иной получается.
Здравствуйте, navrocky, Вы писали:
N>Это вариант и другие подобные не совсем корректен, так как захватывает чужие 2 байта, что может привести к SIGSEGV.
Возможная некорректность несколько шире.
К чтению байт со следующей страницы памяти не приведёт, если выравнивание num.numChar хотя бы 4.
А если этого выравнивания нет, то код может быть некорректен уже из-за выравнивания.
Ещё, uint64 может не являться корректным алиасом