Для компилятора Clang (http://clang.llvm.org/), развиваемого в рамках проекта LLVM, подготовлена (http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/03159... реализация поддержки стандарта OpenMP (http://ru.wikipedia.org/wiki/OpenMP) (Open Multi-Processing), позволяющего задействовать методы параллельного программирования в программах на языках Си и Си++. В настоящее время полностью реализована поддержка спецификаций OpenMP 3.1 (http://www.opennet.me/opennews/art.shtml?num=31153) и частичная поддержка OpenMP 4.0 (http://www.opennet.me/opennews/art.shtml?num=37635). Разработка была начата работником AMD и доведена до конца сотрудниками Intel, которые проделали большую часть работы.
В настоящее время наработки проекта OpenMP/Clang доступны в виде патчей (https://github.com/clang-omp/) для Clang 3.3. В будущем планируется выпускать обновления для всех новых выпусков Clang, синхронизировать патчи OpenMP с состоянием trunk-ветки Clang и добиться их включения в основную кодовую базу Clang/LLVM. Для работы собранных в Clang OpenMP-приложений требуется установка открытой runtime-библиотеки Intel OpenMP Runtime Library (http://www.openmprtl.org/). Реализация OpenMP 3.1 успешно проходит все известные тесты на совместимость с OpenMP, в том числе SPEC OMP2012, проверочный пакет OpenUH и тестовый набор Intel.
По производительности и масштабируемости поддержка OpenMP для Clang находится примерно на одном уровне с другими компиляторами, поддерживающими данную спецификацию. В GCC поддержка OpenMP была интегрирована (http://gcc.gnu.org/projects/gomp/) в компиляторы Си, Си++ и Фортран начиная с ветки 4.2 (http://gcc.gnu.org/gcc-4.2/changes.html), выпущенной в 2007 году. Отсутствие поддержки OpenMP в Clang долгое время упоминалось в качестве существенного недостатка данного компилятора, теперь проблема со сборкой параллельно выполняемого кода в Clang осталось в прошлом.URL: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-August/03159...
Новость: http://www.opennet.me/opennews/art.shtml?num=37790
как же теперь форониксу тестировать DragonflyBSD?
В 10 тыщ потоков.
> как же теперь форониксу тестировать DragonflyBSD?Так же как и все остальное. Ну да, теперь оно не будет сдристывать в разы на многоядерниках. Может быть.
> Так же как и все остальное. Ну да, теперь оно не будет
> сдристывать в разы на многоядерниках.кто оно? гуано которое без OpenMP не умеет многопоточность? так там ничего не поменялось. оно по-прежнему не умеет собираться с другими либами для многопоточности.
Эти чортовы корпорации готовы передавать код в BSD-licenced проекты, лишь бы не открывать его по GPL!
Угу, только почему-то в gcc доступно уже несколько реализаций и гораздо более новых версий спецификаций и уже хрензнаеткогда.пруфы:
1. версии — http://gcc.gnu.org/wiki/openmp
>OpenMP 4.0 (specifications released on July 2013)2. реализации — http://iwomp-2012.caspur.it/sites/iwomp-2012.caspur.it/files...
>Для работы собранных в Clang OpenMP-приложений требуется установка открытой runtime-библиотеки Intel OpenMP Runtime Library.
>Softwares
>‣ gcc 4.6.2 + libGOMP
>‣ gcc 4.6.2 + libKOMP
>‣ icc 12.1.2 + Intel OpenMP runtime (KMP)к чему это я — это только intel-реализация, со всеми вытекающими. и ещё даже не релиз.
OpenMP 4.0 слили сами ее автора в цокольный-gcc
Ну дык и я о чём?
ситуация — «Видишь напротив банк? Ну так вот, у меня с ними договор — я не даю взаймы, а они не торгуют семечками.»
>> Угу, только почему-то в gcc доступно уже несколько реализаций и гораздо более новых версий спецификаций и уже хрензнаеткогда."Собаки лают, караван идет"
>"Собаки лают, караван идет"угу. в собачьих упряжках видимо не сладко этот караван тянуть.
вот они и лают. :Dps;
Да пусть себе идёт.
Только пока он идёт о работе с ним никакой речи просто нет.
"собаки из интел" ? *в цитатник*
> Эти чортовы корпорации готовы передавать код в BSD-licenced проекты, лишь бы не
> открывать его по GPL!Этого как раз не видно.
и опять для работы кода, в системе нужна шлакобиблиотека от интеля. которая, как извесно полна подлянок для не её архитектур.
> которая, как извесно полна подлянок для не её архитектур.Да-да, не иначе. Будьте бдительны, враги на каждом шагу.
"ребуется установка открытой runtime-библиотеки Intel OpenMP Runtime Library" - кто-то мешает програмерам от AMD или VIA запилить аналогичную либу с поддержкой своих "нюансов"? Или просто закоммитить патчи, поставив Интел перед выбором - принять патчи или получить скандал?
"Для работы собранных в Clang OpenMP-приложений требуется установка открытой runtime-библиотеки Intel OpenMP Runtime Library."
ну вот нафига такие костыли?
> "Для работы собранных в Clang OpenMP-приложений требуется установка открытой runtime-библиотеки
> Intel OpenMP Runtime Library."
> ну вот нафига такие костыли?пологаю runtime-библиотеки можно захреначить при помощи -static
>> "Для работы собранных в Clang OpenMP-приложений требуется установка открытой runtime-библиотеки
>> Intel OpenMP Runtime Library."
>> ну вот нафига такие костыли?
> пологаю runtime-библиотеки можно захреначить при помощи -staticвот именно это и интересно - это сделали как временное решение до момента вливания в апстрим или этот костыль приживется на постоянной основе? (что совсем не радует)
у gcc это сплош и рядом одни runtime ...
Кто сильно хотел, тот EGAVGA.BGI в TurboPascal преобразовывал в EGAVGA.OBJ, затем в TPU и статически компилировал со своим приложением. Обычные студенты не знали о такой возможности и иногда забывали положить EGAVGA.BGI рядом со свим учебным приложением. В результате чего приложение на зачёте оказывалось неработоспособным и незачтённым. ;)
> в TurboPascalВау! Вот откуда взялись эти толпы отечественных "программеров".
Да, именно оттуда. Не вижу повода для негатива. Что нашли, на том и писали.
Помнится, в начале 90-х, изучая прерывания, баловался с ними именно с помощью TP.
>баловался с нимиХм, ничего и не добавишь. : D
Потом приходил такой на счётмаш, ну такой баловник, такой...
Ничего, через пол-годика обучения уже мог нормально работать. Процентов 70% правда отсеивалось, но...
Засчитайте мне, пожалуйста, техническое поражение за неявкой в этой фаллометрии.
Может, вам приятно будет.
> Вау! Вот откуда взялись эти толпы отечественных "программеров".Сам-то программер импортный, с рождения на никсах, верно? Или балабол очередной?
не пиши больше такое. клуб анонимных торчков просто нервно курит, забившись в уголочке
Почему?! TurboPascal до сих пор используется на первых курсах при обучении студентов технических специальностей ВУЗов информатике.
> Почему?! TurboPascal до сих пор используетсяДа, это проблема. За прошедшие пару десятков лет её сложно было не заметить по килотоннам поделок на учебном языке, на которые понавязали процессов в реальной жизни.
Но некоторым, похоже, удалось.
Не согласен. Проблема отнюдь не в этом. Вы знаете хоть одного человека, который научился программированию на уроках? Или, может быть, полагаете, что это вина учебного материала?
Безусловно по всем пунктам.Зыж
Думаю не стоит напоминать как линух появился. Или например универ Беркли. Или историю появления сети и тд.
Да, учебный материал у нас не выдерживает критики. Основы алгоритмов — школьная программа. В вузах им (уже) не место. Наши вузы не являются локомативом в этой отрасли.
> Не согласен. Проблема отнюдь не в этом.И в этом, т.к. практика -> привычка.
> Вы знаете хоть одного человека, который научился программированию на уроках?
Научиться и развиваться -- разное.
Начинал с лиспа, затем долго и много писал на разных бейсиках, затем на кружке зацепили паскалем, но не настаивали; а тем временем знакомые программисты подсунули TopSpeed Modula-2, на коей было писано ещё долго и много. Затем -- линукс, руками писать makefile, руками выделять память и дебужить. Затем -- шелл и когда его не хватает -- ruby.
А затем вернулся опять к лиспу. :)
И все-таки проблема в другом. Нет у нас в учебных заведениях обучения программированию. Кто сам захочет - научится сам, кому лень - нет. Что есть эти уроки, что нет.
Или вот пример: четвертый класс у племянника, информатика. В игровой форме вполне серьезно разобраны азы множеств и алгоритмов. Потом пятый класс, "тоже информатика". Основы компьютерной грамотности в виде MS Paint и MS Word. Знания, которые даны в четвертом классе, слиты в канализацию...
Подозреваю, что это остатки программ с советских времен. Там суть предмета "информатика" была вообще ни разу не в обучении программировать - а в формировании у ребенка некоторых навыков мышления/алгоритмизации/планирования. Хотя, конечно, если б довели до конца - было бы много больше толку.
> В игровой форме вполне серьезно разобраны азы множеств и алгоритмов. Потом пятый класс, "тоже информатика".Левенчук в своё время сокрушался, что нет полного сквозного курса програзма. И построить его довольно сложно. Т.е. учить детку можно буквально с 5-6-ти лет на всяких пиктомирах, играх в роботов. А что дальше - непонятно. Хотя поддержать можно.
А судя по тому, что пишут зарубежные авторы, это вообще проблема для "западных варваров", включая "северных".
> А затем вернулся опять к лиспу. :)ML-то по-интереснее будет. :-)
>> А затем вернулся опять к лиспу. :)
> ML-то по-интереснее будет. :-)Об него зубы тоже малость ломал -- на примере febootstrap. :)
Вы не поверите, но это проблема. Для грядущего российского IT.
>Кто сильно хотел, тот EGAVGA.BGI в TurboPascal преобразовывал в EGAVGA.OBJКоторый тут же линковался с прогой на борланд си 3.1 без всяких тпру-у-у.
Борланд си — отличный был компилятор (на них тоже делал) и иде.
Вот его сразу и нужно было использовать в обучении.
А не пытаться придумать язык для умственных инвалидов (они так потом без этих костылей и не могли развиваться дальше. На современных 1ц-эшников похожи)
>(на них тоже делал)Имеется в виду юнихи. (На линух правда не пробовал. Линуха ещё не было :D)
>>Кто сильно хотел, тот EGAVGA.BGI в TurboPascal преобразовывал в EGAVGA.OBJ
> Который тут же линковался с прогой на борланд си 3.1 без всяких
> тпру-у-у.
> Борланд си — отличный был компилятор (на них тоже делал) и иде.TurboC++ довольно медленный компилятор, впрочем, компиляторы C/C++ сами по себе медленные, так как компонуют весь текст программы в одну большую "простыню", а только потом компилируют это чудо. Компилятор модульного Pascal же обходился раздельной компиляцией и был очень быстр из-за идеологии организации структур данных.
> Вот его сразу и нужно было использовать в обучении.Слишком долгая компиляция не способствует быстрому получению результата. Почему интерпретируемые языки получили широкое распространение в сфере обучения? Потому что для запуска программы не нужно ждать, пока она откомпилируется. Быстрые компиляторы Pascal и позднее Java свели ожидание запуска на нет.
> А не пытаться придумать язык для умственных инвалидов (они так потом без этих костылей и не могли развиваться дальше. На современных 1ц-эшников похожи)
Всё же TurboPascal (особенно версия 5.5) внёс серьёзный вклад в продвижение ООП на Wintel-платформе. Apple Pascal — на Mac. Другой вопрос, а эффективно ли ООП, не лучше ли было продвигать Lisp? (С++ для ООП вообще не рассматривался в практическом смысле в отрыве от STL).
> TurboC++ довольно медленный компилятор,Не заметил особой разницы с паскакалем.
> так как компонуют весь текст программы в одну большую "простыню", а
> только потом компилируют это чудо.Да что ты? А библиотеки - это чего по твоему?
> Компилятор модульного Pascal же обходился раздельной
> компиляцией и был очень быстр из-за идеологии организации структур данных.А сишный линкер, типа, очень долго линковал программу с готовой библиотекой? Ты дypилка картонная и не понимаешь как сишный компилер работает, но умничать лезешь. Сперва узнай кто такие объектники и библиотеки, потом приходи.
> программы не нужно ждать, пока она откомпилируется. Быстрые компиляторы Pascal и
> позднее Java свели ожидание запуска на нет.Ололо. Это у явы то нулевое ожидание? Там пока программа взлетит - рак на горе свистнет.
> Всё же TurboPascal (особенно версия 5.5) внёс серьёзный вклад в продвижение ООП
Это ты так на дельфю тонко намекнул, но постеснялся уточнить? :)
>> TurboC++ довольно медленный компилятор,
> Не заметил особой разницы с паскакалем.А вы их сравнивали на одних и тех же современных им машинах? Скажем, на 386-х невооружённым взглядом было видно, что TP в разы уделывал TC.
>> TurboC++ довольно медленный компилятор,
> Не заметил особой разницы с паскакалем.В 1998-2000 годах она всё ещё была заметна невооружённым глазом, без секундомера.
> А библиотеки - это чего по твоему?
Библиотеки при ограниченных 64k на процесс MS-DOS? Разве что как оверлеи. В TP можно. Но зачем? Ведь в TP можно получить статически собранный бинарник, который влезет в эти самые 64k и на дискете много места не займёт. То же самое и с Delphi — там, правда, можно было выбирать, включать ли библиотеку VCL статически в EXE или не включать (по умолчанию включалась, а программа для Windows с пустой формой в этом случае занимала 350-450 килобайт, без — около 30 килобайт). Для сравнения, консольная программа, откомпилированная в Delphi, имела размер 5-10 килобайт, никакие дополнительные библиотеки ей были не нужны).
>> Компилятор модульного Pascal же обходился раздельной
>> компиляцией и был очень быстр из-за идеологии организации структур данных.
> А сишный линкер, типа, очень долго линковал программу с готовой библиотекой?Да и сейчас GCC и LLVM линкер работают не так быстро. В Delphi это происходило гораздо быстрее и незаметнее для разработчика — время от завершения правки исходника до запуска на отладку занимало от силы 2-3 секунды. Притом это время полной сборки проекта — построение бинарных модулей DCU из *.pas-файлов, разрешение связей, линковка бинарного кода в EXE СТАТИЧЕСКИ.
> Ололо. Это у явы то нулевое ожидание? Там пока программа взлетит - рак на горе свистнет.
Всё же кэшируется в оперативной памяти. Кэш дисковой подсистемы не учли что ли?
>> Всё же TurboPascal (особенно версия 5.5) внёс серьёзный вклад в продвижение ООП
> Это ты так на дельфю тонко намекнул, но постеснялся уточнить? :)После TP5.5 был TP6.0, написанный с использованием оконной библиотеки TurboVision (библиотека написана на ObjectPascal с ассемблерными вставками), далее TP/BP7.0 с подсветкой синтаксиса исходных текстов, Borland Pasal for Windows 3.1 с использованием защищённого режима работы с памятью. Наконец, вышла Delphi 1.0 для Windows 3.1 и далее уже пошли версии 32-битных Delphi 2.0, 3.0... для Win9x/WinNT/2k.
>впрочем, компиляторы C/C++ сами по себе медленные, так как компонуют весь текст программы в одну большую "простыню", а только потом компилируют это чудо.А вот и последствия "паскалевского" обучения.
Хинт — а как упомянутый тобой obj (ну тот который ты потом в tpu перегонял) получается? И что это вообще?
В общем бред. А потом другой — то С компилятор "вдруг" медленный, то pascal (не object) c С++ сравниваешь.ps;
>Слишком долгая компиляция не способствует быстрому получению результата.во-первых, в обучении результатом является не блоб, а знания. и уж С способствует гораздо более глубогому пониманию работы всего процесса разработки (пример ИлИтных паскалевцев с bgi ты выше уже привёл)
во-вторых, компилятор С уж точно не медленнее Pascal, а С++ не особо медленнее ObjectPascal.
Прежде чем выхлопы строчить, лучше почитай о линейке TP->Modula->Oberon->Component Pascal. А потом посмотри на java и python и удивись.
Всё правильно написано. Модули в TP строго типизированы и позволяют раздельную компиляцию. В то время как в С/С++ это разделение очень и очень условно.
Этот бред даже комментировать не вижу смысла.Зыж
Типизированные модули — это что-то. : D
Специалисты по коневодству в вакууме на марше.
Прочитай хотя бы это:
http://www.pascal.helpov.net/index/pascal_modules_programmingНу да.. в мейнстрим языках этого и близко нет. К сожалению. Во многом за счет этого Паскаль позволяет компилять любую часть программы не трогая остальное.
Я уже говорил что это бред неуча?зыж
Не, для паскаля модули турбо-паскаля это безусловно шаг вперёд.
Вот только ваша экстраполяция на Си тянет только на двоечку, ибо Си без C standard library вообще не мыслим.
https://en.wikipedia.org/wiki/C_standard_library
>The C standard library provides macros, type definitions, and functions for tasks like string handling, mathematical computations, input/output processing, memory allocation and several other operating system services.и главное:
>The original C language provided no built-in functions such as I/O operations, unlike traditional languages such as COBOL and Fortran.[citation needed] Over time, user communities of C shared ideas and implementations of what is now called C standard libraries.В общем ваш бред — бред неуча.
И причем здесь libc??? Вы хоть разделяете модуль от библиотеки?
А зачем? Библиотеки для С делают тоже самое, что и модули в паскале.
И вон пример айзена c конвертацией EGAVGA.BGI в OBJ (а потом в tpu именно для паскаля, т.к. с работает с obj напрямую) тому прямое доказательство.зыж
Спасибо, поржал от души. :D
ззыж
Это ещё про dso (dinamic shared library) не говорили. Конечно не в ms-dos (для которого этот турбо-паскаль только и существовал. но мы ведь не будем загонять С в эти, школьные рамки, не так ли? :D)
> А зачем? Библиотеки для С делают тоже самое, что и модули в паскале.Ну да.. накостылили. Как-то работает. Обучили тучу людей делать то же самое. Теперь это мейнстрим, теперь это энтерпрайз-з-з и кошерно.
Засчитаем слив (словесного поноса) или будут аргументы?
Продолжай сливать, я то тут причём? Аргументы были по ссылке выше, но тебе же хоть учебник напиши - не осилишь.
В учебнике нет ни слова, что модули турбо-паскаля чем-то лучше библиотек С.
Этот вывод только ваш (и слив тоже).зыж
>но тебе же хоть учебник напиши - не осилишь.сопли подбери, двоеШник.
> В учебнике нет ни слова, что модули турбо-паскаля чем-то лучше библиотек С.И, тем не менее, это так.
Ещё раз — аргументы будут?
Уважаемые ананим и kshetragia, прошу урезать осетра (особенно первого). Дискуссия с живым оппонентом бывает куда интересней дискуссии с предварительно умерщвлённым во избежание разногласий.
> А зачем? Библиотеки для С делают тоже самое, что и модули в
> паскале.
> И вон пример айзена c конвертацией EGAVGA.BGI в OBJ (а потом в
> tpu именно для паскаля, т.к. с работает с obj напрямую) тому
> прямое доказательство.EGAVGA.BGI в OBJ и затем в TPU конвертируется с помощью соответствующей утилиты командной строки. Кладётся в каталог, где среда программирования TurboPascal ожидает увидеть TPU для линковки.
Дальнейшая разработка графической программы сводится лишь к компиляции *.pas файлов.
Запуск и отладка программы на OpjectPascal не требуют столько времени, как у TurboC++.К примеру позднее, с приходом Windows, сборка и запуск пустой формы с кнопочкой в Delphi и Borland C++Builder различались по времени на десятки секунд. Ждать, пока отдуплится компилятор C++, понятное дело, на маломощных учебных компьютерах ни сил, ни желания особо не хватало. Так что быстренько весь процесс начального обучения в университете перевели на Delphi. Впрочем, слишком умным студентам не запрещали использовать Microsoft Visual C++.
> зыж
> Спасибо, поржал от души. :D
> ззыж
> Это ещё про dso (dinamic shared library) не говорили. Конечно не в
> ms-dos (для которого этот турбо-паскаль только и существовал. но мы ведь
> не будем загонять С в эти, школьные рамки, не так ли?
> :D)Ты вообще отличаешь динамическое связывание кода от статического? Если на то пошло, то в TurboPascal были оверлейные модули. И, да, это концепция отлична от TPU.
>и затем в TPU конвертируется с помощью соответствующей утилиты командной строки. Кладётся в каталог, где среда программированиябла-бла-бла. студенты как мартышки проделывают это не понимая вообще ничего.
>Запуск и отладка программы на OpjectPascal не требуют столько времени, как у TurboC++.во брехло. Запуск и отладка НИКАК не связаны с компиляцией.
Уж что-что, а код на С получается и меньше, и быстрее. Опять же НИКАК не связано с получением знаний.
>> Это ещё про dso (dinamic shared library) не говорили.
>Ты вообще отличаешь динамическое связывание кода от статического?Вот и результат — у тебя каша в голове.
>Dynamically linked shared object libraries (.so): There is only one form of this library but it can be used in two ways.
> 1.Dynamically linked at run time but statically aware. The libraries must be available during compile/link phase. The shared objects are not included into the executable component but are tied to the execution.
> 2.Dynamically loaded/unloaded and linked during execution (i.e. browser plug-in) using the dynamic linking loader system functions.Ау! dso это и то, и другое.
А-а-а… что с жабиста взять, тем более с бывшего пасалевода.
Высказал ровно то, что прочувствовал от использования С++ компиляторов в эпоху MS-DOS и ранних версий Windows.Сейчас, сравнивая такие продукты, как OpenOffice и Eclipse, могу сказать, что прогресс в скорости компиляции программ на C++ с помощью GCC так и не заметен, а вот LLVM/Clang компилирует ПО заметно (где-то 20-25%) по сравнению с GCC 4.2-4.6 быстрее.
>Высказал ровно то, что прочувствовал от использования С++ компиляторов в эпоху MS-DOS и ранних версий Windows.Угу. Целиком и полностью написанных на С (с элементами ассемблера).
Конечно! Что нужно изучать в эту эпоху? Паскаль! :D
Это лучший способ почувствовать себя лунатиком.
>Сейчас, сравнивая такие продукты, как OpenOffice и Eclipse, могу сказать, что прогресс в скорости компиляции программ на C++ с помощью GCC так и не заметен, а вот LLVM/Clang компилирует ПО заметно (где-то 20-25%) по сравнению с GCC 4.2-4.6 быстрее.Сейчас, в который раз объясняя, что речь не про скорость компиляции (хотя это и ОЧЕНЬ спорное утверждение) и что эта скорость на 100500 месте в обучении, прихожу к выводу, что утверждение выше — это аксиома. При чём лунатизм может быть хроническим.
Скорость быстрого получения работающей программы — очень важная вещь для процесса обучения. Обучающемуся очень быстро надоест ждать даже по полминуте, пока соберётся его учебный проект. Delphi 2.0 на Pentium-100 с 8 МБ ОЗУ в эпоху Windows 95 удавалось достичь скорости компиляции 300000 строк исходного кода на ObjectPascal в минуту (данные из переводной книжки по созданию баз данных на Delphi). В те времена это был самый быстрый компилятор среди компиляторов языков высокого уровня.То есть учебные программы, да хотя бы примеры программ из поставки компилировались и запускались в среде Delphi на выполнение практически мгновенно, чего не скажешь о таком же процессе в "однояйцевом близнеце" этой IDE — C++ Builder. Разница в скорости компиляции практически одинаковых больших демонстрационных проектов (в одном код на C++, в другом на ObjectPascal, формы с виджетами одинаковы) доходила до нескольких минут!
>Скорость быстрого получения работающей программыКакие проблемы с компиляцией хеловордов?
Зыж
>300'000 строкТы там обкуренный чтоли?
К пониманию работы приводи ассемблер, который, кстати, тоже преподается наравне с паскалем. Паскаль приводит к пониманию чистоты кода и прививает культуру его написания, чем поголовно страдают С-шники.
>К пониманию работы приводи ассемблер, который, кстати, тоже преподается наравне с паскалем.Который я и преподавал, деточка.
>Паскаль приводит к пониманию чистоты кода и прививает культуру его написания, чем поголовно страдают С-шники.Бред.
Пги чём абсолютный.
Браво.
>>К пониманию работы приводи ассемблер, который, кстати, тоже преподается наравне с паскалем.
> Который я и преподавал, деточка.Поздравляю.
>>Паскаль приводит к пониманию чистоты кода и прививает культуру его написания, чем поголовно страдают С-шники.
> Бред.
> Пги чём абсолютный.
> Браво.Я наблюдаю это каждый Божий день.
Видимо заразно.
> Паскаль приводит к пониманию чистоты кода и прививает культуру его написания,Дельфистам это расскажите, они будут очень удивлены.
> Борланд си — отличный был компиляторДрянь это была от рождения, быренько купили у третьей стороны и долепили на коленке.
Jensen & Partners International -- часть борландовского народу, которые писали _хороший_ компилятор со всем прочим положенным. Их не дождались и купили вот ту поделку. Обиделись, ушли, выкупили свои разработки, довели до продуктов серии TopSpeed и никакой багланд рядом не валялся ни с их оптимизирующим компилятором, ни с умным автоматическим линкером (конец восьмидесятых, на минуточку), ни с крайне удобным отладчиком, ни с самой средой разработки, прозрачно умевшей пять языков, ни с рантаймовыми библиотеками, к которым поставлялись исходники -- сами по себе бывшие ценнейшим примером рабочего кода при изучении той же модулы.
Не нужно выдёргивать из контекста.
Как компилятор и иде он вполне соответствовал по удобству обучению в пику тому же турбо-паскалю.
Единственный его минус на тот момент в этом плане был в том, что он появился много позже турбо-паскаля.
Об оптимизации, скорости компиляции и прочем речи не было. (Я ещё помню ватком си и тд. Но речь только об учебном процессе)
Кстати, уж если сравнивать, то на тот момент он был крепким середнечком. Тот же вс2 от мс изобилует ограничениями. Но винда делалась на нём.
А что такая ненависть к рантайм либам? Таки они экономят память и процессор.
> А что такая ненависть к рантайм либам? Таки они экономят память и
> процессор.это не ненависть... просто хотелось бы большей целостности, при этом обходиться без статической линковки - если сделать пакет то хотелось бы иметь предсказуемое его поведение при установке и запуске на другом хосту с отличными версиями в наборе библиотек|rt.
как-то так.
Если вы сделаете пакет использующий GTK3, то о каком предсказуемом поведении может идти речь на другом хосте, где GTK3 нет и в помине.
Вы делаете программу на GTK2, а другие сделали к ней плагины и все это красиво работает. Далее ваша система переходит на GTK3 и вы сохраняя целостность переводите свою программу на ту же библиотеку. Вам без разницы эти плагины, вы ими не пользуетесь. И, что мы увидим на другом хосте, где эти плагины присутствовали. Да они просто не загрузятся.
> Если вы сделаете пакет использующий GTK3, то о каком предсказуемом поведении может
> идти речь на другом хосте, где GTK3 нет и в помине.
> Вы делаете программу на GTK2, а другие сделали к ней плагины и
> все это красиво работает. Далее ваша система переходит на GTK3 и
> вы сохраняя целостность переводите свою программу на ту же библиотеку. Вам
> без разницы эти плагины, вы ими не пользуетесь. И, что мы
> увидим на другом хосте, где эти плагины присутствовали. Да они просто
> не загрузятся.я вообще-то говорил о библиотеках системного (типа libc) а не прикладного уровня... при чем тут GTK23...
Хорошо, если вы используете pthread_getattr_default_np (из glibc 2.18) на своем хосте, то как это будет выглядеть на моем с glibc 2.4. И я не могу обновить системную библиотеку до glibc 2.18.
> Хорошо, если вы используете pthread_getattr_default_np (из glibc 2.18) на своем хосте,
> то как это будет выглядеть на моем с glibc 2.4. И
> я не могу обновить системную библиотеку до glibc 2.18.если при переходе к новой версии функцию pthread_getattr_default_np никто не сломал по обратной совместимости - то выглядеть будет нормально/прозрачно/красиво.
я говорю о другой плоскости (если начинать читать с самого моего первого поста в этой теме):
- есть сущность №1 - clang
- в ней реализовали сущность №2 - OpenMP
- но видите ли для работы софта использующего сущьность №2 необходима какая-то еще сущность №3 в виде отдельно стоящей либы - не бред ли? или не все коварные планы по внедрению зондов нам раскрыты?
я бы конечно молчал если бы все 3 сущности выходили бы из-под одного крыла, так нет - все 3 - разрабатываются/курируются - 3-мя разными конторами...
меня, как разработчика, такая разношерстность настораживает и логика выбора такой схемы взаимодействия тоже...
а в общем ладно - нет смысла продолжать болтовню...
> - но видите ли для работы софта использующего сущьность №2 необходима какая-то
> еще сущность №3 в виде отдельно стоящей либыДля работы почти всех программ на си нужна какая-то библа libc, а если посмотреть сколько библ типовая программа юзает через ldd - можно вообще офигеть :)
И да, shared libs хороши тем что один и тот же код не таскается каждым пи... с собой а реюзается. А если вам нравится как сделано в винде - ну так там за это другие проблемы есть. Как раз гемор с тасканием всех либ или статической линковкой. Ибо чудес не бывает.
>> - но видите ли для работы софта использующего сущьность №2 необходима какая-то
>> еще сущность №3 в виде отдельно стоящей либы
> Для работы почти всех программ на си нужна какая-то библа libc, а
> если посмотреть сколько библ типовая программа юзает через ldd - можно
> вообще офигеть :)в контексте данной темы - было бы вполне достаточно 2-х сущностей...
> И да, shared libs хороши тем что один и тот же код
> не таскается каждым пи... с собой а реюзается.все системные библиотеки являются shared (на то они и *.sHAREDoBJECTS) - я не об этом...
> А если вам нравится как сделано в винде - ну так там за это
> другие проблемы есть. Как раз гемор с тасканием всех либ или
> статической линковкой. Ибо чудес не бывает.нет - я не о "винде".
> в контексте данной темы - было бы вполне достаточно 2-х сущностей...Ага. Кодогенератор как таковой - раз. И некий стандартный набор либ - два. С чего они должны быть одной сущностью всенепременно - я не понял.
В Clang есть Apple-вский Grand Central. OpenMP в Gcc - как ничего кроме мата не вызывал так и не вызывает.
> В Clang есть Apple-вский Grand Central. OpenMP в Gcc -
> как ничего кроме мата не вызывал так и не
> вызывает.он (GCD) требует соответствующей реализации в ядре...
да что-то как-то кроме как у Apple платформ он и не прижился... в других где есть поддержка - как-то избегают разработчики его использование - пишут свои реализации диспечеров исполнения потоков.это всё то же продолжение темы о целостности
http://www.opennet.me/openforum/vsluhforumID3/91474.html#28
> он (GCD) требует соответствующей реализации в ядре...Вы заблуждаетесь, это всего лишь библиотека. В бзде идет как обычный пакет.
>> он (GCD) требует соответствующей реализации в ядре...
> Вы заблуждаетесь, это всего лишь библиотека. В бзде идет как обычный пакет.это вы заблуждаетесь...
а ну ка продемонстрируйте мне запуск проги использующей эту библиотеку на ядрах 8 <=r198732 и 9 <=r197293
https://wiki.freebsd.org/GCD
Внимательней, внимательней нужно быть, в реализации pthreads для FreeBSD до версии 8.1 не была реализована workqueue, без которой GCD работать не может, но согласитесь что это не проблема GCD
> Внимательней, внимательней нужно быть, в реализации pthreads для FreeBSD до версии 8.1
> не была реализована workqueue, без которой GCD работать не может, но
> согласитесь что это не проблема GCDименно потому я и сказал - что GCD требует поддержки в ядре ;) (возвращаясь к началу диалога)
Да нет, это workqueue (как часть стандарта POSIX Threads) требует поддержки в ядре, а деятели из BSD не реализовывали ее до последнего времени. В Linux есть давно уже
> Да нет, это workqueue (как часть стандарта POSIX Threads) требует поддержки в
> ядре, а деятели из BSD не реализовывали ее до последнего времени.
> В Linux есть давно ужехм.. не знал, спасибо.
> Да нет, это workqueue (как часть стандарта POSIX Threads) требует поддержки в
> ядре, а деятели из BSD не реализовывали ее до последнего времени.
> В Linux есть давно ужезнали бы ещё в posix об этом... это яблочная поделка, которую утащили во freebsd. в линуксах её как не было так и нет...
OpenMP - ЧАСТЬ апстрима GCC.
внезапно.
самая быстрорастующая, причем, кроме изувеченного форка от интел.
> как ничего кроме мата не вызывал так и не вызывает.Пока вы генерите мат, куча софта вполне себе оным пользуется и в ус не дует. А эппл как обычно - пытаются корчить из себя независимую фирму. Что у изобретателей скругленных параллелепипедов, понадергавших халявы из открытых проектов - получается довольно туго.