Какой язык/платформу Вы рекомендовали бы для зависящего от ЦП приложения?
этот код поможет вам объединить все данные в вашем массиве:
let test = [
{
subsets:
[
{
start: '0020', end: '007F',
},
{
start: '0020', end: '007G',
},
{
start: '0020', end: '007G',
},
],
fontFormat: 'woff2',
src: 'estPath1/',
},
{
subsets:
[
{
start: '0020', end: '007F',
},
{
start: '0020', end: '007G',
},
{
start: '0020', end: '007G',
},
],
fontFormat: 'woff',
src: 'estPath2/',
},
{
subsets:
[
{
start: '0020', end: '007F',
},
{
start: '0021', end: '007G',
},
{
start: '0020', end: '007G',
},
],
fontFormat: 'woff',
src: 'estPath3/',
}
];
var final = [];
for(var i = 0; i < test.length; i++) {
var object = {subsets : [] , webFontList: []};
object.subsets = test[i].subsets;
object.webFontList.push({fontFormat: test[i].fontFormat, src: test[i].src});
for(var j = i +1; j < test.length; j++) {
if(_.isEqual(test[i].subsets, test[j].subsets)) {
object.webFontList.push({fontFormat: test[j].fontFormat, src: test[j].src});
test.splice(j, 1);
}
}
final.push(object);
}
console.log("final object is : ", final);
20 ответов
Только быть полным: первое, что нужно сделать состоит в том, чтобы собрать данные профиля, и вторая вещь сделать, рассматривают Ваши алгоритмы. Я уверен, что Вы знаете это, но они должны быть #included в любое программирующее производительность обсуждение.
Быть прямым о Вашем вопросе "Может, переключаясь на справку ASM?" ответ, "Если Вы не знаете ответ на это, затем вероятно, нет". Если Вы не очень знакомы с архитектурой ЦП и ее входами и выходами, маловероятно, что Вы сделаете значительно лучшее задание, чем хорошая оптимизация компилятор C/C++ на Вашем коде.
Следующий вопрос для создания - то, что значительные ускорения в коде (кроме алгоритмических улучшений) почти наверняка прибудут из параллелизма, не линейных увеличений. Настольные машины могут теперь бросить 4 или 8 ядер в задачу, которая имеет намного больше потенциала производительности, чем немного лучший генератор кода. Так как Вы довольны C/C++, OpenMP является в значительной степени легкой задачей; это очень просто в использовании для параллелизации циклов (очевидно, необходимо наблюдать несомые на цикле зависимости, но это - определенно "самый простой параллелизм, который мог возможно работать").
Сказав все это, качество генерации кода действительно варьируется между компиляторами C/C++. Компилятор Intel C ++ хорошо расценивается по его качеству оптимизации и имеет полную поддержку не только для OpenMP, но и для других технологий, таких как Стандартные блоки Поточной обработки.
Перемещаясь в вопрос того, какие языки программирования могли бы быть еще лучше, чем C++, ответ будет "языками программирования, которые активно продвигают / упрощают понятие параллелизма и параллельного программирования". Erlang является королевой бала в том отношении и является "горячим" языком прямо сейчас, и большинство людей, заинтересованных программированием производительности, обращает по крайней мере некоторое внимание на него, поэтому если Вы хотите улучшить свои навыки в той области, Вы могли бы хотеть проверить его.
Вероятная маленькая справка:
Оптимизация 64-разрядных программ
Отладка и оптимизация программ OpenMP мультипотока
Если Вы чувствуете, что Вы оптимизируете свой код к точке, нет никакого улучшения, увеличьте свой ЦП. Это может быть сделано на различных платформах. Один я разрабатываю с, Appistry. Несколько ссылок:
http://www.appistry.com/resource-library/index.html
и можно загрузить бесплатно продукт отсюда:
http://www.appistry.com/developers/
Я работаю на Appistry, и мы сделали много установок для задач, которые были зависящими от ЦП путем распространения работы за 10-е или 100's машин.
Надежда это помогает, - Brett
Linux
Переключение на Linux может помочь при разделении его вниз только к частям, Вам на самом деле нужно.
Сначала выведите вывод. Затем, если это - с такой скоростью, как это может возможно быть, не идя в ASM, пусть будет так. Но думая необходимо перейти к ASM, предполагает, что Вы знаете то, что заставляет его замедлиться, и я поставлю пончик, который Вы предполагаете.
2 очевидных ответа на "Зависящий от ЦП": 1. Используйте больше ЦП (ядро) s 2. Используйте что-то еще.
Используя 2 потока вместо 1 сократит время, проведенное максимум на 50%. В сравнении C++ к ASM редко дает Вам 5% (и для новичка программисты ASM, это часто-5%!). Некоторые проблемы масштабируются хорошо и могут извлечь выгоду из 8 или 16 ядер. Такие аппаратные средства являются все еще симпатичной господствующей тенденцией, поэтому посмотрите, падают ли Ваши проблемы в той категории.
Другое решение состоит в том, чтобы бросить более специализированные аппаратные средства в задачу. Это могло быть векторной единицей Вашего ЦП - рассматривающий Windows=x86/x64, это будет разновидностью SSE. Другим видом векторных аппаратных средств является современный GPU. GPU также имеет свою собственную шину памяти, которая довольно быстра.
Для современных процессоров, изучая ASM возьмет Вас долгое время. Далее, со всеми различными версиями SSE вокруг, Ваш код закончится очень иждивенец процессора.
Я делаю довольно большую зависящую от ЦП работу и нашел, что разница между компилятором и g C++ Intel ++ обычно не является настолько большой (самое большее приблизительно 15%), и нет никакого измеримого различия между Mac OS X, Windows и Linux.
Вы оказываетесь перед необходимостью оптимизировать свой код и улучшать Ваш алгоритм вручную. Нет никакой "волшебной волшебной пыли", которая может сделать существующий код, что намного быстрее я боюсь.
Если Вы еще не имеете, и Вы заботитесь о производительности, НЕОБХОДИМО выполнить код через хорошего профилировщика (лично, мне нравятся kcachegrind и valgrind на Linux или Акула на Mac OS X. Я не знаю то, что хорошо для окон, я боюсь).
На основе моего прошлого опыта существует очень хороший шанс, Вы найдете, что некоторый метод берет 95% Вашего процессорного времени, и некоторое простое изменение или добавление кэширования сделают крупное улучшение Вашей производительности. На подобной ноте, если некоторый метод только берет 1% Вашего процессорного времени, никакой объем оптимизации не собирается получить Вас что-либо.
Для альтернативного подхода Вы могли изучить Распределенные вычисления, которые кажутся, что могли удовлетворить Вашим потребностям.
Я предлагаю, чтобы Вы заново продумали свой алгоритм, или возможно еще лучше, Ваш подход. С другой стороны, возможно, то, что Вы пытаетесь вычислить просто, занимает много вычислительного времени. Вы рассмотрели для создания, это распределило так, это может работать в каком-то кластере? Если Вы хотите сфокусироваться на чистой оптимизации кода путем представления Ассемблера для внутренних циклов затем часто, которые могут быть очень выгодными (если Вы знаете то, что Вы делаете).
Если Вы придерживаетесь C++ на компиляторе Intel, смотрите на компилятор intrinsics (полная ссылка здесь). Я знаю, что VC ++ имеет схожую функциональность, и я уверен, что можно сделать то же самое с gcc. Они могут позволить Вам в полной мере воспользоваться параллелизмом, встроенным в Ваш ЦП. Можно использовать MMX, SSE и инструкции SSE2 улучшить производительность в известной степени. Как другие сказали, Вы являетесь, вероятно, выглядящими лучше всего в алгоритме сначала.
Во-первых, фигура, если можно изменить алгоритм как предложенный S.Lott.
Принятие выбора алгоритма корректно, Вы могли бы посмотреть шаблоны доступа к памяти, если у Вас есть много данных, Вы обрабатываете. Для большого количества приложений перемалывания чисел в эти дни, они связываются шиной памяти, не ALU. Я недавно оптимизировал некоторый код, который имел форму:
// Assume N is a big number
for (int i=0; i<N; i++) {
myArray[i] = dosomething(i);
}
for (int i=0; i<N; i++) {
myArray[i] = somethingElse(myArray[i]);
}
...
и преобразованный это для сходства с:
for (int i=0; i<N; i++) {
double tmp = dosomething(i);
tmp = somethingElse(tmp);
...
myArray[i] = tmp;
}
...
В данном случае это уступило о 2x ускорение.
Иногда можно найти библиотеки, которые оптимизировали реализации алгоритмов, о которых Вы заботитесь. Часто времена они будут делать многопоточность для Вас.
Например, переключение от LINPACK до LAPACK получило нас 10x, увеличение скорости LU-факторизации / решает с хорошей библиотекой BLAS.
Как lobrien сказал, Вы не дали нам информации, чтобы сказать Вам, если оптимизировано рукой, код ASM помог бы..., что означает, что ответ, вероятно, "еще".
Вы выполнили свой код с профилировщиком?
Вы знаете, является ли код медленным из-за ограничений процессора или ограничений памяти?
Вы используете все свои доступные ядра?
Вы определили какие-либо алгоритмы, которые Вы используете, которые не являются O (1)? Можно ли получить их к O (1)? В противном случае, почему нет?
Если Вы сделали все это, сколько контроля Вы имеете над средой, в которой работает Ваша программа? (по-видимому, много при размышлении о переключении операционных систем), можно ли отключить другие процессы, отдать ли процессу самый высокий приоритет и т.д.? Что относительно того, чтобы просто найти машину с быстрым процессором, большим количеством ядер или большей памятью (в зависимости от того, что Вы ограничиваетесь на),
И вперед и вперед.
Если Вы уже сделали все это и больше, конечно, возможно, что Вы доберетесь до точки, где Вы думаете, "Интересно, могли ли эти немного строк кода прямо здесь быть оптимизированы лучше, чем блок, что я смотрю на в отладчике прямо сейчас?" И в той точке можно спросить конкретно.
Удачи! Вы решаете проблему, которую это интересно решить.
Рука оптимизируя Ваш ASM кодирует по сравнению с тем, что C++ может сделать для Вас, редко экономически эффективно.
При выполнении чего-нибудь, что Вы можете к алгоритму от традиционного алгоритмического представления, и Вы также устранили излишки, то можно или быть СОЛЬ, или можно рассмотреть оптимизацию программы с аппаратной точки зрения.
Например, любое время, Вы следуете за указателем вокруг "кучи", Вы оплачиваете огромную стоимость из-за неудачных обращений в кэш, возможно подкачки страниц, и т.д., который все влияние, переходящее прогнозы. Большинство программистов (даже C гуру) склонно смотреть на ЦП с функциональной точки зрения, а не что происходит негласно. Иногда реорганизация памяти, например, путем "выравнивания" или вручную выделения памяти для установки на той же странице может получить ОГРОМНЫЕ ускорения. Мне удалось добраться 2X ускорения на обходах графика только путем выравнивания моих структур.
Это не вещи, которые Ваш компилятор сделает для Вас, так как они основаны на Вашем высокоуровневом понимании программы.
Попробуйте Фортран 77 - когда дело доходит до вычислений все еще ничто не бьет дедушку языков программирования. Кроме того, попробуйте его OpenMP для использования в своих интересах нескольких ядер.
Лично я посмотрел бы на языки, которые позволяют Вам использовать в своих интересах параллелизм наиболее легко, если это не полностью non-parallelisable ситуация. Способность к устройству, повышаяющему характеристики, некоторые дополнительные ядра и добирается (если возможный!) почти линейное улучшение может быть намного более экономически эффективным, чем отжимание дополнительного небольшого количества процента эффективности.
Когда дело доходит до распараллеливания я полагаю, что функциональные языки часто рассматриваются как лучший способ пойти, или Вы могли посмотреть на OpenMP для C/C++. (Лично, как управляемый парень языка, я посмотрел бы на библиотеки для Java/.NET, но я вполне понимаю, что не у всех есть те же предпочтения!)
В то время как просто переключение на asm не принесет пользы, так как Intel C ++ Compiler, вероятно, лучше в оптимизации, чем Вы, можно попробовать одну из следующих опций:
- Попробуйте компилятор, который параллелизирует Ваш код, как компилятор VectorC.
- Попытайтесь переключиться на asm с интенсивным использованием MMX, 3DNow!, SSE или безотносительно соответствий Ваши потребности (и Ваш ЦП). Это принесет больше пользы, чем чистый asm.
- Можно также попробовать GPGPU, т.е. выполнить значительные части алгоритма на GPU вместо ЦП. В зависимости от Вашего алгоритма это может быть существенно быстрее.
Править: Я также второй подход профиля. Я рекомендую AQTime, который поддерживает компилятор Intel C ++.
Переключение на ASM не собирается помогать многому, если Вы не очень хороши в нем и/или имеете определенную стандартную программу критического пути, которая Вы знаете, что можно добиться большего успеха. Как несколько человек отметили, современные компиляторы просто лучше в большинстве случаев в извлечениях выгоды из кэширования/и т.д. чем кто-либо может сделать вручную.
Я предложил бы:
- Попробуйте другой компилятор и/или различные опции оптимизации
- Выполните утилиту покрытия/анализа кода и фигуру, где критические пути, и работа над оптимизацией критических путей в коде
C++ должен смочь дать Вам очень около самой лучшей производительности из кода, таким образом, я не рекомендовал бы переключить язык. В зависимости от приложения Вы можете добираться, лучшая производительность во много системах кода/процессора с помощью нескольких распараллеливают, как другое предложение.
Это - всегда алгоритм, редко язык. Вот моя подсказка: "в то время как я работаю над улучшением алгоритма".
Тонкая настройка не может быть достаточно.
Рассмотрите радикальные изменения в алгоритме. Необходимо устранить обработку, не заставляют обработку пойти быстрее. Преступник часто является "поиском" - цикличное выполнение через данные, ища что-то. Найдите способы устранить поиск. Если Вы не можете устранить его, замените линейный поиск некоторым поиском по дереву или картой хеша некоторого вида.
Поскольку Oregonghost уже подсказал - компилятор VectorC мог бы помочь. Это действительно не параллелизирует код, хотя, вместо этого можно использовать его для усиления на наборах расширенной команды как mmx или sse. Я использовал его для самых строго ограниченных во времени частей в механизме визуализации программного обеспечения, и это привело к ускорению приблизительно 150%-200% на большинстве процессоров.