Здравствуйте, Khimik, Вы писали:

K>Я это представляю так: в таких ЯП должны быть два типа циклов – обычные и параллельные.

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

В реальности, это самообман.

Параллелить вычисления на уровне циклов чуть менее чем бесполезно.

В реальном мире есть задачи которые хорошо параллелятся и те что параллелятся плохо.

У большинства вычислений есть четкая последовательность. Чтобы вычислить Б нужно сначала вычислить А, и т.д.

Параллелить можно "в большом". Простой пример. Вот есть у нас проект который мы разрабатываем. В нем 100500 файлов. Паралелить разбор одно фала практически бесполезно (очень сложно и мало толку). Но распараллелить разбор отдельных файлов можно довольно просто.

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

Ну не может эффективно распараллеливать вычисления автомат (программа). А человек — может.

Значит нужно ему помочь.

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

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

Для того нужно чтобы программист оперировал некими областями памяти которые можно изменят только из одного потока управления. И предоставить программисту дешевый способ передачи "замороженного слепа информации" из одного потока в другой.

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

У меня есть масса мыслей по этому поводу. Но это требует разработки нового языка программирования. И нового рантайма для него.

Правильные мысли есть в Расте. Но там все слишком сложно для того чтобы это могло войти в мэйнстрим. Нужно научить языки манипулировать кучами. Научить передавать эти кучи между "виртуальными процессами" (в стиле Эрланг).

Для этого нужно создавать новые языки программирования.

Здравствуйте, Khimik, Вы писали:

K>Я это представляю так: в таких ЯП должны быть два типа циклов – обычные и параллельные.

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

В реальности, это самообман.

Параллелить вычисления на уровне циклов чуть менее чем бесполезно.

В реальном мире есть задачи которые хорошо параллелятся и те что параллелятся плохо.

У большинства вычислений есть четкая последовательность. Чтобы вычислить Б нужно сначала вычислить А, и т.д.

Параллелить можно "в большом". Простой пример. Вот есть у нас проект который мы разрабатываем. В нем 100500 файлов. Паралелить разбор одно фала практически бесполезно (очень сложно и мало толку). Но распараллелить разбор отдельных файлов можно довольно просто.

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

Ну не может эффективно распараллеливать вычисления автомат (программа). А человек — может.

Значит нужно ему помочь.

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

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

Для того нужно чтобы программист оперировал некими областями памяти которые можно изменят только из одного потока управления. И предоставить программисту дешевый способ передачи "замороженного слепа информации" из одного потока в другой.

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

У меня есть масса мыслей по этому поводу. Но это требует разработки нового языка программирования. И нового рантайма для него.

Правильные мысли есть в Расте. Но там все слишком сложно для того чтобы это могло войти в мэйнстрим. Нужно научить языки манипулировать кучами. Научить передавать эти кучи между "виртуальными процессами" (в стиле Эрланг).

Для этого нужно создавать новые языки программирования.