LINUX.ORG.RU

Производительность; илитный запил оптимальных реализаций и основы матчасти.

 , , ,


20

17

Поглядел я тут на пацанов и увидел прогресс в их глазах. Поэтому я решил вести тут свой бложик, в котором я буду толкать матчасть, разбирать/разрушать всякие мифы и легенды, а так же их обсуждать с пацанами. Банить меня не надо - тут всё будет очень культурно.

Это будет формат для самых маленьких, где я буду показывать как что-то пилится по-пацаночке. Его задача - на примерах пересказать штеудмануал тем, кому лень его читать, но кто очень любит спорить про код, перфоманс и матчасть. Ну и просто интересные наблюдения.

Изначально я хотел написать про то: что такое бесплатные вычисления на примере is_range() + сумма елементов массива, но тут выявилась смешная особенность, поэтому пока без is_range().

Начнём с простого - сумма елементов(float) массива. Как написать её быстро? Обычный крестопоц сделает так:

auto summ = accumulate(begin(vec), end(vec), 0.)

Этот код выдаёт 5.6GB/s(мы всё бенчим в л1д 32килобайта массив). Казалось бы, если бы мы слушали всяких «гуру», которые нам говорят: accumulate() - оптимизирован, «ты что умнее создатели stl"а?», «конпелятор умнее тебе - сам всё делает оптимально», «руками что-то делать слишком сложно и не нужно» - то мы бы там и остались с этими 5.6ГБ, но мы пойдём дальше и поймём почему так, и является ли это тем, что намн ужно.

Но посмотрев на код - он не векторизован:

	addq	$4, %rdx
	vcvtss2sd	-4(%rdx), %xmm2, %xmm2
	vaddsd	%xmm2, %xmm1, %xmm1

Почему? Патамучто это основная флоатпроблема: Он не ассоциативен - флоат не имеет в себе точных представлений всех чисел входящих в диапазон его «представления» т.е. порядкопроблемы.

Поэтому конпелятор НЕ ВЕКТОРИЗУЕТ флоат по умолчанию, ну никак. Даже такую банальщину.

Для решения этих проблем - есть ключик -funsafe-math-optimizations, который входит в -ffast-math, который кладёт на точность при вычислениях. Добавив его мы получаем уже 44.9GB/s.

Но теперь мы получаем ещё одну проблему - надо думать: «как бэ сунуть эту ключик не повредив там, где этот ключик не нужен».

Поэтому ноцанам, которые хотят быстро и не хоятт рандомных жоп из-за тупости конпелятора - пишут всё руками. Допустим на той же сишке это пишется так:

double memadd_autovec(buf_t buf) { //5.609465GB/s, либо 44.969652GB/s с ffast-math
  float * it = buf_begin(buf), * end = buf_end(buf), summ = 0.;
  do {
    summ += *it++;
  } while(it != end);
  return summ;
}

double hsumf(__v8sf v) {
  return (v[0] + v[1] + v[2] + v[3] + v[4] + v[5] + v[6] + v[7]);
}

double memadd_vec(buf_t buf) { //45.652002GB/s и класть на ffast-math
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
  do {
    summ += *it++;
  } while(it != end);
  return hsumf(summ);
}

Т.е. разницы никакой нет, кроме нужной нам реализации горизантального сложение вектора. Когда я говорил пацану: «векторную сишку для написания быстрого кода юзать намного проще, чем плюсы» - поцан нипонимэ, да и любые пацаны скажут - ну дак с -ffast-math оба выдают по 45гигов - нахрен эта сишка нужна?

А вот зачем:

double memadd(buf_t buf) { //132.878440GB/s
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
  do {
    summ += *it++;summ += *it++;summ += *it++;summ += *it++;
  } while(it != end);
  return hsumf(summ);
}

Это называется пацанский анролл копипастой, а вот заставить конпелятор нормально что-то разанролить очень сложно.

Если бы мы слушали всяких «гуру», которые нам вещают: «анрол говно и не нужен» - мы бы так и седели с 45-ю гигами, а так мы сидим с 132.878440GB/s. Т.е. анролл нам дал немного не мало ~300%.

Но основная мысль, которую толкают всякие «гуру» - это не надо следить за тактами/считать такты и прочее. Но мы о5 сделаем наоборот и посмотрим что будет.

Т.к. наш юзкейс упирается на 99% в throughput и дёргается одна инструкция, то нам достаточно просто считать теоретическую производительность для моего камня. 4.5(частота камня)*8(т.е. у нас камень с avx, то там вектор 32байта, либо 8флоатов.)*1(throughput нашей инструкции - в данном случае vpaddps из интел мануала). Т.е. 36гигафлопс, либо ~144гига. Т.е. мы сняли овер 90% теоретической производительности - остальные 10% у нас ушли в наши циклы, всякие горизонтальные суммы вектора и прочее, ну и конечно же чтение данных из кеша.

Но самое смешное - на моём хасвеле умножение имеет throughput 0.5 - т.е. на хасвеле умножение быстрее сложения. Это новая забористая трава у интела.

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

Поэтому очень смешно слушать, когда какие-то пацаны говорят: «float point имеет такую же производительность как и инты» - нет, оно имеет такоу же производительность лишь по причине того, что на штеуде инты тормазят так же, как и float.

И чтобы окончательно в этом убедится - мы взглянем на fma(вариации умножения со сложением/вычитанем), которые имеют throughput 0.5 - да, да - на хасвеле умножение+сложение в 2раза быстрее просто сложения. Это уже не просто трава - это что-то принципиально новое.

У целочисленного сложения же throughput 0.5 и казалось бы, если мы поменяем в нашей функции float на int - у нас будет сложение работать в 2раза быстрее, но это не так. Оно выдаёт те же 130гигов, а почему?

Вообще у камня есть такая фича, допустим у нас:

add $1, %reg0//вот тут инструкция add залочит регистр reg0
add $1, %reg0//а эта инструкция уйдёт в лок до особождения предыдущей инструкцией регистра reg0

Чтобы такой жопы небыло - есть специальная фича:

add $1, %reg0//lock reg0
add $1, %reg0//И тут вместо того, чтобы уйти в лок - камень вместо reg0 даёт инструкции любой свободный регистр.

Эта фича называется прееименование регистров, либо как-то так - мне лень гуглить.

Дак вот штука в том, что фича работает через жопу. Мне лень читать мануал и искать почему так, но штука в том, что она ограничивает throughput. На умножении и целочисленном сложении она огранивает throughput c 0.5 до 1.

И вот я решил заюзать сложении через fma:

__v8sf fmaadd(__v8sf a, __v8sf b) {
  return _mm256_fmadd_ps(_mm256_set1_ps(1.), a, b);// a + b * 1. == a + b.
}

double memadd_fma(buf_t buf) {
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
  do {
    summ = fmaadd(summ, *it++);
  } while(it != end);
  return hsumf(summ);
}

Но меня ждала жопа: 27.347290GB/s, причем не анролл и ничего не помогал. Я уж подумал, что мануал наврал, но позже до меня допёрло: у неё latency 5тактов и ((4.5×8)÷5)×4 ~= 29гигов - т.е. я получаю производительность с её latency, но какой жопой оно так?

Потом я вспомнил, что гцц гинерит анрольный код вида:

add $1, %reg0
add $1, %reg0
//а не
add $1, %reg0
add $1, %reg1

Т.е. на неё вообще не работает переименовывание регистров - и инструкции постоянно в локе. Я это проверил и оказался прав. Ну и я написал такой мемадд:


__v8sf fmaadd(__v8sf a, __v8sf b) {
  return _mm256_fmadd_ps(_mm256_set1_ps(1.), a, b);
}

inline void fma_10way_finality(__v8sf * cache, __v8sf * it, __v8sf * end) {
  switch(end - it) {
    case 8:
      *(cache + 7) = fmaadd(*(cache + 7), *(it + 7));
      *(cache + 6) = fmaadd(*(cache + 6), *(it + 6));
    case 6:
      *(cache + 5) = fmaadd(*(cache + 5), *(it + 5));
      *(cache + 4) = fmaadd(*(cache + 4), *(it + 4));
    case 4:
      *(cache + 3) = fmaadd(*(cache + 3), *(it + 3));
      *(cache + 2) = fmaadd(*(cache + 2), *(it + 2));
    case 2:
      *(cache + 1) = fmaadd(*(cache + 1), *(it + 1));
      *(cache + 0) = fmaadd(*(cache + 0), *(it + 0));
    case 0:
      break;
    default: error_at_line(-1, 0, __FILE__, __LINE__, "bad_aligned");
  }
}

double memaddfma_10way(buf_t buf) {
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = (__v8sf){};
  __v8sf * cache = (__v8sf[10]){{}};
  uint64_t i = 0;
  while((it += 10) <= end) {
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    *(cache + i) = fmaadd(*(cache + i), *(it - i - 1));++i;
    i = 0;
  }
  fma_10way_finality(cache, (it - 10), end);
  summ = (*(cache + 0) + *(cache + 1) + *(cache + 2) + *(cache + 3) +
	  *(cache + 4) + *(cache + 5) + *(cache + 6) + *(cache + 7) +
	  *(cache + 8) + *(cache + 9));
  return hsumf(summ);
}

Пришлось хреначить финалити, ибо тут «анролл» на 10, а почему на 10 - для максимального throughput"а - надо, чтобы каждый каждый регистр юзался через 5тактов - т.е. 10регистров.

И вся эта порятнка нужна для борьбы с тупостью конпелятора.

Это уже: 214.167252GB/s(раельно там в районе 250 - просто мой бенч говно). 107 гигафлопс на ведро. Из теоретических 144, но тут уже влияние кеша. Причем 50+ из которых выкидываются и просто бесплатные.

Теперь вопрос к пацанам - что нам дадут эти гагфлопсы, когда у нас будет массив не 32килобайта, а 32мегабайта? Зачем нужно выживать максимум, когда скорость памяти отсилы 20-30гигабайт и нам хватит даже С++ кода с ffast-math?

Ну и призываются упомянутые мною пацаны: mv - этот тот експерт, что вещал про «руками переименовывать регистры не надо» и «анрол ваще ненужен», emulek вещал про ненужность счёта тактов, и не понимал что такое «беслпатно», AIv - не понимал в чем проблема плюсов, ck114 - так же не понимал в чем проблема плюсов.

Бенчи: https://gist.github.com/superhackkiller1997/606be26fa158ef75501d - вроде я там ничего не напутал.

P.S. - не выпиливайте пж, пусть пацаны «нужно» или «не нужно». Мне интеерсно. Ну и там рекомендации пацанов.

Отсыпь.

И с возвращением!

Deleted ()

Очень занимательное чтиво. Но практическая польза от такой оптимизации IRL стремится к 0 (бывают, конечно, исключения, но они встречаются крайне редко).

ddos3 ()

Carb_blog

мыщьх, перелогинься.

devl547 ★★★★★ ()

Отличный пост об идиотизме преждевременной оптимизации, было интересно и познавательно, пиши ещё.

aedeph_ ★★ ()

Да, SIMD - это круто. Intel уже лет 15 об этом говорит.

tailgunner ★★★★★ ()

emulek вещал про ненужность счёта тактов, и не понимал что такое «беслпатно»,

понимаешь в чём дело: мне не нужно считать сумму 32768 float'ов. IRL алгоритмы несколько сложнее. Ну и упираются они обычно НЕ в процессор.

А за статью — спасибо. Про анрол я знаю, но вот у меня оно просто не нужно.

emulek ()
Ответ на: комментарий от devl547

Норм штука, шаблонную бы ещё обёртку над ней (впрочем, легко макросами нагенерить), и вообще огонь

yoghurt ★★★★★ ()
Ответ на: комментарий от yoghurt

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

aedeph_ ★★ ()

Да ладно, что все на него наехали? Велосипедирование полезно. Carb_blog, что про GPU (CUDA, а лучше openCL, ибо от производителя не зависит) скажешь? Может на эту тему что-нибудь напишешь? Тогда больше пользы будет, про openCL информации, да ещё на русском - днём с огнём не найти.

peregrine ★★★★★ ()
Ответ на: комментарий от ddos3

Очередной эксперт-пхпист, который ошибся разделом/темой? Я конечно понимаю, что пхпист ничего из того, о чем он так ответственно заявняет не знает/понимает, но всё же - это основа реализации всех числодробилок.

Тыж пхпист? Дак вот, это и основа всех функций работающих со строками.

Carb_blog ()
Ответ на: комментарий от yoghurt

Он работает почти идеально - максимум сумм работает так же. И то только на icc, ибо без инлайна оно будет глотать пыль. Я поставил качатся 5гигов твоей проприетарщины - позже проверю на icc.

Carb_blog ()

Складывать? Массив флоатов? Я-то думал за такое сразу убивают в приличных конторах... Но я не про это.

Что, собственно говоря, доказывает твой пост? Что ты успешно смог разменять алгоритмическую сложность на производительность? Ну, дык, не ты первый...

Что высокоспециализированное решение будет в клочки рвать общее? Опять, никто в этом и не сомневается.

У тебя радости полные штаны, что ты смог осилить интеловский мануал? Ну, поздравляю...

А теперь главный вопрос. Что именно тебе дадут полученные «знания»? Они сделают тебя умнее, красивее, лучшим программистом? Нет, нет и нет!

Ну, и тесты твои — сплошная синтетика. Компьютер не является сферическим процессором + кешем + памятью, висящей в вакууме. В реальной жизни все упрется в производительность периферии. И решение данной проблемы намного более нетривиально, чем дрочка вприсядку на интеловские мануалы.

Macil ★★★★★ ()
Ответ на: комментарий от Macil

Складывать? Массив флоатов? Я-то думал за такое сразу убивают в приличных конторах...

Раскрой тему - почему нельзя складывать массив float?

tailgunner ★★★★★ ()
Ответ на: комментарий от Macil

Складывать? Массив флоатов? Я-то думал за такое сразу убивают в приличных конторах... Но я не про это.

Меня пхписты из контор не интересуют.

Что, собственно говоря, доказывает твой пост? Что ты успешно смог разменять алгоритмическую сложность на производительность? Ну, дык, не ты первый...

«алгоритмическую сложность» - с этим в пхп.

Что высокоспециализированное решение будет в клочки рвать общее? Опять, никто в этом и не сомневается.

Это общий случай, причем тут «общее»? Ты просто так побалаболить пришел?

У тебя радости полные штаны, что ты смог осилить интеловский мануал? Ну, поздравляю...

Только вот ты его не осилил, причем тут радости. Сказать по существу чёесть?

А теперь главный вопрос. Что именно тебе дадут полученные «знания»? Они сделают тебя умнее, красивее, лучшим программистом? Нет, нет и нет!

Они мне дадут то, благодаря чему я тебя и похожих тебе уничтожаю в ноль. В этом суть. Давай посоревнуемся?

Ну, и тесты твои — сплошная синтетика.

Это не синтетика, ты реально не отличаешь синтетику от реальности? Зачем ты говоришь на темы, в которых ты ничего не понимаешь?

Специально для балабола поясню - синтетика - это голый цикл, который бенчит какой-то кусок кода не привязанный ни к чему:

void bench(uint64_t len) {
  float a, b;
  do {
    a *= b;
  } while((len -= 1));
}

Это синтетика, из которой убирается всё, кроме бенча собственно умножения, в данном случае. Мой же пример не синтетика.

Компьютер не является сферическим процессором + кешем + памятью, висящей в вакууме.

Является, просто от этого тебя отделяет твой пхп и руки.

В реальной жизни все упрется в производительность периферии.

Какой-такой перифирии - ты примеры мне давай, что это за мистическая перифирия? Хотя да, тыж пхпист у тебя там субд и ИО.

И решение данной проблемы намного более нетривиально, чем дрочка вприсядку на интеловские мануалы.

Ну давай примеры своих проблем. Вообще-то мануал. Мне так смешно - я там специально упомянул мануал, о котором ты даже не знал.

Зачем ты к нему привязался?

Carb_blog ()
Ответ на: комментарий от aedeph_

Отличный пост об идиотизме преждевременной оптимизации, было интересно и познавательно, пиши ещё.

А что ты знаешь об оптимизации, кроме этой копипасты из какой-то книженки про «преждевременную»? Ничего, а если ничего, то зачем ты про это балаболишь?

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

Подумай над вопросом, авось поймёшь зачем это надо.

Carb_blog ()
Ответ на: комментарий от peregrine

что про GPU

А что про него писать? Мне лень с ним копаться. Мне не интересно копаться в проприетарщине. Максимум, что мне было интересно - это запил двигла для хасвелловского гпу, но спеков нет, а beignet нихрена не работает. Как-нибудь потом, когда допилят хоть чтобы оно работало.

openCL

Это ужасно.

Тогда больше пользы будет, про openCL информации, да ещё на русском - днём с огнём не найти.

Пользы не будет. Я не вижу смысла в openCL. Это не для велосепидостов.

Carb_blog ()
Ответ на: комментарий от Carb_blog

Это общий случай, причем тут «общее»?

Перенеси это «общее» решение хотя бы на другой компилятор. Про другой процессор я даже не заикаюсь.

Ну давай примеры своих проблем.

Обработать хотя бы 100к пакетов в секунду на интеловском железе.

я там специально упомянул мануал, о котором ты даже не знал

Почему ты так решил? Инетловские мануалы читал каждый школьник, интересующийся профильной тематикой.

Это мне смешно... Прочитал парочку мануалов, и решил что всех надурил? Категоричность суждений (достойная самого Полграфа Полграфовича) с головой выдает в тебе человека видевшего слишком много побед, и слишком мало факапов. Будь бы тематика из области ФП, я бы с готовностью применил убойную идиому «мамкин борщ», но увы...

Проблема в том, что дерьмо за такими «молодыми и горячими» приходится убирать ежедневно, в том числе и мне. Но, к сожалению, это имеет небольшое отношение к мелкому мирку интеловских мануалов.

Macil ★★★★★ ()

Ну вот может же и общаться, и выкладки приводить когда захочет :) Даже как человеку далекому от перформанса и др. почитать интересно, однозначный респект.

А ты не пробовал пилить штуку, которая из входящей задачи типа такой, пусть не на сях, а на к-л псевдокоде, быстро тестит параметры камня и исполнения и выдает подобный же код? Такой запил требует времени и нексилого знания конкретной платформы, почему бы его не автоматизировать, вложив скилл в продукт, ведь в этом суть всего кодинга — получать больше, делая меньше. Или это не поддается анализу и формализации?

arturpub ★★ ()

То есть тебя по теме оптимизаций тогда опустили мордой в говно, и сейчас ты пытаешься доказать, что типа поумнел? Дохловатое доказательство вышло.

Pavval ★★★★★ ()
Ответ на: комментарий от Macil

Перенеси это «общее» решение хотя бы на другой компилятор.

А что мешает? Там валидный сишный код.

Про другой процессор я даже не заикаюсь.

Зачем мне другой процессор? Там есть общий случай для всех процессоров с avx"ами.

Обработать хотя бы 100к пакетов в секунду на интеловском железе.

Ну давай, выкатывай юзкейс. ЧТо за пакеты - их сигнатура, что значит «Обработать»? Яж не проч тебя в лужу вогнать.

Почему ты так решил? Инетловские мануалы читал каждый школьник, интересующийся профильной тематикой.

Ну какбэ я этого не вижу, отписались 10человек, включая тебя - до сих пор никто не ответил на вопрос. И да, я этот мануал не читал.

Это мне смешно... Прочитал парочку мануалов, и решил что всех надурил? Категоричность суждений (достойная самого Полграфа Полграфовича) с головой выдает в тебе человека видевшего слишком много побед, и слишком мало факапов. Будь бы тематика из области ФП, я бы с готовностью применил убойную идиому «мамкин борщ», но увы...

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

Проблема в том, что дерьмо за такими «молодыми и горячими» приходится убирать ежедневно, в том числе и мне. Но, к сожалению, это имеет небольшое отношение к мелкому мирку интеловских мануалов.

Мануалов, ты хочешь посоревноваться в качестве запила? Ну давай, давай - я жду.

Ещё раз - ты сказал пакеты - выкатывай ТЗ - посоревнуемся.

Какой уверенный в себе нулёвый пхпист пошел, прям брыжит «скиллом».

Carb_blog ()
Ответ на: комментарий от Pavval

Ладно, я не буду описывать пацанам наши встречи - меня забанят, но всё же - ты же мне осилишь показать «тебя по теме оптимизаций тогда опустили мордой в говно»?

Конкретно и с цитатками - где кто и как?

Carb_blog ()
Ответ на: комментарий от arturpub

А ты не пробовал пилить штуку, которая из входящей задачи типа такой, пусть не на сях, а на к-л псевдокоде, быстро тестит параметры камня и исполнения и выдает подобный же код? Такой запил требует времени и нексилого знания конкретной платформы, почему бы его не автоматизировать, вложив скилл в продукт, ведь в этом суть всего кодинга — получать больше, делая меньше. Или это не поддается анализу и формализации?

В этом особого смысла нет. Да я пилил всякие брутфорсы для подбора оптимального анролла, обхода памяти и прочее, но мне проще написать всё с нуля.

Суть кодинга - иметь скилл, чтобы всё занимало у тебя времени в районе нуля. Вот тут пацаны сказали про ipp. По времени заюз ipp у меня занимает времени столько же, сколько я потратил на запил этой байды на fma. И то такие случае бывают редко.

Обычно этого хватает:

double memadd(buf_t buf) { //132.878440GB/s
  __v8sf * it = buf_begin(buf), * end = buf_end(buf), summ = {};
  do {
    summ += *it++;summ += *it++;summ += *it++;summ += *it++;
  } while(it != end);
  return hsumf(summ);
}

Это пишется за 5секунд и имеет «идеальную» производительность. В этом нет ничего сложного. Столько же времени ты потратишь на написание своего «псевдокода».

Carb_blog ()
Ответ на: комментарий от Carb_blog

не буду описывать пацанам наши встречи - меня забанят

ЩИТО? И с кем ты там встречался?

ты же мне осилишь показать «тебя по теме оптимизаций тогда опустили мордой в говно»?

Я тебе еще что-то показывать должен?

Pavval ★★★★★ ()
Ответ на: комментарий от ritsufag

Да этот вроде косит под него, номер не тот после супелблаблабла на гитхабе. Тем более тот совсем был школотой, а этот уже на первый курс тянет

vertexua ★★★★☆ ()
Ответ на: комментарий от peregrine

Что именно ужасно в OpenCL?

Всё. Основная ужасность - универсальность. Ладно там было бы только гпу, но туда тянут всё. Мне этого не нужно. Подходы к запилу на цпу/гпу различны и «вездеработать» это будет так, что лучше бы оно вообще не работало.

Мне не нравится эта отстранённость от железа, какой-то шейдерстайл протухший десятки лет назад. Это популизм.

Carb_blog ()
Ответ на: комментарий от vertexua

Так последнее его пришествие вроде около года назад было, не? Летом. Вот, прошел год, он за это время закончил первый курс, прочел маны и пришел сюда.

NeverLoved ★★★★★ ()
Ответ на: комментарий от Pavval

ЩИТО? И с кем ты там встречался?

Поиск в помощь, я тебе ещё что-то доказывать должен?

Я тебе еще что-то показывать должен?

Т.е. ты вякнул, а когда тебя спросили «почему?» - ты слился? Ок, это так в стиле балаболов. Ну не пичалься - завтра за партой ты встретишься с друзъяшками, с которыми такое канает.

Мб ты всётаки попытаешься аргументировать свой выхлоп? Радуйся, что я тебе не занулю - тут всё будет культурно.

Модераторы, вот как с такими говорить «культурно»? Т.е. он клевещит, обзывается, сливается на раз-два, а мне даже слова плохого сказать нельзя?

Carb_blog ()

Чё вы на посона наезжаете? Молодец, пытливый ум! Как пойдёт на работу и столкнётся с задачами, не умещающимися в L1d, то посидит ещё денёк-другой-третий, и разберётся, чё к чему.

Ну а что речами дерзкий, так это или гопники вылечат, или с возрастом само пройдёт.

mv ★★★★★ ()
Ответ на: комментарий от mv

Ты уже показал своё осведомлённость: слившись тут Производительность памяти., и тутНужно ли учить ассемблер? (комментарий) и где-то ещё было - лень искать.

Твоё невежество и тотальная некомпетентсность настолько поражают. Ты так же бойко балаболил в темах по сыслкам выше, яж тебе привел конкретно пруфцы констатирующий факт того, что ты обделался в штанишки.

Как пойдёт на работу и столкнётся с задачами, не умещающимися в L1d, то посидит ещё денёк-другой-третий, и разберётся, чё к чему.

О да, ну я другого от балабола не ожидал. А причем тут l1d? Ты так же обделался и с memcpy.

Мне интересно, ты реально не понимаешь всей бредовойсти своих оправданий? Я конечно понимаю - балаболить ты всегда мастер, а когда к стеночки подперают ты уже не боец, аргументы кончаются и идут детсадовские отговорки. «я тамг де-то что-то делал, а потом у теня что-то сломаось, ноя не знаю что и типа ты поэтому неправ».

Ладно, я уж не буду тебя напрягать, а то вдруг невыдержит твой «камень» такой невероятной нагрузки, всётаки тут не балаболить, а хоть чуть подумать надо - ты представляешь себе, что ВНЕЗАПНО, в более сложном юзкейсе ВНИМАНИЕ!! БОЛЬШЕ 1-й операции, нежданчик да?

Давай ещё проще, то наверное слишком сложно для тебя. Имея одно сложение в 1гигафлопс, добавляя в функцию ещё 4сложения - мы получаем, ВНИЗАПНО, тот же 1гигафлопс, а вот прочитать из памяти требудется уже не 1, а 1/5 гигфлопса.

Имея же функцию на 50+гигфлопс на одном сложение - добавляя туда ещё 4сложения - мы получаем теже 50гигафлопс, а вот прочитать надо не 50, а 10. А 10гигфлопс - это уже скорость оперативы.

Я надеюсь ты осилишь это понять, если нет - скажи, я ещё раз объясню.

Carb_blog ()
Ответ на: комментарий от Carb_blog

Если ты утрудишься пройти по своим же ссылкам и пролистнуть дальше, то увидешь, что мудрый mv объяснил залётному дурачку, где он ошибается. С memcpy так вообще эпичный фейл получился.

Извини, а этот дурачок - не ты ли? Тогда только гопникам выправлять, возраст не исправит.

mv ★★★★★ ()
Ответ на: комментарий от tailgunner

Раскрой тему - почему нельзя складывать массив float?

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

no-such-file ★★★★★ ()

Что нужно прочитать чтобы понять всё это? Накидай список литературы, пожалуйста.

anonymous ()
Ответ на: комментарий от ritsufag

кококок анскильный петушара

Уже было?

чуть выше :)

false ★★★★★ ()
Ответ на: комментарий от vertexua

номер не тот после супелблаблабла на гитхабе

а какой должен быть? я этого царька запомнил ником, который на гитхабе

false ★★★★★ ()

Рад видеть тебя! Спасибо за ликбез, ты как всегда, впереди меня. Это нужно, потому что:

Раньше я ориентировался на тебя, теперь брожу как по пещере с фонариком.

anonymous ()
Ответ на: комментарий от Carb_blog

это основа реализации всех числодробилок

И? Много сегодня пишут числодробилок на голом CPU?

Тыж пхпист?

С чего ты это взял?

основа всех функций работающих со строками

Примеры из libc приведешь? Или libc тоже пхписты писали?

ddos3 ()
Ответ на: комментарий от no-such-file

результат будет не всегда адекватный, т.к. очень быстро накопится ошибка

«Царям» программирования это не важно. Главное - чтобы код был «четким и резким», т.е. главное - подр*чить на flops`ы.

P.S. Быстродействие, конечно, очень важно в «числодробилках», но в таких приложениях зачастую на первый план выходят немного другие факторы, которые аффтар не освещает в своих высерах заметках :)

htower_ ★★ ()

Поэтому я решил вести тут свой бложик

Запили тег пооригинальние, по которому можно посты отслеживать.

mkam ()

Поэтому я решил вести тут свой бложик

История успеха: супехаккиллер теперь СМИ!

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от no-such-file

Раскрой тему - почему нельзя складывать массив float?

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

Это ты о проблеме всех операций с плавающей точкой (и тогда это капитанство), или о том, что функция hsumf накапливает ошибку быстрее, чем стандартный accumulate, или о чем-то совсем другом?

tailgunner ★★★★★ ()
Ответ на: комментарий от Carb_blog

Там валидный сишный код.

Этот «валидный сишный код» даже более ранней версией gcc не собирается.

tailgunner ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.