>Потому что в последние несколько десятков лет стали известны сотни NP-полных задач, вплоть до задачи об оптимальном алгоритме для игры в сапёра. Достаточно решить хоть одну из этих задач, чтобы все они оказались решены. И тем не менее, несмотря на все усилия тысяч людей, никаких продвижений в сторону создания алгоритмов для этих задач пока не наблюдается.
>… на правдоподобность гипотезы n2 указывал тот факт, что метод умножения «в столбик» известен не менее четырёх тысячелетий (например, этим методом пользовались шумеры), и если бы был более быстрый метод умножения, то он, вероятно, уже был бы найден. Однако, в 1960 году Анатолий Карацуба[3][4][5][6] нашёл новый метод умножения двух n-значных чисел
>скорость обработки упадёт, так как int32 отлично в регистр 32-битного процессора влазит, а 128 бит — уже не очень.
загнать 32-битное значение в регистр — тоже не один опкод, вобщемто.
сделать сопроц или добавить в arm или mips парочку 128-битных регистров специально для IP — вполне возможное решение.
и вообще, алгоритмы роутинга совершенно не обязательно будут настолько деревянными, чтобы гонять двоичный поиск и одну 128-битовую маску по огромным таблицам.
>Не вводить TCO из-за того, что плохо написанный, но синтаксически корректный код может порождать баги? Это тоже бред.
"...in the kernel we have a pretty strict «no regressions» rule, and that if
people depend on interfaces we exported having side effects that weren't
intentional, we try to fix things so that they still work unless there is a
major reason not to"
>Другой подход заключается в том, что на одной стороне отношения хранится список ключей сущностей другой стороны.
>Это полезно, когда количество хранимых элементов заведемо ограничен
то же самое касается и отношений child-parent. если повесить много чайлдов, при чем активно обновляющихся, на одного парента — будет ой.
>На фоне нынешних рассуждений о том, «справится ли мой телефон/калькулятор/часы с проигрыванием HD-видео» отошел на задний план интересный исторический факт: немногим более 10 лет назад проблемой была даже не скорость декодирования видео (теплый ламповый MPEG декодировался тогда отдельными аппаратными декодерами;
так в нормальных программно-аппаратных решениях оно аппаратно и сейчас декодируется. гонять видекодеки на MCU — это как раз мерзостные веяния виндовса и интеля.
>как вообще у Андроида с поддержкой двухядерных процев?
а при чем тут вообще андроид?
линупс умеет SMP на второй тегре, при чем с включением/отключением ядер на ходу.
AFAIK, каждое android-приложение запускает новый инстанс ява-машины, так что линуксовый шедулер их распихивает по разным ядрам. вот про использование обоих ядер одним приложением — мне не понятно.
вторая тегра с напрочь убитым PM, включенными двумя ядрами mcu, выкрученной на полную катушку яркостью и рабочим вайфаем спокойно работает 3-4 часа от батарейки 10V/2200mAh.
>… на правдоподобность гипотезы n2 указывал тот факт, что метод умножения «в столбик» известен не менее четырёх тысячелетий (например, этим методом пользовались шумеры), и если бы был более быстрый метод умножения, то он, вероятно, уже был бы найден. Однако, в 1960 году Анатолий Карацуба[3][4][5][6] нашёл новый метод умножения двух n-значных чисел
ru.wikipedia.org/wiki/Умножение_Карацубы
загнать 32-битное значение в регистр — тоже не один опкод, вобщемто.
сделать сопроц или добавить в arm или mips парочку 128-битных регистров специально для IP — вполне возможное решение.
и вообще, алгоритмы роутинга совершенно не обязательно будут настолько деревянными, чтобы гонять двоичный поиск и одну 128-битовую маску по огромным таблицам.
"...in the kernel we have a pretty strict «no regressions» rule, and that if
people depend on interfaces we exported having side effects that weren't
intentional, we try to fix things so that they still work unless there is a
major reason not to"
>Это полезно, когда количество хранимых элементов заведемо ограничен
то же самое касается и отношений child-parent. если повесить много чайлдов, при чем активно обновляющихся, на одного парента — будет ой.
так в нормальных программно-аппаратных решениях оно аппаратно и сейчас декодируется. гонять видекодеки на MCU — это как раз мерзостные веяния виндовса и интеля.
два кило сам девайс, плюс еще три — аккумуляторы.
а при чем тут вообще андроид?
линупс умеет SMP на второй тегре, при чем с включением/отключением ядер на ходу.
AFAIK, каждое android-приложение запускает новый инстанс ява-машины, так что линуксовый шедулер их распихивает по разным ядрам. вот про использование обоих ядер одним приложением — мне не понятно.
читайте мой коммент полностью. 3-4 часа там из-за очень жестких условий.
в штатных условиях — где-то восемь и есть.
>вся проблема современной автономной электроники в АКБ
вся проблема современного чего угодно — в тупых мудаках. в данном случае, в тех, что писали драйвера для моей уютненькой тегры.
>считаю, что в них надо инвестировать, а не в новые аппаратные платформы и мегагерцы…
вы хорошо разбираетесь, идите на место директора той же нвидии, наведите порядок.
вторая тегра с напрочь убитым PM, включенными двумя ядрами mcu, выкрученной на полную катушку яркостью и рабочим вайфаем спокойно работает 3-4 часа от батарейки 10V/2200mAh.
без доков, сериал консоли, жтага и с одним образцом железа, который еще и нельзя убить? да, проще простого, блин!