AMD или Intel а так-же бренд memory - страница 42
Вы упускаете торговые возможности:
- Бесплатные приложения для трейдинга
- 8 000+ сигналов для копирования
- Экономические новости для анализа финансовых рынков
Регистрация
Вход
Вы принимаете политику сайта и условия использования
Если у вас нет учетной записи, зарегистрируйтесь
Если говорить именно о SSD (а не просто о USB Flash Drive'ах или различных SD/MMC/CF и т.п.), то современные контроллеры планируют операции записи таким образом, чтобы равномерно распределить нагрузку на все ячейки. Т.е. даже если будет все время перезаписываться один и тот же файл - то ячейки будут почти всегда разные. Так что даже ресурса в ~10 000 циклов (для MLC) хватит очень надолго.
В частности Intel для своих SSD М-серии гарантирует, что накопитель будет способен записывать до 100Гб в день на протяжении 5 лет. Правда гарантия на них "всего" 3 года, но и 100Гб в день на тестировании у нас в ближайшее время вряд ли будет.
Что касается скорости обращения к ЛЮБЫМ (большим/маленьким) файлам, то современные SSD могут уступать ЛЮБЫМ СОВРЕМЕННЫМ HDD исключительно на линейных (последовательных) операциях. Но на таких операциях их скорости и так за глаза. В то же время при случайном доступе (основной "тормоз") даже серверные "15-тысячники" не способны к ним хоть сколько-то приблизиться по скорости. Ну а время доступа вообще отличается на порядки! То же самое по количеству операци ввода-вывода в секунду.
Так что единственный сдерживающий фактор - цена.
Ого как подробно...спасибо за лик без - не знал) Краем глаза читал об этом, но таких глубоких познаний не имею... Спасибо, может теперь без страха стану подкапливать на SSD =)
кстати, судя по обзорам в первых eee PC стояли SSD полное г... так что по скорости и качеству они вообще по-мойму всему уступали....
Протестировал ноут. Intel Mobile Core 2 Duo P8600 @ 2.4 GHz, cache 3072 KB L2, DDR2 4GB PC-6400
Тест скрипта 44,99 с, оптимизация 201 с, по тикам 29:46
При терминале в RAM будет 45,14, оптимизация 185 с, и 29:38 по тикам.
to Olga_trader. При тестировании пользовался прогой SuperSpeed RamDisk 9.0.1.0 - первое, что попалось в руки. В обоих случаях создавал диск на 800 Mb, так как тестер создает историю заранее. 1 год примерно равен 524 Mb. Для 5 лет уже 2.5 гб плюс папка history, которая у меня уже раздулась до 1.85 гб и еще надо оставить оперативки самому терминалу и винде 3-4 гб. Итого 8 гб. Прирост производительности от этих действий сомнителен, а комфортной работы с этим хозяйством все равно не получится.
Если на моем атлончике запустить сразу 2 терминала, то тест по минутам будет 188с и 166с - выбираем больший результат. По тикам 1:23:24 и 1:18:23 (было 1:09:06 на одном ядре) - не хватило RAM и комп стал активно пользоваться хардом.
На ноуте оптимизация по минутам 113с и 96с, по тикам 20:26 и 16:48.
Ага, Imp120, внес тест ноута в таблицу.
Если на моем атлончике запустить сразу 2 терминала, то тест по минутам будет 188с и 166с - выбираем больший результат. По тикам 1:23:24 и 1:18:23 (было 1:09:06 на одном ядре) - не хватило RAM и комп стал активно пользоваться хардом.
На ноуте оптимизация по минутам 113с и 96с, по тикам 20:26 и 16:48.
Вот тут я не понял. Какие результаты оставить в таблице? И как так получилось, что запуск двух терминалов улучшает результаты?
Imp120, кстати, вот заметил, что Ваш ноут и мой десктоп по табличным характеристикам очень близки. И результаты получились близкими (Ваш пошустрее получился, но ненамного).
Mathemat, извините я не точно выразился. Я разделил оптимизацию на два терминала. 102 цикла в одном и столько же в другом. Значения второй переменной в первом были 1 и 4, а во втором 7 и 10. Думал будет в 2 раза быстрее, а получилось в 1.5 ) Просто наводит на размышления, что при равной цене оптимизация быстрее будет на двух компах, чем на одном, но мощном.
Быстрее, бип-бип, будет, если разработчики закончат бип-бип страдать и сделают нормальный многопотоковый тестер. А то, бип-бип, приходится терминалы как бип-бип размножать, чтобы ядра задействовать.
И ведь что характерно, основной проблемой задействования многоядерности у всех считается плохая распараллеливаемость алгоритма. Тестер - идеально распараллеливается, чем мы и дебильно занимаемся, запуская копии. Но это - у всех, а не у наших дорогих разработчиков! У них другая проблема - судя по реакции - квалифицированные кадры. ООП, ясен пионер, важнее! (Кстати, ни одного опубликованного кода на 5-ке с применение ООП - все процедурные!)
Пардон - вот уже 20 часов идет процесс оптимизации, вот и дергаюсь.
Есть у меня такая дурацкая и наивная гипотеза, что разработчики именно это и пытаются сделать с тестером. Кнопочка тестера стратегий до сих пор отключена, а это ведь неспроста...
Есть у меня такая дурацкая и наивная гипотеза, что разработчики именно это и пытаются сделать с тестером. Кнопочка тестера стратегий до сих пор отключена, а это ведь неспроста...
Оптимизм - суть бодрое, жизнеутверждающее мировоззрение.
Щаз! По этому поводу было сказано неоднократно и однозначно - не будет.
Вначале разработчики тоже говорили, что наследования не будет.
И что в индюках не будет объектов.
А не так ведь вроде получается...
P.S. Ну ведь истину глаголешь: тестер (точнее, оптимизатор) распараллеливается проще всего. Интересно, а можно ли этим процессом управлять - т.е. задавать напрямую, как раскидывать наборы параметров по ядрам?
Дай-то Б-г...
С объектами же, вернее с их отсутствием в индикаторах, понятно - идиотизм ситуации был очевиден.
Кста, новый билд уже позволяет?