Спасибо за рзъяснение, не знал что везде MSVS 2010… Про 64-bit Linux прошу прощения, невнимательно читал, пропустил. Скорее всего именно потому что обозначение x64 непривычно в Linux мире.
Как минимум для Windows есть еще MSVS 2012 x32 и MinGW x86_32. Да и Linux x86_64 не понятно почему забыт… Итого вроде 7 уже получается.
А вообще было бы неплохо сделать api для PySide.
C89 3.3.8:
Each of the operators < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false. The result has type int.
Один вопрос — а почему LO 3.5? стабильная вроде как 4.2.1 ну или 4.1.5 на крайний случай.
P.S. По честному надо бы как-то валидировать получившиеся odt и смотреть — LO генерирует невалидный файл или MSO не хочет открывать файл, полностью соответствующий формату.
Нет, совершенно не смешно. Я говорю даже не про колею применительно к архитектуре CPU, а в целом к любой области знания и технологии. История вычислительных устройств пока слишком молода. Еще даже одно поколение не сменилось. Чтобы поменять колею, как правило, нужна как минимум смена одного поколения людей, то есть около 50 лет. И я почти уверен, что в ближайшие лет 10 возникнет вторая колея, которая станет основной еще через лет 10-15. Дело не в нише. Революции случаются как правило по более глобальным причинам. Одна из таких причин в данном случае — больше половины площади CPU занимают костыли, эмулирующие поведение машин 60х годов разработки. А значит, теоретически, можно сделать вычислительное устройство до 2х раз быстрее только поменяв подход. И, поскольку развитие полоупроводниковых технлогий замедлется, это может стать единственным реальным выходом. И именнопо этому рельсы скоро поменяются.
В том то и дело, что программы пишутся как есть. Язык просто не мешает компилятору и железу распараллеливать граф вычислений. Язык судя по всему напоминает современные функциональные, возможно тот же Хаскель. Просто нужно еще промежуточное представление(аля сжатие) и железо-ориентированный компилятор. Возможно, часть работы современного компилятора мог бы делать и сам процессор аппаратно.
Локальная память, как я понял, это и есть замена кэшу, а может даже и регистрам. По сути это кэш L1 для данных, который не синхронизируется с остальными т.е. синхронизация только явная на основании анализа алгоритма.
Есть большая разница. Он предлагает не архитектуру, сулящую выгоду в некоторых частных случаях(как те же явно параллельные видео ускорители, которые адаптировали для смежных задач), а радикальное изменение подхода для вычислительных ядер общего назначения. Поэтому искать нишу по сути не его забота, у Intel полно людей. Другое дело можно было бы поискать общие задачи, где такой переход дает больший выигрыш, чем в среднем, но это отдельная история.
А коле именяются регулярно…
Кстати Хаскель(да и в общем то все остальные функционально-ориентированные языки) как раз ближе к идеальному языку в его понимании, поскольку дает компилятору больше информации о структуре данных и графе вычислений, чем традиционные языки.
Это был просто пример того, что не всегда пишут memset 0, иначе можно ыбло не объявлять bzero устаревшей. Для большинстве платфор никак нельзя memset'ами писать шаблоном шире одного байта, на сколько я знаю. Но на Mac OS X есть в libc функции memset_pattern[4,8,16], относящиеся к семейству memset.
В релизе — да, а для отладки забивают 0xCC или 0xDEADBEEF или еще чем-то в этом роде. Так что этот баг слегка затруднял отладку. Промахнулся на один уровень.
x86, под который оптимизируется код и x86 Quark это совсем разные вещи. В нем(Quark) даже MMX нет, не говоря уже более новые расширения. Оптимизация под него и под большие ядра не имеет почти ничего общего. В какие будут наборы инструкций у мобильной платформы и сколько эти SoC будут есть — большой вопрос.
Около половины из того молока в пачках, которые я видел, не сворачивалось при добавлении спирта… То есть молочного белка там в свободном виде не наблюдалось.
Есть еще такая вещь, как cache contentions. Суть в том, что при некоторых обстоятельствах(«удачном» размере матрицы) g[i][j] и g[j][i] приходятся на одну линию кэша(см en.wikipedia.org/wiki/CPU_cache#Associativity). Получается что при обращение к первому адресу в L1 из L2 подтягивается одна область памяти. При обращении к второму — другая. И так _каждое_! обращение. Т.е. вместо кэширования области памяти и дальнейшего чтения последующих напрямую из L1 мы каждый раз ждем перечитывания из L2. Та же история может быть с L2, только обходится еще дороже — перечитывать из L3 или того хуже из памяти.
Подробно про такие вещи хорошо рассказывается в «Optimizing software in C++» by Agner Fog — www.agner.org/optimize/optimizing_cpp.pdf
Кстати, упоминаются в одном предложении язык C и гуманитарии. Зачем гуманитарию язык низкоуровнего системного программирования, который сильно завязан на понимание архитектуры компьютеров? На мой взгляд это мало что безсмыленно, так еще и себе дороже. И им пользоваться сложнее, и текст программ длиннее для той же задачи, и ошибки можно сделать, которые не объяснишь, не вдаваясь в эту самую архитектуру компьютера.
А вообще было бы неплохо сделать api для PySide.
Each of the operators < (less than), > (greater than), <= (less than or equal to), and >= (greater than or equal to) shall yield 1 if the specified relation is true and 0 if it is false. The result has type int.
P.S. По честному надо бы как-то валидировать получившиеся odt и смотреть — LO генерирует невалидный файл или MSO не хочет открывать файл, полностью соответствующий формату.
Локальная память, как я понял, это и есть замена кэшу, а может даже и регистрам. По сути это кэш L1 для данных, который не синхронизируется с остальными т.е. синхронизация только явная на основании анализа алгоритма.
А коле именяются регулярно…
Подробно про такие вещи хорошо рассказывается в «Optimizing software in C++» by Agner Fog — www.agner.org/optimize/optimizing_cpp.pdf