чувствую kemiisto сейчас как напишет...    если что, я фортран совсем не знаю, и использовал такие фразы, как: "насколько я знаю", АФАИК итд  

Lazin, возможно ты и прав. С ФП. Есть правда у меня некоторые сомнения... 

В Fortran ввод/вывод вообще не потоковый... Но это фиг с ним...


Есть достаточное количество людей, считающих, что вся эта шумиха - проделки маркетологов. А так, всякие куды - игрушки. Я не знаю... Ho ведь таже CUDA - это опять же C. Да и Fortran никуда не уходил.

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

Добавлено @ 14:51

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

проблема с многоядерностью в нескольких местах - в организации кешей, и в организации ввода/вывода.
напр. если внутри чипа есть какое-то подобие шины (FSB), то ты зависаешь с ботлнеком на вводе/выводе.

все наверное знают, что задачи обычно характеризуют либо как одно из
1. cpu-bound, т.е. сосредоточенные на нагрузке вычислительных модулей процессора
2. io-bound, т.е. сосредоточенные на нагрузке ввода/вывода в процессор.

многопоточие и многоядерность обычно дает прирост первому типу задач, НО
проблема в том, что задачи нередо не относятся к типу 1 или 2, а являются какой-то микстурой из нагрузки арифметикой-данными, 
из 60-40 или 40-60, или 50-50.

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



Это сообщение отредактировал(а) bilbobagginz - 7.12.2009, 14:52

вот есть одна из не многих библиотек квантовой логики http://www.opennet.ru/docs/RUS/perl_obzor/...s/quantium.html

там написано что прогарммы быстрее работают, и быстрее чем в базе данных



http://nauka.relis.ru/cgi/nauka.pl?07+0101+07101024+HTML

ЗЫ я Fortran не знаю, надо будет посмотреть что за язык


Это сообщение отредактировал(а) gcc - 7.12.2009, 17:41

gcc, причём здесь квантовая логика?  

Читал как-то у Хокинга про какого-то известного учёного мужа, который задумался, когда его представили как одного из трёх человек на Земле, понимающих теорию относительности. На вопрос о предмете задумчивости он ответил, что никак не может понять, кто же третий!?   

Дык вот, квантовая логика - туда же. У меня даже книжка есть за авторством некого Васюкова В. Л. Это нечто. Функциональное программирование нервно курит в сторонке.  Вообще фон Нейман работал за пределами понимания для простых смертных...



Это сообщение отредактировал(а) kemiisto - 7.12.2009, 17:57

gcc, чего-то тебя (видимо как опозиционера фортрану) заминусовали 
я не понял: ты просто привел пример какой-нибудь научной библиотеки на перле ?

Китай -- одна из древнейших цивилизаций. Дремучие-предремучие, надо полагать. Они, наверное, до сих пор живут в соломенных домиках и учат кунг-фу. Блин, а ведь первая экономика в мире. Почему вас это не смущает? Всем знакомо понятие стандартов и пересмотров языка. Все смотрят, что нового в Java 7 и C# 3 и при этом почему-то думают, что Fortran не развивается. У него уже 1+5 международных стандартов: 66 (ANSI), 77, 90, 95, 2003, 2008. пересматриваться будет каждые пять лет. И если и останется компилируемый и не интерпретируемый язык, то это будут C и Fortran. У последних совместимость на уровне стандарта Fortran. В будущем разница в производительности между интерпретируемыми языками и скомпилированными с оптимизацией в машинный код будет всё возрастать, т.к. будет увеличиваться число вычислительных устройств, а значит и сам объём вычислений.


Да ну? Вот перемножение матриц, которое автоматически распараллеливается для N-ядерной машины.



    


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


Да. Писать обработку массивов данных на Fortran куда быстрее, чем на Python -- в последнем можно будет запросто потонуть в циклах. А про строгое соблюдение стандартов плавающей точки и расширенные точности вообще никто не говорит. На нём векторизация вообще возможна?


Ровно наоборот.


Пробежать не значит эффективно использовать. Здесь стоит вопрос -- интерпретируемость и многоплатформенность или компилируемость и автоматическая оптимизация под архитектуру на уровне языка. Вы ещё вспомните меня, когда будете плеваться на Google Chrome OS, там JavaScript проявит себя во всех красе интерпретации.


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


В F08 собираются ввести асинхронный ввод/вывод. Это можно делать с помощью задач в OpenMP.


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


Квантовые вычисления связаны со способом организации вычислений. В данном случае тоже двоичных. Это никак не соотносится с языком.

Мы все ругаем депутатов за то, что они предлагают бредовые законы, т.к. они (депутаты) не купаются сами в той среде, для которой эти законы принимаются. При этом в этой теме происходит практически то же самое -- идут разговоры и рассуждения на темы, которыми некоторые даже ни разу не занимались. ИМЕННО ТАК рождаются потом мифы в головах программистов. Для пытливых советую посмотреть средства регулярного программирования в Fortran, OpenMP (особенно директиву workshare, которая хоть как-то поддерживает Fortran 95), Co-array Fortran, автоматическую векторизацию (GCC, Intel Fortran). Средства параллельного ввода/вывода не спешат вводить в стандарт, т.к. мало прецедентов хороших реализаций в других языках.

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

P.S. А мы все дружно ждём как будут тормозить первые веб-оси, простите за не-по-теме.

Cr@$h, мы каждый говорим про свой специфический случай, не определяя этого в дискуссии,
получается, что каждый думает что второй думает про общий случай.
Есть характер задач, решение на которые дает HPC (high performance computing), это такие задачи, на решение которых выкладывается много денег, но реально свои задачи такие системы решают несколько процентов времени в году. (беовульф туда).

есть подход HTC (high throughput computing), когда нет особой критичности во времени, но есть огромное количество вычислений, это и есть GRID, где компутеры грызут себе вычисления месяцами без остановки.

это тоже смотря каких матриц (т.е. какой величины члены матрицы).


З.Ы. может создать какой-то раздел по параллельным и распределенным вычислениям ? про опенмп, про mpi, dsm, и т.д. ?