Это проблема. Видеокарта, действительно, юзается, мягко говоря, не на все деньги. Процессор, наоборот, на все, но только одно ядро. Об этом уже шла речь в комментариях.
Ну на самом деле по поводу приоритетов здесь не всё так однозначно. Для игр, например, попугаи имеют не менее определяющее значение, чем предсказуемость поведения "стандартных" шаблонов на разных платформах и архитектурах. Возможно, как раз производительность ставится во главу угла, а однозначность поведения идёт важным приятным бонусом.
Как я уже сказал, в проекте мы std не используем. По сравнению с nstl удобнее в плане гибкости, в плане быстродействия преимуществ особых нет, только, если в nstl нет откровенного косяка, а они там встречаются. У меня есть планы провести отдельное небольшое сравнение нескольких реализаций stl с eastl, тогда смогу ответить более предметно. Но их результатам сравнений, имхо, можно доверять.
Масштабно заменять nstl, на котором построен проект, на eastl нет смысла. Долго, очень багоопасно, профит, возможно, и будет, но есть сомнения, что грандиозный. Из того, что сравнивал, собственный nstl::hash_map при обработке нанонапильником оказался практически аналогичным eastl::hash_map, местами чуть быстрее. Правда пришлось масштабно перепилить итерирование, сильно отставало из-за кривой реализации.
Если же говорить именно о std::stl, то у EA есть же много сравнений, там прирост местами очень значительный. Мы просто не используем std. Сейчас у нас гибрид из nstl и eastl. Что касается самого eastl, безусловно, очень гибкий инструмент в критичных к производительности проектах. Однозначно, must have.
Ваша картинка даже лучше бы подошла. )))
Ответ на первый вопрос, очевидно, следует из названия статьи. Ну а второй отпадает, ввиду ответа на первый.
Это проблема. Видеокарта, действительно, юзается, мягко говоря, не на все деньги. Процессор, наоборот, на все, но только одно ядро. Об этом уже шла речь в комментариях.
Ну компилятор VS2010 находится в тех же условиях, однако, он не увидел, что от обёртки можно избавиться.
Ну на самом деле по поводу приоритетов здесь не всё так однозначно. Для игр, например, попугаи имеют не менее определяющее значение, чем предсказуемость поведения "стандартных" шаблонов на разных платформах и архитектурах. Возможно, как раз производительность ставится во главу угла, а однозначность поведения идёт важным приятным бонусом.
Как я уже сказал, в проекте мы std не используем. По сравнению с nstl удобнее в плане гибкости, в плане быстродействия преимуществ особых нет, только, если в nstl нет откровенного косяка, а они там встречаются. У меня есть планы провести отдельное небольшое сравнение нескольких реализаций stl с eastl, тогда смогу ответить более предметно. Но их результатам сравнений, имхо, можно доверять.
Масштабно заменять nstl, на котором построен проект, на eastl нет смысла. Долго, очень багоопасно, профит, возможно, и будет, но есть сомнения, что грандиозный. Из того, что сравнивал, собственный nstl::hash_map при обработке нанонапильником оказался практически аналогичным eastl::hash_map, местами чуть быстрее. Правда пришлось масштабно перепилить итерирование, сильно отставало из-за кривой реализации.
Если же говорить именно о std::stl, то у EA есть же много сравнений, там прирост местами очень значительный. Мы просто не используем std. Сейчас у нас гибрид из nstl и eastl. Что касается самого eastl, безусловно, очень гибкий инструмент в критичных к производительности проектах. Однозначно, must have.