Свежие комментарии

Title	Comment
у Интел есть намного более гибкий и удобный ArBB, для выч з	у Интел есть намного более гибкий и удобный ArBB, для выч задач самое то.
На третий день зоркий глаз заметил.... что я пускал компиля	На третий день зоркий глаз заметил.... что я пускал компилятор с --targer=sse4x2 что, собственно, и порождает код "шириной" 8.
наконец-то лёд тронулся	наконец-то лёд тронулся
Да, понял. Разница существенна, согласен.	Да, понял. Разница существенна, согласен.
И это не совсем OpenCL - оффлайн-компиляция - нет многопот	И это не совсем OpenCL - оффлайн-компиляция - нет многопоточности
Ну следов TBB я не заметил, оно же линкуется как библиотека,	Ну следов TBB я не заметил, оно же линкуется как библиотека, ничего такого нет. Просто порождает объектник или LLVM-код (бинарный) или ассемблер. Вот что умеет использовать (но я не пробовал) - это intel small vector math library или как ее там. А ассемблер - обычный такой, SSE4.2 (ну я такой просил). И объектник - обычный, линкуешься с ним и все. Т.е. если рассматривать код в примере выше, то в первом приближении он развернется в сложение 4-х элементов за раз внутри цикла путем movups xmm1,[откуда] addps xmm0,xmm1 # xmm0 - это sum (а если на самом деле, то за один цикл фигачится 8 элементов: movups xmm2,[data+i] addps xmm0,xmm2 movups xmm1,[data+i+4] addps xmm0, xmm1 # Всякие штуки с обработкой длины массива некратной 8 я опускаю, а в них весь кайф этой тулзы, выписывать их вручную всегда очень лениво.
Сходил по ссылке: - C-like language - LLVM Compiler - Попроб	Сходил по ссылке: - C-like language - LLVM Compiler - Попробую догадаться... использует TBB? OpenCL, вид слева.
Вопрос же не в легкости, а в	Вопрос же не в легкости, а в удобстве. Про Бизон все говорят, что носится удобно. Скажем, более легкая Татонка Кимберли (у меня литров на 80, сначала жена таскала, потом дочь) - лично на мой вкус, носится неудобно. Т.е. более тяжелый (скажем, на кило) но более удобный рюкзак - интегрально легче. Наверное, если в рюкзаке 20 кило, то разница меньше, чем если там 30 или 40.
Зачем бизона? Есть и легче	Зачем бизона? Есть и легче рюкзаки - не легкоходовские, а нормальные классические прочные, но легче Татонки-Бизона - тот же Акме-Нормал.
Да, если всего один блок, то	Да, если всего один блок, то имеет смысл. Но сейчас ведь говорим о переносе GPU OpenCL кода (ведь про shared из-за GPU начали говорить), на CPU, а там потоков достаточно.
В вырожденном случае, когда у	В вырожденном случае, когда у нас всего один блок в 64 потока - раскидывать по ядрам, очевидно, имеет смысл. А в невырожденном - да, надо посмотреть как работает планировщик у разных CPU OpenCL.
А зачем раскидывать блок по	А зачем раскидывать блок по разным ядрам? В задаче ведь как правило много блоков. Проще говоря, нужно относится к ядру, как к SM. Пусть потоки блока выполняются одним ядром, что я и сказал ранее ("особенно если один блок обслуживается одним ядром") Т.е. я к тому клоню, что эффективный kernel разный для разного железа и никуда от этого не деться. не, ну само собой, пусть не по этим, но тогда по другим причинам.. я всего лишь ищу позитив.
Тут какбэ другая беда. Если у	Тут какбэ другая беда. Если у нас размер блока - 64, то его раскидает по 4(8) ядрам в 8-way SIMD. Отчего начнутся всякие приколы с инвалидацией кэшей (если shared мы делаем в 32к и со всех ядер туда ходим) и так далее. Будет (относительно) плохо. Т.е. я к тому клоню, что эффективный kernel разный для разного железа и никуда от этого не деться.
Ну, по идее, если оно делает	Ну, по идее, если оно делает циклу unroll, то дальше само уже должно придумать. Кроме того, есть помянутый выше ispc, который ровно это и делает. Но мультитредность сам не умеет
Ну так я и говорю, что прагма	Ну так я и говорю, что прагма simd_is_here_Take_it_baby! , подскажет компилятору, что 4(8) соседних итераций можно сделать как одну с использованием SIMD. То есть я говорю не о векторизации simd внутри итерации, я говорю об автоматическом обьеденении нескольких итераций в simd, что-то типа OpenMP, но для simd (для простых случаев OpenCL это слишком жирно)
128k регистров на блок	128k регистров на блок (сколько есть в CC2.0) Надо учитывать, что все запрошенные регистры на блок, одновременно не нужны. На железках NVidia минимальный разумный размер блока, который выедает все регистры, это 64, поэтому я и поделил на 64minGPU_BlockSize и умножил на 8simd_threads, то есть из минимально возможных 64 потоков блока, параллельно будут исполнятся только 8(а если double, то вообще 4), то есть память под регистры для всех потоков одновременно не нужна (единственное при синхронизации внутри блока будет перетасовка - но всё в пределах L2 кэша). Поэтому и получилось 16KiB кэша под регистры для соответствия CC2.0
clInfo (AMD-шная от 2.3):	clInfo (AMD-шная от 2.3): Local memory type: Global Local memory size: 32768 т.е. банально кэш туда вписали. А в качестве размера кэша - L2 (256k). Но, конечно, kernel который хочет 48k shared + 128k регистров на блок (сколько есть в CC2.0) - пролетит немножко мимо.
Нет, там другое. Там вручную	Нет, там другое. Там вручную расписана сортировка (9 элементов) в окрестности пиксела. Это не так просто векторизовать, но можно хотя бы min/max одной инструкцией сделать. В OpenCL-случае просто 4(8) пикселов обрабатываются параллельно.
Наверное он соседние итерации	Наверное он соседние итерации цикла не смог объединить в SIMD? Можно ввести новую прагму для циклов типа unroll - simd_is_here_Take_it_baby!
Интересно, а что выдаёт	Интересно, а что выдаёт clGetDeviceInfo c CL_DEVICE_LOCAL_MEM_SIZE ? Я к тому, что локальная (shared в терминологии cuda c), вроде должна хорошо эмулироваться с помощью процессорного кэша, особенно если один блок обслуживается одним ядром. Конечно ещё надо учитывать использование регистров - по моим оценкам для соответствия CC2.0 по регистрам, нужно 4byte32768regs8simd_threadsAVX/64minGPU_BlockSize=16KiB кэша, у I7 32KiB L1 data cache, остаётся 16KiB L1 для shared, что не плохо, учитывая наличие ещё L2 и L3.
http://slickdeals.net/permadeal/53897/newegg-8gb-2x4gb-g.ski	http://slickdeals.net/permadeal/53897/newegg-8gb-2x4gb-g.skill-ddr3-1066... http://slickdeals.net/permadeal/53833/newegg-desktop-memory-6gb-3x2gb-ki... http://slickdeals.net/forums/showthread.php?t=3048045 ;) Добить памяти до максимума - самое оно. А на лаптопе очень помогает ready boost - 4х гиговый ссд воткнутый в свободный mini PCI-e слот. Даже не смотря на 8 гиг памяти. Тот же ворд на C2D LV 1.3GHz запускается за 3 секунды.
Ну я не пробовал 57x27k, пробовал 30x30k. Там время было как	Ну я не пробовал 57x27k, пробовал 30x30k. Там время было какое-то приемлемое, точно не два часа и не час.
Ну так а "баланс" я веду для	Ну так а "баланс" я веду для себя в уголке и именно как баланс, а не как движение средств.
1 действую строго по инструкции с твоей страницы http://ale	1 действую строго по инструкции с твоей страницы http://alextutubalin.livejournal.com/240280.html?view=3042968 вот такую картинку программа судя по мелькающим циферкам планирует обрабатывать 133минуты projection: +proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs width: 57324 pixel height: 27276 pixel area (top/left, bottom/right): 28.214454 83.981380, 27.697474 85.211420 xscale: 0.000021 ┬░/px, yscale: -0.000019 ┬░/px real scale: 2.102486 m/px 2 вот про это ничего не скажу 3 после апдейта фирмвари прибора до 3.0, выходной файл с 0.2.4 прекрасно в приборе видится
Ага, ясно.. Ну да, так проще,	Ага, ясно.. Ну да, так проще, только баланс будет неправильный, хотя это не принципиально. (можно виртуальными движениями под-тюнить, но особо не зачем). Но я всё же, хотя бы в моедело буду списания вносить, для себя..
Ну да, естественно.	Ну да, естественно.
Тут есть моментики 1) Странно что работает "годами", я сним	Тут есть моментики 1) Странно что работает "годами", я снимки размера близкого к предельному (50x50k) конвертировал за приемлемое время. Быстрее чем GlobalMapper их мне сохранял. Несколько минут на файл. Может быть ты в GlobalMapper координаты оставляешь как есть и оно у тебя каждый пиксель пересчитывает? 2) Если оно однопоточное, то перекомпиляцией многопоточность не добавится 3) Использовать последнюю версию map2jnx у меня вовсе не получилось.
А для каких списаний, я не	А для каких списаний, я не понял вопроса? Мне же для налогового учета (КУДИР) нужны только приходы, все остальное я в Эльбу не вношу.
Лёш, а могёшь эту штуковину компильнуть с заточкой по 64бит	Лёш, а могёшь эту штуковину компильнуть с заточкой по 64бит и многопоточность и прочие интеловские феньки https://qlandkartegt.svn.sourceforge.net/svnroot/qlandkartegt/map2jnx/tr... то что сейчас гуляет скомпилёным похоже делалось для калькулятора грузит проц на 10% и работает годами на относительно небольшом файле я с компиляторами ввобще никак не дружу, ну тоесть совсем кстати птичий глаз купил и разочаровался наполнение его гораздо бедней гугля в интересных для туристов местах
IO - это когда с 8 до 12 потоков. Больше потоков - уже время	IO - это когда с 8 до 12 потоков. Больше потоков - уже время начинает расти. Также на 6ти головом феноме (без ГТ естественно) оптимальное число 9 потоков. Да и вообще не понятно - IO ли это. При моих 24х гигах памяти (16ти на феноме) перенос билда на рэйд/ссд вообще не даёт никакого выигрыша - винт и так еле моргает с частотой раз в 3-4 секунды. Только сетевой диск через 100Mbps увеличивает время билда на пару минут (в основном на линковке монстрячих бинарников). Но отключать HT я попробую - когда будет время фигней пострадать в очередной раз ;)

Свежие комментарии

Pages