процессоры, 2 или 4 ядра, capture nx2

[Gun]

Почему-то мне кажется, что "32-разрядный Oracle в UNIX-имплементации" - это не "общий случай"

А что же это ? Что такое "в общем случае" ?

[another]

С форума IXBT



Скажите Capture поддерживает больше двух потоков и будет ли заметно улучшение скорости от такой замены проца.

сам Капчуре не поддерживает, но на 4х ядернике все таки скорость работы выше ( сам менял дуо на квад , частоты ядра - одинаковые в плюсе - в батче на 10-15 % выигрыш). А вот фотошоп сильно выигрывает от 4х ядерности = до 30% + общая "гладкость" системы

я в шоке !!!

хотя если подумать - в батче - тут начинает играть быстродействие системы в целом в частности диски. так что возможно все не так плохо.

[Gun]

я в шоке !!!

хотя если подумать - в батче - тут начинает играть быстродействие системы в целом в частности диски. так что возможно все не так плохо.

А я в шоке от того, что двукратное увеличение мощности дает лишь 30% прирост производительности. КПД не такой, как у паровоза, но тоже недалеко ушел...

[MadFox]

я в шоке от того, что двукратное увеличение мощности дает лишь 30% прирост производительности

это давно так..... двухкратное увеличение частоты - около 30%-50% прибавления производительности, рейд-0 на двух дисках вместо одного - 50% производительности, добавление второго проца в систему - 25%-50% производительности. причем эти законы выведены еще в 60 или 70 годах того века.

[Gun]

это давно так..... двухкратное увеличение частоты - около 30%-50% прибавления производительности, рейд-0 на двух дисках вместо одного - 50% производительности, добавление второго проца в систему - 25%-50% производительности. причем эти законы выведены еще в 60 или 70 годах того века.

Это не то что не "давно так", а это и вовсе не так и никогда так не было. Закон говорит лишь о масштабируемости в зависимости от объема параллельных вычислений (ну, или наоборот - от объема последовательных вычислений). Если речь идет о законе Амдала. Так вот масштабируемость с вышеуказанным КПД говорит о слабеньком параллелизме. Другое дело, что фотошоп не единственное хреновое приложение, а, пожалуй, лишь отражение общей незрелости параллельного программирования. В качестве иллюстрации можно посмотреть тесты масштабируемости с IXBT (http://www.ixbt.com/video3/quadcore2.shtml, <noindex>http://www.ixbt.com/divideo/cores.shtml)</noindex>. Там можно видеть совершенно различные примеры, от полного "отстоя" до вполне приличных результатов, типа 97% прироста при добавлении второго ядра. Общее же резюме говорит о том, что на сегодняшний день, в массе своей, эффективно научились использовать только 2 потока. В этой связи переход с 2-х на 4 ядра оправдан ни разу не увеличением числа ядер, а просто более совершенным устройством более нового ядра. Если, конечно, речь не идет о небольшом количестве уже хорошо сделанных прикладов. Ну и, разумеется, что все это относится к комбинации "писюк + виндоза + настольное ПО", поскольку на серверной территории с параллелизмом сильно лучше (по причинам, которые вряд ли имеют отношение к обработке фотографий).

[MadFox]

Gun, я и говорю о серверных системах, там проблемма распаралеливания потоков была решена немного раньше чем на десктопах. так вот: при добавлении второго проца SQL2000 почему-то двухкратного увеличения производительности не показывал. а вписывался как-раз в рамки 25%-50%

да и при повышении частоты проца сильно сомневаюсь что двухратную производительность вы получите....

[Gun]

Gun, я и говорю о серверных системах, там проблемма распаралеливания потоков была решена немного раньше чем на десктопах. так вот: при добавлении второго проца SQL2000 почему-то двухкратного увеличения производительности не показывал. а вписывался как-раз в рамки 25%-50%

да и при повышении частоты проца сильно сомневаюсь что двухратную производительность вы получите....

100% КПД, конечно, не бывает, а 70-80% - вполне распространенный результат.

SQL 2000, кстати, далеко не самый лучший пример серверного ПО...

[Andrey]

это давно так..... двухкратное увеличение частоты - около 30%-50% прибавления производительности, рейд-0 на двух дисках вместо одного - 50% производительности, добавление второго проца в систему - 25%-50% производительности. причем эти законы выведены еще в 60 или 70 годах того века.

Эти цифры очень сильно зависят от конкретных задач ... а говорить о средних значениях - это как о "средней температуре по госпиталю" ... к примеру, на одних задачах добавление второго процессора даст почти 100% прибавку производительности, а для других - около 0%.... Так и со всеми остальными приведенными параметрами ....



Без указания конкретного класса задач эти цифры не имеют значения ....

[Косильщик]

ок тестить так тестить ...

Ниже я привел хронометраж работы Сapture NX 2.2.0 c с вашим файлом, но на моей машине, по тем функциям что вы оговаривали выше:

Машина НР Havilion а6745fr, (полные и исчерпывающе точные характеристики вы можете посмотреть на сайте НР введя в строку поиска а6745fr, за исключением памяти - я ее сменил на Kingston HyperX PC-2-6400 CL5 800 Мгц kat.№ KHX6400D2K2/4G )

ЦП q8200 (core 2 quad 4x2,33 Ггц);

Память 8 Гб;

Видео карта Nvidia T120 ( 1Гб )

HDD "Hitachi"- 500 Гб, 400Гб- свободно.

Внешний USB диск "Iomega" с данными - 1 Тб, 425 Гб- свободно;

Установленное ПО (необходимое):

- Microsoft .NET Framework 1, Microsoft .NET Framework 2, Microsoft .NET Framework 2 SP2, Microsoft .NET Framework 3, Microsoft .NET Framework 3 SP2, Microsoft .NET Framework 3,5 SP1 со всеми хот фиксами. (Ну т.е. все версии для ХР х-64);

- Microsoft Visual C++ 2005 Redistributable, Microsoft Visual C++ 2008 Redistributable -x64 9.0.21022, Microsoft Visual C++ 2008 Redistributable -x64 9.0.30729;

- QuickTime 7.62.14.0

- Capture NX2 v. 2.2.0

- ViewNX v.1.2.2



Что имеем: файл 15 мб ( 74,1 mb temp cache)

Первичное время рендеринга (т.е. программа не имеет кэш файлов на момент открытия) - 10,46 с. У меня прога открывающая NEF по умолчанию CNX2, и это время - с момента клика по файлу. Повторный запуск NEF из уже открытой СNX2 2,46 с.

При активеном инструменте выделения по круговому градиенту время рендеринга с момента клика по файлу до полного открытия изменилось на 11,23 с. ( но ни как ни до 30 секунд как у вас!!!)

изменил параметры шарпа с 30 до 37 закрыл файл с сохранением 4.71 сек.

изменил параметры шарпа с 37 до 30 закрыл файл с сохранением 3.38 сек.

обсчет файла при изменении масштаба масштаб изменялся от fit to screen до view at 100% в обе стороны результат примерно одинаковый - десятые доли секунды, практически мгноменно.

сохранение в jpg заняло 1.15 сек. размер 6,8 мб 100% Excellent Quality + embided ICC profile



Мои выводы (как бы я решал проблему)

1 Можно попробовать освободить место для кэш фалов и по больше до 20 ГБ

2 Есть некая тенденция связанная с объемами HDD чем он больше тем быстрее работает ОС ( новизна приводов и т.п.)

3 Проверьте по списку установленного у вас ПО (с учетом х-32 или х-64) .NET Framework все ли обновления у вас есть

4 Таблетки-стероиды для CNX2 - это С++

5,6, - скорость видеокарты и процессора

7 Еще есть программа TuneUP Utilities оч. полезная прога пользую 3 год и все ошибки (а их не малои в реестре) - около 925 - она оч хорошо поправила - безболезненно! есть rescue обратный возврат действий! Да и дефрагментирует она неплохо что HDD, что реестр! Цифры у вас есть и принимать решенее теперь вам. Удачи!

[another]

отлично ! ) примного благодарен, первый результативный тест.



при четырех ядрах и значительно меньшей тактовой частоте, выигрыш порядка 30-40%

различия в тесте у меня при первичном открытии CNX был поднят (то есть время старта не учитывалось), а рез практически сходный.

по поводу бага с активным инструментом кругового выделения - имелось ввиду не открытие файл, а изменение масштаба то есть:

открываете файл, далее fit to screen затем активизируете инструмент кругового выделения (со занаком минус), выделяете некоторую область (к примеру для создания виньетирования)

и после этого жмете ctrl+alt+0 (view at 100%) - вот тут то его и скрючивает у меня (как на windows так и на маке)



с пустым местом на дисках было возможно (было такое подозрение).. вечером попытаюсь освободить побольше.

и еще вы не написали рабочее разрешение - (боюсь что время пересчета изображения при изменении масштаба сильно зависит)



вопрос

как вам живется на 64бит XP - проблем с набором ПО и его взаимодействием не испытываете?