У меня 55 дюймовая модель этого телевизора. Тонкая рамка экрана — конечно выглядит красиво, и сильно уменьшает размер самого телевизора — но имеет большой недостаток прочности! Нужно быть очень аккуратным при перемещении телевизора, и особенно транспортировке при переезде. Например, если положить телевизор горизонтально — его нельзя поднимать за один конец — он тупо гнется как резиновая палка. Нужно поднимать и переносить вдвоем.
Будте осторожны!
А так — великолепный телевизор с лучшей 3D картинкой из всех что я видел!
Думаю, в случае с Firefox 4, реч идёт о здравом ограничении количества FPS на отметке 100 FPS. Для себя отметил, что тест грузит процессор на 0%, и сколько экземпляров его не запускай, загрузка все равно в районе нулевой.
Я думаю amc имеет ввиду, что спецификакия 775 сокета на протяжении своего существования претерпела изменения, которые не позволяют новые Core процессоры, вставлять в ранние 775 материнские платы. Если мне не изменяет память, изменения были в системе питании процессоров. И скорее всего Интер тогда не изменила номер сокета по причине того, что старые процессоры все еще можно было вставлять в новые сокеты 775.
Ехал, ехал, не доехал до офиса буквально пару километров — попал в ужастную пробку (авария впереди, неожиданные ремонтные работы). Припарковался, разложил байк из запаски, сел поехал в офис! :)
Прикольно. Главное в реализации сохранить компактность, маленький вес и удобный механизм складывания.
Вот стоит у меня в системном блоке GF 9800 GTX+. Кто незнает, это фактически GF 250, который был рожден идеей маркетологов NVIDIA в свете перехода на систему именования моделей 2xx.
И вы знаете, я все таки думаю что апргейд на 5770, а лучше сразу на 5850 или 5870 очень даже имеет смысл.
И дело не в DX11 (у меня ОС даже DX10 не поддерживает), а в очень успешном сочетании энергопотребления и производительности, энергопотребления в простое и тишине кулера. За это инженерам AMD просто поклон.
Если в конкрентном случае, памяти требуется настолько много, сколько не может быть установлено (а точнее говоря — это выходит за рамки бюджета), а следовательно вариант не может привести к успеху, то он просто вычеркивается.
Но это никак не влияет на общую методику оценки эффективности решения.
Уважаемый автор. Ваша задачка — конкурсную/олимпиадную? Почему спрашиваю, потому что именно в таких задачах дают условие и ограничивают по памяти и/или времени.
С практической точки зрения заказчика на какой то программный комплекс, или отдельный компонент — нет такого понятия как ограничение по памяти. Зато есть — требование по времени выполнения, и затрачиваемым ресурсам.
С временем выполнения все ясно. Для многих программных систем — время отклика критично (хотя бы например ПО для форекса).
Затрачиваемые ресурс — это не что иное как количество $, которое программная система требует для ее запуска (стартовые затраты) и функционирования. Функциональные затраты могут считаться на каждый объем выполенной работы, либо по периодам времени — ежедневные, ежемесячные.
Эффективность системы тем выше, чем меньше затрат она требует для своей реализации и работы.
Теперь, давайте возмем некую конкрентную задачку, типа вашей, и попробуем посчитать затраты каждого из вариантов решения — варианта А, который требует много памяти, и варианта Б, который требует много… времени? хотя нет, я бы сказал — требует много вычислительных ресурсов (так как делает большее количество операций).
Для варианта А — чтобы успевать решать задачу в определенном диапазоне входных данных, нам надо докупить памяти. При этом дальнейшие вычисления будут идти просто, так как те значения, которые уже были высчитаны, уже хранятся в памяти, и процессор легко может их получить по адресу ячейки.
Для варианта Б — нам скорее всего надо будет покупать более мощный процессор. Просто потому что мы теперь делаем больше операций, и дабы сэкономить память, не храним, а заново вычисляем промежуточные значения.
На моей практике, вариант А часто оказывается более предпочтительнее — потому что память обычно дешевле дополнительной процессорной мощности, и потому что повторные вычисления промежуточных значений обычно требует больше энергии, чем чтение этих значений из памяти.
Соотвественно, система которая затрачивает больше энергии на алгоритм (а каждый киловатт энергии стоит денег) будет требовать больших операционных расходов. :)
В оригинальной игре, насколько я помню, на высоких уровнях скорость такая, что еле успеваеш кошелку двигать. Не представляю, как на тач скрине можно будет успевать. Ведь скорость реакции гораздо ниже, чем на обычные механические кнопочки.
А мы говорим о проверке вводимых данных с точки зрения валидации данных, или с точки зрения бизнесс правилах приложения?
Например, отклонение ввода слишком простых паролей — это требование уровня бизнесс правил, конкрентнее — правил безопасности принятых в системе.
А вот отклонение ввода слишком длинных имен — это требование продиктованное технической реализацией. Например в базе данных под некое поле отведено всего N байт.
И говоря о проверке данных, я бы сказал, что она должна быть настолько жесткой, чтобы обеспечивать уверенность в том, что в дальнейшем мы имеем дело с проверенными данными по определенным параметрам — размер, формат, другие характеристики.
Говоря проще, если я делаю поле в базе 20 байт, я проверяю что данные пришли не больше. Если я добавляю в дальнейшем код, который делает разбор или анализ сожержимого, я добавляю проверку во входной точке, что данные соотвествуют моим предположениям.
А для меня спектрум, это не только первые игры, а и первый опыт программинга на асме путем кодирования команд в коды по книжечке, записывания на листик кодов, и ввода в спектрум :-)
А еще первые попытки собрать спекктрум самому — после того как купленный сгорел, я с паяльником и схемами в руках, собирал свой персональный спектрумчик — получилось. Народ, это не передать, как было приятно самому спаять спектрум!
А игры, тоже конечно супер. Всего списка и не перечислить.
Это если Вы совсем чуть чуть передвинули мышку, и там просто не набралось 6000 кадров. А вообще у вас похоже частота между мышкой и компом — 6000Hz. Это USB? Хорошая частота, аж слишком хорошая… :-)
Вопрос не в скорости передачи данных между мышкой и компом. Вопрос в скорости обработки микрухой данных от сенсора. К примеру данные микросхема может обрабатывать 1000 раз в секунду, а передавать 200 (частота PS/2).
Ну а про то, что USB может работать в режиме 1000Hz… вообще первый раз слышу. Хорошо, давайте проведем тест. Есть специальная программа, называется Mouse Rate Checker (http://tscherwitschke.de/download/mouserate.zip). Она определяет реальную частоту передачи данных с мыши. Пожалуйста, запустите программу, подвигайте мышкой в центре ее окна, и продемонстрируйте нам всем, эти базнословные 1000Hz. (Мои 200Hz можно увидеть тут img512.imageshack.us/my.php?image=rate.png).
Ну и еще хочу сказать о парочке важных для геймеров вещей, которые редко упоминают рекламные статьи наподобие таковой на THG. Это — развесовка мышки, и предельная высота сканирования.
Развесовка — это балланс веса передней и задней части мышки. Оптимальная развесовка, это когда вы держите мышку в рабочем положении, поднимаете мышку двумя пальцами (которыми вы обычно делаете «перекат» — поднятие и перенос мышки на коврике) и мышка висит ровно, не ныряя носом вперед и не проваливаясь задом на ковер.
Предельная высота сканирования — это высота, на которую вам надо поднять мышку, чтобы сделать перекат, на которой сенсор не будет замечать изменения положение мышки. Если высота сканирования слишком большая (типичная проблема лазерных мышей, в отличии от классической оптики) — вам прийдется слишком высоко поднимать мышку, чтобы перекатить ее на другую часть ковра. В играх наподобие quake, где нужно много крутиться, нужно часто перекатывать мыш, и если приходится ее высоко поднимать — это во первых неудобно, во вторых медленно.
Скажите, какая микруха там стоит? Скажите мне наименование процессора, а я посмотрю техническую документацию на нее — какой поток данных она может обрабатывать. (Подавляющее большинство мышей сделаны на стандартных микросхемах, потому как отдельно разрабатывать микросхему и запускать ее в производство для одной единственной модели мышки — мышка бы «золотая» по цене вышла). Ибо обработать 5600 реальных dpi с высокой частотой (скажем 200 кадров/в секунду) — это очень нехилая вычислительная мощность нужна, а чем выше мощность микрухи, тем больше энергии она будет потреблять. Ну а сабжевая мышко то — батарейковая ;)
В любом случае — оптическое разрешение выше 800 dpi практически не имеет смысла. Куда более важный параметр, скорость обработки, либо другими словами частота сканирования. Чем выше частота, тем плавнее мышка отслеживает незначительные передвижения, и тем более резкие движения мышка сопобна уследнить без «вертолетов».
Ну насколько я помню, для про гейминга у этих безпроводных мышек есть один минус — большой вес. Ну а про 5600 dpi я практически на 100% уверен — это эмуляция.
Будте осторожны!
А так — великолепный телевизор с лучшей 3D картинкой из всех что я видел!
img823.imageshack.us/img823/6145/testaod.png
Конфигурация:
i7 2600K @ 4.5 Ghz
Win 7 SP1 (32bit)
Firefox 4.0 RC1
Прикольно. Главное в реализации сохранить компактность, маленький вес и удобный механизм складывания.
И вы знаете, я все таки думаю что апргейд на 5770, а лучше сразу на 5850 или 5870 очень даже имеет смысл.
И дело не в DX11 (у меня ОС даже DX10 не поддерживает), а в очень успешном сочетании энергопотребления и производительности, энергопотребления в простое и тишине кулера. За это инженерам AMD просто поклон.
Если в конкрентном случае, памяти требуется настолько много, сколько не может быть установлено (а точнее говоря — это выходит за рамки бюджета), а следовательно вариант не может привести к успеху, то он просто вычеркивается.
Но это никак не влияет на общую методику оценки эффективности решения.
С практической точки зрения заказчика на какой то программный комплекс, или отдельный компонент — нет такого понятия как ограничение по памяти. Зато есть — требование по времени выполнения, и затрачиваемым ресурсам.
С временем выполнения все ясно. Для многих программных систем — время отклика критично (хотя бы например ПО для форекса).
Затрачиваемые ресурс — это не что иное как количество $, которое программная система требует для ее запуска (стартовые затраты) и функционирования. Функциональные затраты могут считаться на каждый объем выполенной работы, либо по периодам времени — ежедневные, ежемесячные.
Эффективность системы тем выше, чем меньше затрат она требует для своей реализации и работы.
Теперь, давайте возмем некую конкрентную задачку, типа вашей, и попробуем посчитать затраты каждого из вариантов решения — варианта А, который требует много памяти, и варианта Б, который требует много… времени? хотя нет, я бы сказал — требует много вычислительных ресурсов (так как делает большее количество операций).
Для варианта А — чтобы успевать решать задачу в определенном диапазоне входных данных, нам надо докупить памяти. При этом дальнейшие вычисления будут идти просто, так как те значения, которые уже были высчитаны, уже хранятся в памяти, и процессор легко может их получить по адресу ячейки.
Для варианта Б — нам скорее всего надо будет покупать более мощный процессор. Просто потому что мы теперь делаем больше операций, и дабы сэкономить память, не храним, а заново вычисляем промежуточные значения.
На моей практике, вариант А часто оказывается более предпочтительнее — потому что память обычно дешевле дополнительной процессорной мощности, и потому что повторные вычисления промежуточных значений обычно требует больше энергии, чем чтение этих значений из памяти.
Соотвественно, система которая затрачивает больше энергии на алгоритм (а каждый киловатт энергии стоит денег) будет требовать больших операционных расходов. :)
Не соотвествует условию. Написано заменить один символ. Про добавить ничего не сказано ;)
Да, просто проверка, и всё, я уверен что данные не превышают максимальный размер.
Например, отклонение ввода слишком простых паролей — это требование уровня бизнесс правил, конкрентнее — правил безопасности принятых в системе.
А вот отклонение ввода слишком длинных имен — это требование продиктованное технической реализацией. Например в базе данных под некое поле отведено всего N байт.
И говоря о проверке данных, я бы сказал, что она должна быть настолько жесткой, чтобы обеспечивать уверенность в том, что в дальнейшем мы имеем дело с проверенными данными по определенным параметрам — размер, формат, другие характеристики.
Говоря проще, если я делаю поле в базе 20 байт, я проверяю что данные пришли не больше. Если я добавляю в дальнейшем код, который делает разбор или анализ сожержимого, я добавляю проверку во входной точке, что данные соотвествуют моим предположениям.
А еще первые попытки собрать спекктрум самому — после того как купленный сгорел, я с паяльником и схемами в руках, собирал свой персональный спектрумчик — получилось. Народ, это не передать, как было приятно самому спаять спектрум!
А игры, тоже конечно супер. Всего списка и не перечислить.
Ну а про то, что USB может работать в режиме 1000Hz… вообще первый раз слышу. Хорошо, давайте проведем тест. Есть специальная программа, называется Mouse Rate Checker (http://tscherwitschke.de/download/mouserate.zip). Она определяет реальную частоту передачи данных с мыши. Пожалуйста, запустите программу, подвигайте мышкой в центре ее окна, и продемонстрируйте нам всем, эти базнословные 1000Hz. (Мои 200Hz можно увидеть тут img512.imageshack.us/my.php?image=rate.png).
Ну и еще хочу сказать о парочке важных для геймеров вещей, которые редко упоминают рекламные статьи наподобие таковой на THG. Это — развесовка мышки, и предельная высота сканирования.
Развесовка — это балланс веса передней и задней части мышки. Оптимальная развесовка, это когда вы держите мышку в рабочем положении, поднимаете мышку двумя пальцами (которыми вы обычно делаете «перекат» — поднятие и перенос мышки на коврике) и мышка висит ровно, не ныряя носом вперед и не проваливаясь задом на ковер.
Предельная высота сканирования — это высота, на которую вам надо поднять мышку, чтобы сделать перекат, на которой сенсор не будет замечать изменения положение мышки. Если высота сканирования слишком большая (типичная проблема лазерных мышей, в отличии от классической оптики) — вам прийдется слишком высоко поднимать мышку, чтобы перекатить ее на другую часть ковра. В играх наподобие quake, где нужно много крутиться, нужно часто перекатывать мыш, и если приходится ее высоко поднимать — это во первых неудобно, во вторых медленно.
Скажите, какая микруха там стоит? Скажите мне наименование процессора, а я посмотрю техническую документацию на нее — какой поток данных она может обрабатывать. (Подавляющее большинство мышей сделаны на стандартных микросхемах, потому как отдельно разрабатывать микросхему и запускать ее в производство для одной единственной модели мышки — мышка бы «золотая» по цене вышла). Ибо обработать 5600 реальных dpi с высокой частотой (скажем 200 кадров/в секунду) — это очень нехилая вычислительная мощность нужна, а чем выше мощность микрухи, тем больше энергии она будет потреблять. Ну а сабжевая мышко то — батарейковая ;)
В любом случае — оптическое разрешение выше 800 dpi практически не имеет смысла. Куда более важный параметр, скорость обработки, либо другими словами частота сканирования. Чем выше частота, тем плавнее мышка отслеживает незначительные передвижения, и тем более резкие движения мышка сопобна уследнить без «вертолетов».
Уж поверте 'екс-' q3 геймеру ;-)
PS: MX510 — наше все :-)