OpenMP во FreePascal

[olegy123]

Intel-овцы ругали OpenMP просили приобщится к tbb
https://www.threadingbuildingblocks.org/

[Vadim]

OpenMP делает столько задач сколько доступно потоков...

Либо меньше, если это указал (вручную) программист. Правда ручной режим мало кто использует, доверяя тому, сколько вычислительных ядер обнаружил OpenMP, тем не менее, ручная организация кол-ва потоков там тоже доступна.
Надо сказать, что многопоточность в OpenMP организовывается намного проще, чем с применением MPI. Другое дело, что MPI - это чисто сторонняя библиотека и от компилятора не зависит. Правда завести в FPC MPI мне так и не удалось, несмотря на правильное описание заголовков функций, единственное, что у меня работало, это MPI_Init() и MPI_Finalize(), на всё остальное выплевывалась ошибка 216.
Так что над параллельностью в FPC надо хорошо подумать. А то одна сплошная печаль...

Добавлено спустя 4 минуты 17 секунд:

Intel-овцы ругали OpenMP просили приобщится к tbb

Пугает С++шная реализация...

[Mirage]

Пихать крит. секции и пулы потоков в синтаксис языка ни к чему. Все прекрасно реализуется на уровне библиотек.
Ценность горутин в том, что это т.н. зеленый поток, т.е. в рамках одного потока несколько зеленых работают по очереди. В нативных языках нормально их не реализовать все равно. Да и в ненативных есть проблемы.
Вот библиотека хорошая на тему многопоточности нужна. Типа как Omnithread для Delphi, но кроссплатформенная. Вот эта вполне серьезный претендент, но руки никак не доходят поиграть с ней.

[serbod]

Посмотрел PasMP, хороший пример того, как не надо делать.

- Полное отсутствие документации. Есть только общее описание возможностей.
- Сложно разобраться даже в секции interface, огромное количество ifdef.
- Все-в-одном-файле
- Примеры нечитаемые, даже сраный Фибоначчи сделан с приведением указателей на указатели и прочими сишными фокусами. Внутри самой библиотеки такое допустимо, но небезопасный код даже в простых примерах - это однозначно нет.

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

[Alex2013]

И чем это go сильно отличается от чего-то вроде этого кода ?
(Это древний fpc+kol... сейчас в новых версиях Лазаруса наверное все гораздо проще можно сделать... хотя и так не очень сложно! )

Код: Выделить всё

function Simple_proc(l:pointer):Integer; stdcall;
type   TArr = array[0..0] of record r,g,b:byte; end;
var    i, j, t, _r, _g, _b, cnt,_x,_y: integer;
      row:pointer;
begin
   Result := 0;
   with PThreadRec(l)^ do
      for j := Start to Start + Size-1 do
        begin
            row := Src.ScanLine[j]; 
            for i := 0 to bmp.Width-1 do  
              begin
                cnt := 0;
                _r := 0;
                _g := 0;
                _b := 0;
                for t := 0 to step*step-1 do
                  begin      
                   _x := i + t mod step - d_step;
                   _y := j + t div step - d_step; 
                   if (_x >= 0)and(_x < bmp.Width)and(_y >= 0)and(_y < bmp.Height)then
                      with TArr(Bmp.ScanLine[_y]^)[_x] do begin
                         inc(cnt);
                         inc(_r,r);
                         inc(_g,g);
                         inc(_b,b);
                      end;
                  end;
                with TArr(row^)[i] do 
                  begin
                    r := _r div cnt;
                    g := _g div cnt;
                    b := _b div cnt;
                  end;
              end;
        end;
end;

procedure THIPBlur.Simple;
var rc:PThreadRec;
    i,c:integer;
    id:LongWord;
    lpSystemInfo:_SYSTEM_INFO;
    FEvents:array of cardinal;
    lst:PList;
begin
   bmp.PixelFormat := pf24bit;
   src.PixelFormat := pf24bit;
   if(bmp.Width > 256)and(bmp.Height > 256)then
     begin
       GetSystemInfo(lpSystemInfo);
       c := lpSystemInfo.dwNumberOfProcessors;
     end
   else c := 1;
   
   lst := NewList;
   SetLength(FEvents, c);
   for i := 1 to c do
     begin
       new(rc);
       rc.src := src;
       rc.bmp := bmp;
       rc.size := bmp.height div c;
       rc.Start := (i-1)*rc.size;
       rc.handle := CreateThread(0, 0, @Simple_proc, rc, 0, id);
       FEvents[i-1] := rc.handle;
       lst.Add(rc); 
       SetThreadPriority(rc.handle, THREAD_PRIORITY_HIGHEST);
     end;
   WaitForMultipleObjects(c, PWOHandleArray(@FEvents[0]), true, cardinal(-1));
   for i := 0 to c-1 do
     begin
       CloseHandle(FEvents[i]);
       dispose(PThreadRec(lst.Items[i]));
     end;
   lst.Free; 
end;

[serbod]

И чем это go сильно отличается от чего-то вроде этого кода ?

Принцип тот же, но меньше возможностей допустить ошибку. Это как паскалевский string, где снаружи все просто, а внутри довольно сложный механизм выделения и освобождения памяти, подсчета ссылок, контроля границ. Этот механизм обеспечивает прежде всего безопасность работы с памятью, защищает от general protection fault и подобных ужасов, убивающих программу на месте.

Люди придумывают новые парадигмы и языки программирования не потому, что возможностей не хватает. На машинных кодах можно написать вообще что угодно. Но и любую ошибку можно совершить. А на языках высокого уровня (особенно скриптовых) допустить ошибку сложно, и последствия ошибки незначительны. В итоге, даже корявый говнокод вполне сносно работает и справляется со своими задачами. И это очень хорошо. Плохой код, который работает, намного лучше хорошего кода, который не работает. А многопоточность такая штука, на одном компе все нормально, а на другом через пару часов ломается. В некоторых языках такое невозможно by design.