форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Для компилятра Clang реализована поддержка OpenMP"	+/–
Сообщение от opennews on 31-Авг-13, 09:44
Для компилятора 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
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Для компилятра Clang реализована поддержка OpenMP"	+3 +/–
Сообщение от Куяврик on 31-Авг-13, 09:44
как же теперь форониксу тестировать DragonflyBSD?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	2. "Для компилятра Clang реализована поддержка OpenMP"	+4 +/–
	Сообщение от Аноним (??) on 31-Авг-13, 10:41
	В 10 тыщ потоков.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	40. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от Аноним (??) on 01-Сен-13, 00:07
	>  как же теперь форониксу тестировать DragonflyBSD? Так же как и все остальное. Ну да, теперь оно не будет сдристывать в разы на многоядерниках. Может быть.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	107. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Куяврик on 05-Сен-13, 21:02
	> Так же как и все остальное. Ну да, теперь оно не будет > сдристывать в разы на многоядерниках. кто оно? гуано которое без OpenMP не умеет многопоточность? так там ничего не поменялось. оно по-прежнему не умеет собираться с другими либами для многопоточности.
	Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

3. "Для компилятра Clang реализована поддержка OpenMP"	+5 +/–
Сообщение от YetAnotherOnanym (ok) on 31-Авг-13, 11:30
Эти чортовы корпорации готовы передавать код в BSD-licenced проекты, лишь бы не открывать его по GPL!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	7. "Для компилятра Clang реализована поддержка OpenMP"	+4 +/–
	Сообщение от ананим on 31-Авг-13, 12:30
	Угу, только почему-то в 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-реализация, со всеми вытекающими. и ещё даже не релиз.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	8. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Аноним (??) on 31-Авг-13, 12:32
	OpenMP 4.0 слили сами ее автора в цокольный-gcc
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	13. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от ананим on 31-Авг-13, 12:40
	Ну дык и я о чём? ситуация — «Видишь напротив банк? Ну так вот, у меня с ними договор — я не даю взаймы, а они не торгуют семечками.»
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	9. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Аноним (??) on 31-Авг-13, 12:34
	>> Угу, только почему-то в gcc доступно уже несколько реализаций и гораздо более новых версий спецификаций и уже хрензнаеткогда. "Собаки лают, караван идет"
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	11. "Для компилятра Clang реализована поддержка OpenMP"	–3 +/–
	Сообщение от ананим on 31-Авг-13, 12:37
	>"Собаки лают, караван идет" угу. в собачьих упряжках видимо не сладко этот караван тянуть. вот они и лают. :D ps; Да пусть себе идёт. Только пока он идёт о работе с ним никакой речи просто нет.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	24. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Аноним (??) on 31-Авг-13, 18:00
	"собаки из интел" ? *в цитатник*
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	63. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от Vkni (ok) on 01-Сен-13, 21:33
	> Эти чортовы корпорации готовы передавать код в BSD-licenced проекты, лишь бы не > открывать его по GPL! Этого как раз не видно.
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

12. "Для компилятра Clang реализована поддержка OpenMP"	+2 +/–
Сообщение от аннон on 31-Авг-13, 12:40
и опять для работы кода, в системе нужна шлакобиблиотека от интеля. которая, как извесно полна подлянок для не её архитектур.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	51. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от Аноним (??) on 01-Сен-13, 13:38
	> которая, как извесно полна подлянок для не её архитектур. Да-да, не иначе. Будьте бдительны, враги на каждом шагу.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	65. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от YetAnotherOnanym (ok) on 02-Сен-13, 00:08
	"ребуется установка открытой runtime-библиотеки Intel OpenMP Runtime Library" - кто-то мешает програмерам от AMD или VIA запилить аналогичную либу с поддержкой своих "нюансов"? Или просто закоммитить патчи, поставив Интел перед выбором - принять патчи или получить скандал?
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

14. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
Сообщение от fidaj (ok) on 31-Авг-13, 12:44
"Для работы собранных в Clang OpenMP-приложений требуется установка открытой runtime-библиотеки Intel OpenMP Runtime Library." ну вот нафига такие костыли?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	15. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Аноним (??) on 31-Авг-13, 12:50
	> "Для работы собранных в Clang OpenMP-приложений требуется установка открытой runtime-библиотеки > Intel OpenMP Runtime Library." > ну вот нафига такие костыли? пологаю runtime-библиотеки можно захреначить при помощи -static
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	17. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от fidaj (ok) on 31-Авг-13, 12:59
	>> "Для работы собранных в Clang OpenMP-приложений требуется установка открытой runtime-библиотеки >> Intel OpenMP Runtime Library." >> ну вот нафига такие костыли? > пологаю runtime-библиотеки можно захреначить при помощи -static вот именно это и интересно - это сделали как временное решение до момента вливания в апстрим или этот костыль приживется на постоянной основе? (что совсем не радует)
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	18. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от Аноним (??) on 31-Авг-13, 13:05
	у gcc это сплош и рядом одни runtime ...
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	20. "Для компилятра Clang реализована поддержка OpenMP"	+4 +/–
	Сообщение от iZEN (ok) on 31-Авг-13, 14:28
	Кто сильно хотел, тот EGAVGA.BGI в TurboPascal преобразовывал в EGAVGA.OBJ, затем в TPU и статически компилировал со своим приложением. Обычные студенты не знали о такой возможности и иногда забывали положить EGAVGA.BGI рядом со свим учебным приложением. В результате чего приложение на зачёте оказывалось неработоспособным и незачтённым. ;)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	33. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Аноним (??) on 31-Авг-13, 20:20
	> в TurboPascal Вау! Вот откуда взялись эти толпы отечественных "программеров".
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	53. "Для компилятра Clang реализована поддержка OpenMP"	+7 +/–
	Сообщение от тоже Аноним (ok) on 01-Сен-13, 16:57
	Да, именно оттуда. Не вижу повода для негатива. Что нашли, на том и писали. Помнится, в начале 90-х, изучая прерывания, баловался с ними именно с помощью TP.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	76. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от ананим on 02-Сен-13, 11:01
	>баловался с ними  Хм, ничего и не добавишь. : D Потом приходил такой на счётмаш, ну такой баловник, такой... Ничего, через пол-годика обучения уже мог нормально работать. Процентов 70% правда отсеивалось, но...
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	88. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от тоже Аноним (ok) on 02-Сен-13, 16:02
	Засчитайте мне, пожалуйста, техническое поражение за неявкой в этой фаллометрии. Может, вам приятно будет.
	Ответить | Правка | ^ к родителю #76 | Наверх | Cообщить модератору

	108. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Куяврик on 05-Сен-13, 21:04
	> Вау! Вот откуда взялись эти толпы отечественных "программеров". Сам-то программер импортный, с рождения на никсах, верно? Или балабол очередной?
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	39. "Для компилятра Clang реализована поддержка OpenMP"	+2 +/–
	Сообщение от Карбофос (ok) on 31-Авг-13, 23:50
	не пиши больше такое. клуб анонимных торчков просто нервно курит, забившись в уголочке
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	47. "Для компилятра Clang реализована поддержка OpenMP"	+3 +/–
	Сообщение от iZEN (ok) on 01-Сен-13, 07:32
	Почему?! TurboPascal до сих пор используется на первых курсах при обучении студентов технических специальностей ВУЗов информатике.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	52. "Для компилятра Clang реализована поддержка OpenMP"	+2 +/–
	Сообщение от Michael Shigorin (ok) on 01-Сен-13, 14:50
	> Почему?! TurboPascal до сих пор используется Да, это проблема.  За прошедшие пару десятков лет её сложно было не заметить по килотоннам поделок на учебном языке, на которые понавязали процессов в реальной жизни. Но некоторым, похоже, удалось.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	54. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от тоже Аноним (ok) on 01-Сен-13, 17:00
	Не согласен. Проблема отнюдь не в этом. Вы знаете хоть одного человека, который научился программированию на уроках? Или, может быть, полагаете, что это вина учебного материала?
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	55. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от ананим on 01-Сен-13, 17:25
	Безусловно по всем пунктам. Зыж Думаю не стоит напоминать как линух появился. Или например универ Беркли. Или историю появления сети и тд. Да, учебный материал у нас не выдерживает критики. Основы алгоритмов — школьная программа. В вузах им (уже) не место. Наши вузы не являются локомативом в этой отрасли.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	78. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Michael Shigorin (ok) on 02-Сен-13, 12:09
	> Не согласен. Проблема отнюдь не в этом. И в этом, т.к. практика -> привычка. > Вы знаете хоть одного человека, который научился программированию на уроках? Научиться и развиваться -- разное. Начинал с лиспа, затем долго и много писал на разных бейсиках, затем на кружке зацепили паскалем, но не настаивали; а тем временем знакомые программисты подсунули TopSpeed Modula-2, на коей было писано ещё долго и много.  Затем -- линукс, руками писать makefile, руками выделять память и дебужить.  Затем -- шелл и когда его не хватает -- ruby. А затем вернулся опять к лиспу. :)
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	87. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от тоже Аноним (ok) on 02-Сен-13, 15:55
	И все-таки проблема в другом. Нет у нас в учебных заведениях обучения программированию. Кто сам захочет - научится сам, кому лень - нет. Что есть эти уроки, что нет. Или вот пример: четвертый класс у племянника, информатика. В игровой форме вполне серьезно разобраны азы множеств и алгоритмов. Потом пятый класс, "тоже информатика". Основы компьютерной грамотности в виде MS Paint и MS Word. Знания, которые даны в четвертом классе, слиты в канализацию...
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	92. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Crazy Alex (ok) on 02-Сен-13, 18:31
	Подозреваю, что это остатки программ с советских времен. Там суть предмета "информатика" была вообще ни разу не в обучении программировать - а в формировании у ребенка некоторых навыков мышления/алгоритмизации/планирования. Хотя, конечно, если б довели до конца - было бы много больше толку.
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	106. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от Vkni (ok) on 04-Сен-13, 20:49
	> В игровой форме вполне серьезно разобраны азы множеств и алгоритмов. Потом пятый класс, "тоже информатика". Левенчук в своё время сокрушался, что нет полного сквозного курса програзма. И построить его довольно сложно. Т.е. учить детку можно буквально с 5-6-ти лет на всяких пиктомирах, играх в роботов. А что дальше - непонятно. Хотя поддержать можно. А судя по тому, что пишут зарубежные авторы, это вообще проблема для "западных варваров", включая "северных".
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	100. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от Vkni (ok) on 04-Сен-13, 09:53
	> А затем вернулся опять к лиспу. :) ML-то по-интереснее будет. :-)
	Ответить | Правка | ^ к родителю #78 | Наверх | Cообщить модератору

	103. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Michael Shigorin (ok) on 04-Сен-13, 13:02
	>> А затем вернулся опять к лиспу. :) > ML-то по-интереснее будет. :-) Об него зубы тоже малость ломал -- на примере febootstrap. :)
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	64. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Аноним (??) on 01-Сен-13, 23:45
	Вы не поверите, но это проблема. Для грядущего российского IT.
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	56. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от ананим on 01-Сен-13, 17:31
	>Кто сильно хотел, тот EGAVGA.BGI в TurboPascal преобразовывал в EGAVGA.OBJ Который тут же линковался с прогой на борланд си 3.1 без всяких тпру-у-у. Борланд си — отличный был компилятор (на них тоже делал) и иде. Вот его сразу и нужно было использовать в обучении. А не пытаться придумать язык для умственных инвалидов (они так потом без этих костылей и не могли развиваться дальше. На современных 1ц-эшников похожи)
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	57. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от ананим on 01-Сен-13, 17:34
	>(на них тоже делал)  Имеется в виду юнихи. (На линух правда не пробовал. Линуха ещё не было :D)
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	60. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от iZEN (ok) on 01-Сен-13, 19:38
	>>Кто сильно хотел, тот EGAVGA.BGI в TurboPascal преобразовывал в EGAVGA.OBJ > Который тут же линковался с прогой на борланд си 3.1 без всяких > тпру-у-у. > Борланд си — отличный был компилятор (на них тоже делал) и иде. TurboC++ довольно медленный компилятор, впрочем, компиляторы C/C++ сами по себе медленные, так как компонуют весь текст программы в одну большую "простыню", а только потом компилируют это чудо. Компилятор модульного Pascal же обходился раздельной компиляцией и был очень быстр из-за идеологии организации структур данных. > Вот его сразу и нужно было использовать в обучении. Слишком долгая компиляция не способствует быстрому получению результата. Почему интерпретируемые языки получили широкое распространение в сфере обучения? Потому что для запуска программы не нужно ждать, пока она откомпилируется. Быстрые компиляторы Pascal и позднее Java свели ожидание запуска на нет. > А не пытаться придумать язык для умственных инвалидов (они так потом без этих костылей и не могли развиваться дальше. На современных 1ц-эшников похожи) Всё же TurboPascal (особенно версия 5.5) внёс серьёзный вклад в продвижение ООП на Wintel-платформе. Apple Pascal — на Mac. Другой вопрос, а эффективно ли ООП, не лучше ли было продвигать Lisp? (С++ для ООП вообще не рассматривался в практическом смысле в отрыве от STL).
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	66. "Для компилятра Clang реализована поддержка OpenMP"	–2 +/–
	Сообщение от Аноним (??) on 02-Сен-13, 04:01
	> TurboC++ довольно медленный компилятор, Не заметил особой разницы с паскакалем. > так как компонуют весь текст программы в одну большую "простыню", а > только потом компилируют это чудо. Да что ты? А библиотеки - это чего по твоему? > Компилятор модульного Pascal же обходился раздельной > компиляцией и был очень быстр из-за идеологии организации структур данных. А сишный линкер, типа, очень долго линковал программу с готовой библиотекой? Ты дypилка картонная и не понимаешь как сишный компилер работает, но умничать лезешь. Сперва узнай кто такие объектники и библиотеки, потом приходи. > программы не нужно ждать, пока она откомпилируется. Быстрые компиляторы Pascal и > позднее Java свели ожидание запуска на нет. Ололо. Это у явы то нулевое ожидание? Там пока программа взлетит - рак на горе свистнет. > Всё же TurboPascal (особенно версия 5.5) внёс серьёзный вклад в продвижение ООП Это ты так на дельфю тонко намекнул, но постеснялся уточнить? :)
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	102. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от Vkni (ok) on 04-Сен-13, 09:55
	>> TurboC++ довольно медленный компилятор, > Не заметил особой разницы с паскакалем. А вы их сравнивали на одних и тех же современных им машинах? Скажем, на 386-х невооружённым взглядом было видно, что TP в разы уделывал TC.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	105. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от iZEN (ok) on 04-Сен-13, 13:42
	>> 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.
	Ответить | Правка | ^ к родителю #66 | Наверх | Cообщить модератору

	69. "Для компилятра Clang реализована поддержка OpenMP"	–3 +/–
	Сообщение от ананим on 02-Сен-13, 04:20
	>впрочем, компиляторы C/C++ сами по себе медленные, так как компонуют весь текст программы в одну большую "простыню", а только потом компилируют это чудо. А вот и последствия "паскалевского" обучения. Хинт — а как упомянутый тобой obj (ну тот который ты потом в tpu перегонял) получается? И что это вообще? В общем бред. А потом другой — то С компилятор "вдруг" медленный, то pascal (не object) c С++ сравниваешь. ps; >Слишком долгая компиляция не способствует быстрому получению результата. во-первых, в обучении результатом является не блоб, а знания. и уж С способствует гораздо более глубогому пониманию работы всего процесса разработки (пример ИлИтных паскалевцев с bgi ты выше уже привёл) во-вторых, компилятор С уж точно не медленнее Pascal, а С++ не особо медленнее ObjectPascal.
	Ответить | Правка | ^ к родителю #60 | Наверх | Cообщить модератору

	70. "Для компилятра Clang реализована поддержка OpenMP"	+2 +/–
	Сообщение от kshetragia (ok) on 02-Сен-13, 05:58
	Прежде чем выхлопы строчить, лучше почитай о линейке TP->Modula->Oberon->Component Pascal. А потом посмотри на java и python и удивись. Всё правильно написано. Модули в TP строго типизированы и позволяют раздельную компиляцию. В то время как в С/С++ это разделение очень и очень условно.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	74. "Для компилятра Clang реализована поддержка OpenMP"	–3 +/–
	Сообщение от ананим on 02-Сен-13, 10:50
	Этот бред даже комментировать не вижу смысла. Зыж Типизированные модули — это что-то. : D Специалисты по коневодству в вакууме на марше.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	81. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от kshetragia (ok) on 02-Сен-13, 13:28
	Прочитай хотя бы это:   http://www.pascal.helpov.net/index/pascal_modules_programming Ну да.. в мейнстрим языках этого и близко нет. К сожалению. Во многом за счет этого Паскаль позволяет компилять любую часть программы не трогая остальное.
	Ответить | Правка | ^ к родителю #74 | Наверх | Cообщить модератору

	82. "Для компилятра Clang реализована поддержка OpenMP"	–3 +/–
	Сообщение от ананим on 02-Сен-13, 14:31
	Я уже говорил что это бред неуча? зыж Не, для паскаля модули турбо-паскаля это безусловно шаг вперёд. Вот только ваша экстраполяция на Си тянет только на двоечку, ибо Си без 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. В общем ваш бред — бред неуча.
	Ответить | Правка | ^ к родителю #81 | Наверх | Cообщить модератору

	83. "Для компилятра Clang реализована поддержка OpenMP"	+3 +/–
	Сообщение от kshetragia (ok) on 02-Сен-13, 14:44
	И причем здесь libc??? Вы хоть разделяете модуль от библиотеки?
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	84. "Для компилятра Clang реализована поддержка OpenMP"	–2 +/–
	Сообщение от ананим on 02-Сен-13, 15:15
	А зачем? Библиотеки для С делают тоже самое, что и модули в паскале. И вон пример айзена c конвертацией EGAVGA.BGI в OBJ (а потом в tpu именно для паскаля, т.к. с работает с obj напрямую) тому прямое доказательство. зыж Спасибо, поржал от души. :D ззыж Это ещё про dso (dinamic shared library) не говорили. Конечно не в ms-dos (для которого этот турбо-паскаль только и существовал. но мы ведь не будем загонять С в эти, школьные рамки, не так ли? :D)
	Ответить | Правка | ^ к родителю #83 | Наверх | Cообщить модератору

	85. "Для компилятра Clang реализована поддержка OpenMP"	+2 +/–
	Сообщение от kshetragia (ok) on 02-Сен-13, 15:31
	> А зачем? Библиотеки для С делают тоже самое, что и модули в паскале. Ну да.. накостылили. Как-то работает. Обучили тучу людей делать то же самое. Теперь это мейнстрим, теперь это энтерпрайз-з-з и кошерно.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	89. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от ананим on 02-Сен-13, 17:13
	Засчитаем слив (словесного поноса) или будут аргументы?
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	97. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от kshetragia (ok) on 03-Сен-13, 05:37
	Продолжай сливать, я то тут причём? Аргументы были по ссылке выше, но тебе же хоть учебник напиши - не осилишь.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	98. "Для компилятра Clang реализована поддержка OpenMP"	–4 +/–
	Сообщение от ананим on 03-Сен-13, 08:29
	В учебнике нет ни слова, что модули турбо-паскаля чем-то лучше библиотек С. Этот вывод только ваш (и слив тоже). зыж >но тебе же хоть учебник напиши - не осилишь. сопли подбери, двоеШник.
	Ответить | Правка | ^ к родителю #97 | Наверх | Cообщить модератору

	99. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Led (ok) on 03-Сен-13, 17:10
	> В учебнике нет ни слова, что модули турбо-паскаля чем-то лучше библиотек С. И, тем не менее, это так.
	Ответить | Правка | ^ к родителю #98 | Наверх | Cообщить модератору

	101. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от ананим on 04-Сен-13, 09:54
	Ещё раз — аргументы будут?
	Ответить | Правка | ^ к родителю #99 | Наверх | Cообщить модератору

	104. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Michael Shigorin (ok) on 04-Сен-13, 13:05
	Уважаемые ананим и kshetragia, прошу урезать осетра (особенно первого).  Дискуссия с живым оппонентом бывает куда интересней дискуссии с предварительно умерщвлённым во избежание разногласий.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	86. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от iZEN (ok) on 02-Сен-13, 15:40
	> А зачем? Библиотеки для С делают тоже самое, что и модули в > паскале. > И вон пример айзена 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.
	Ответить | Правка | ^ к родителю #84 | Наверх | Cообщить модератору

	90. "Для компилятра Clang реализована поддержка OpenMP"	–3 +/–
	Сообщение от ананим on 02-Сен-13, 17:26
	>и затем в 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 это и то, и другое. А-а-а… что с жабиста взять, тем более с бывшего пасалевода.
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	93. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от iZEN (ok) on 02-Сен-13, 19:48
	Высказал ровно то, что прочувствовал от использования С++ компиляторов в эпоху MS-DOS и ранних версий Windows. Сейчас, сравнивая такие продукты, как OpenOffice и Eclipse, могу сказать, что прогресс в скорости компиляции программ на C++ с помощью GCC так и не заметен, а вот LLVM/Clang компилирует ПО заметно (где-то 20-25%) по сравнению с GCC 4.2-4.6 быстрее.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	94. "Для компилятра Clang реализована поддержка OpenMP"	–2 +/–
	Сообщение от ананим on 02-Сен-13, 22:42
	>Высказал ровно то, что прочувствовал от использования С++ компиляторов в эпоху MS-DOS и ранних версий Windows. Угу. Целиком и полностью написанных на С (с элементами ассемблера). Конечно! Что нужно изучать в эту эпоху? Паскаль! :D Это лучший способ почувствовать себя лунатиком. >Сейчас, сравнивая такие продукты, как OpenOffice и Eclipse, могу сказать, что прогресс в скорости компиляции программ на C++ с помощью GCC так и не заметен, а вот LLVM/Clang компилирует ПО заметно (где-то 20-25%) по сравнению с GCC 4.2-4.6 быстрее. Сейчас, в который раз объясняя, что речь не про скорость компиляции (хотя это и ОЧЕНЬ спорное утверждение) и что эта скорость на 100500 месте в обучении, прихожу к выводу, что утверждение выше — это аксиома. При чём лунатизм может быть хроническим.
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	95. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от iZEN (ok) on 02-Сен-13, 23:59
	Скорость быстрого получения работающей программы — очень важная вещь для процесса обучения. Обучающемуся очень быстро надоест ждать даже по полминуте, пока соберётся его учебный проект. Delphi 2.0 на Pentium-100 с 8 МБ ОЗУ в эпоху Windows 95 удавалось достичь скорости компиляции 300000 строк исходного кода на ObjectPascal в минуту (данные из переводной книжки по созданию баз данных на Delphi). В те времена это был самый быстрый компилятор среди компиляторов языков высокого уровня. То есть учебные программы, да хотя бы примеры программ из поставки компилировались и запускались в среде Delphi на выполнение практически мгновенно, чего не скажешь о таком же процессе в "однояйцевом близнеце" этой IDE — C++ Builder. Разница в скорости компиляции практически одинаковых больших демонстрационных проектов (в одном код на C++, в другом на ObjectPascal, формы с виджетами одинаковы) доходила до нескольких минут!
	Ответить | Правка | ^ к родителю #94 | Наверх | Cообщить модератору

	96. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от ананим on 03-Сен-13, 00:38
	>Скорость быстрого получения работающей программы Какие проблемы с компиляцией хеловордов? Зыж >300'000 строк Ты там обкуренный чтоли?
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	71. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от kshetragia (ok) on 02-Сен-13, 06:01
	К пониманию работы приводи ассемблер, который, кстати, тоже преподается наравне с паскалем. Паскаль приводит к пониманию чистоты кода и прививает культуру его написания, чем поголовно страдают С-шники.
	Ответить | Правка | ^ к родителю #69 | Наверх | Cообщить модератору

	72. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от ананим on 02-Сен-13, 10:37
	>К пониманию работы приводи ассемблер, который, кстати, тоже преподается наравне с паскалем. Который я и преподавал, деточка. >Паскаль приводит к пониманию чистоты кода и прививает культуру его написания, чем поголовно страдают С-шники. Бред. Пги чём абсолютный. Браво.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	73. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от kshetragia (ok) on 02-Сен-13, 10:43
	>>К пониманию работы приводи ассемблер, который, кстати, тоже преподается наравне с паскалем. > Который я и преподавал, деточка. Поздравляю. >>Паскаль приводит к пониманию чистоты кода и прививает культуру его написания, чем поголовно страдают С-шники. > Бред. > Пги чём абсолютный. > Браво. Я наблюдаю это каждый Божий день.
	Ответить | Правка | ^ к родителю #72 | Наверх | Cообщить модератору

	75. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от ананим on 02-Сен-13, 10:55
	Видимо заразно.
	Ответить | Правка | ^ к родителю #73 | Наверх | Cообщить модератору

	77. "Для компилятра Clang реализована поддержка OpenMP"	+4 +/–
	Сообщение от Аноним (??) on 02-Сен-13, 11:02
	> Паскаль приводит к пониманию чистоты кода и прививает культуру его написания, Дельфистам это расскажите, они будут очень удивлены.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	79. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Michael Shigorin (ok) on 02-Сен-13, 12:14
	> Борланд си — отличный был компилятор Дрянь это была от рождения, быренько купили у третьей стороны и долепили на коленке. Jensen & Partners International -- часть борландовского народу, которые писали _хороший_ компилятор со всем прочим положенным.  Их не дождались и купили вот ту поделку.  Обиделись, ушли, выкупили свои разработки, довели до продуктов серии TopSpeed и никакой багланд рядом не валялся ни с их оптимизирующим компилятором, ни с умным автоматическим линкером (конец восьмидесятых, на минуточку), ни с крайне удобным отладчиком, ни с самой средой разработки, прозрачно умевшей пять языков, ни с рантаймовыми библиотеками, к которым поставлялись исходники -- сами по себе бывшие ценнейшим примером рабочего кода при изучении той же модулы.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	80. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от ананим on 02-Сен-13, 12:51
	Не нужно выдёргивать из контекста. Как компилятор и иде он вполне соответствовал по удобству обучению в пику тому же турбо-паскалю. Единственный его минус на тот момент в этом плане был в том, что он появился много позже турбо-паскаля. Об оптимизации, скорости компиляции и прочем речи не было. (Я ещё помню ватком си и тд. Но речь только об учебном процессе) Кстати, уж если сравнивать, то на тот момент он был крепким середнечком. Тот же вс2 от мс изобилует ограничениями. Но винда делалась на нём.
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	27. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от 123 (??) on 31-Авг-13, 18:21
	А что такая ненависть к рантайм либам? Таки они экономят память и процессор.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	28. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от fidaj (ok) on 31-Авг-13, 18:51
	> А что такая ненависть к рантайм либам? Таки они экономят память и > процессор. это не ненависть... просто хотелось бы большей целостности, при этом обходиться без статической линковки - если сделать пакет то хотелось бы иметь предсказуемое его поведение при установке и запуске на другом хосту с отличными версиями в наборе библиотек|rt. как-то так.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	36. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от Аноним (??) on 31-Авг-13, 22:39
	Если вы сделаете пакет использующий GTK3, то о каком предсказуемом поведении может идти речь на другом хосте, где GTK3 нет и в помине. Вы делаете программу на GTK2, а другие сделали к ней плагины и все это красиво работает. Далее ваша система переходит на GTK3 и вы сохраняя целостность переводите свою программу на ту же библиотеку. Вам без разницы эти плагины, вы ими не пользуетесь. И, что мы увидим на другом хосте, где эти плагины присутствовали. Да они просто не загрузятся.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	37. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от fidaj (ok) on 31-Авг-13, 22:51
	> Если вы сделаете пакет использующий GTK3, то о каком предсказуемом поведении может > идти речь на другом хосте, где GTK3 нет и в помине. > Вы делаете программу на GTK2, а другие сделали к ней плагины и > все это красиво работает. Далее ваша система переходит на GTK3 и > вы сохраняя целостность переводите свою программу на ту же библиотеку. Вам > без разницы эти плагины, вы ими не пользуетесь. И, что мы > увидим на другом хосте, где эти плагины присутствовали. Да они просто > не загрузятся. я вообще-то говорил о библиотеках системного (типа libc) а не прикладного уровня... при чем тут GTK23...
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	38. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от Аноним (??) on 31-Авг-13, 23:25
	Хорошо, если вы используете pthread_getattr_default_np (из glibc 2.18) на своем хосте, то как это будет выглядеть на моем с glibc 2.4. И я не могу обновить системную библиотеку до glibc 2.18.
	Ответить | Правка | ^ к родителю #37 | Наверх | Cообщить модератору

	41. "Для компилятра Clang реализована поддержка OpenMP"	+2 +/–
	Сообщение от fidaj (ok) on 01-Сен-13, 00:09
	> Хорошо, если вы используете 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-мя разными конторами... меня, как разработчика, такая разношерстность настораживает и логика выбора такой схемы взаимодействия тоже... а в общем ладно - нет смысла продолжать болтовню...
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	48. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от Аноним (??) on 01-Сен-13, 08:51
	> - но видите ли для работы софта использующего сущьность №2 необходима какая-то > еще сущность №3 в виде отдельно стоящей либы Для работы почти всех программ на си нужна какая-то библа libc, а если посмотреть сколько библ типовая программа юзает через ldd - можно вообще офигеть :) И да, shared libs хороши тем что один и тот же код не таскается каждым пи... с собой а реюзается. А если вам нравится как сделано в винде - ну так там за это другие проблемы есть. Как раз гемор с тасканием всех либ или статической линковкой. Ибо чудес не бывает.
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	50. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от fidaj (ok) on 01-Сен-13, 12:18
	>> - но видите ли для работы софта использующего сущьность №2 необходима какая-то >> еще сущность №3 в виде отдельно стоящей либы > Для работы почти всех программ на си нужна какая-то библа libc, а > если посмотреть сколько библ типовая программа юзает через ldd - можно > вообще офигеть :) в контексте данной темы - было бы вполне достаточно 2-х сущностей... > И да, shared libs хороши тем что один и тот же код > не таскается каждым пи... с собой а реюзается. все системные библиотеки являются shared (на то они и *.sHAREDoBJECTS) - я не об этом... > А если вам нравится как сделано в винде - ну так там за это > другие проблемы есть. Как раз гемор с тасканием всех либ или > статической линковкой. Ибо чудес не бывает. нет - я не о "винде".
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	67. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Аноним (??) on 02-Сен-13, 04:03
	> в контексте данной темы - было бы вполне достаточно 2-х сущностей... Ага. Кодогенератор как таковой - раз. И некий стандартный набор либ - два. С чего они должны быть одной сущностью всенепременно - я не понял.
	Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

26. "Для компилятра Clang реализована поддержка OpenMP"	+/–
Сообщение от 123 (??) on 31-Авг-13, 18:19
В Clang есть Apple-вский  Grand Central. OpenMP в  Gcc -  как ничего кроме мата  не вызывал так и не вызывает.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	29. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от fidaj (ok) on 31-Авг-13, 18:58
	> В Clang есть Apple-вский  Grand Central. OpenMP в  Gcc - >  как ничего кроме мата  не вызывал так и не > вызывает. он (GCD) требует соответствующей реализации в ядре... да что-то как-то кроме как у Apple платформ он и не прижился... в других где есть поддержка - как-то избегают разработчики его использование - пишут свои реализации диспечеров исполнения потоков. это всё то же продолжение темы о целостности http://www.opennet.me/openforum/vsluhforumID3/91474.html#28
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	30. "Для компилятра Clang реализована поддержка OpenMP"	–1 +/–
	Сообщение от Фтщтнь on 31-Авг-13, 19:42
	> он (GCD) требует соответствующей реализации в ядре... Вы заблуждаетесь, это всего лишь библиотека. В бзде идет как обычный пакет.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	31. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от fidaj (ok) on 31-Авг-13, 20:02
	>> он (GCD) требует соответствующей реализации в ядре... > Вы заблуждаетесь, это всего лишь библиотека. В бзде идет как обычный пакет. это вы заблуждаетесь... а ну ка продемонстрируйте мне запуск проги использующей эту библиотеку на ядрах 8 <=r198732 и 9 <=r197293 https://wiki.freebsd.org/GCD
	Ответить | Правка | ^ к родителю #30 | Наверх | Cообщить модератору

	58. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Фтщтнь on 01-Сен-13, 18:13
	Внимательней, внимательней нужно быть, в реализации pthreads для FreeBSD до версии 8.1 не была реализована workqueue, без которой GCD работать не может, но согласитесь что это не проблема GCD
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	59. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от fidaj (ok) on 01-Сен-13, 18:32
	> Внимательней, внимательней нужно быть, в реализации pthreads для FreeBSD до версии 8.1 > не была реализована workqueue, без которой GCD работать не может, но > согласитесь что это не проблема GCD именно потому я и сказал - что GCD требует поддержки в ядре ;) (возвращаясь к началу диалога)
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	61. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от Фтщтнь on 01-Сен-13, 20:21
	Да нет, это workqueue (как часть стандарта POSIX Threads) требует поддержки в ядре, а деятели из BSD не реализовывали ее до последнего времени. В Linux есть давно уже
	Ответить | Правка | ^ к родителю #59 | Наверх | Cообщить модератору

	62. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от fidaj (ok) on 01-Сен-13, 21:25
	> Да нет, это workqueue (как часть стандарта POSIX Threads) требует поддержки в > ядре, а деятели из BSD не реализовывали ее до последнего времени. > В Linux есть давно уже хм.. не знал, спасибо.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	109. "Для компилятра Clang реализована поддержка OpenMP"	+/–
	Сообщение от анонимус (??) on 24-Сен-15, 13:48
	> Да нет, это workqueue (как часть стандарта POSIX Threads) требует поддержки в > ядре, а деятели из BSD не реализовывали ее до последнего времени. > В Linux есть давно уже знали бы ещё в posix об этом... это яблочная поделка, которую утащили во freebsd. в линуксах её как не было так и нет...
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	34. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от Аноним (??) on 31-Авг-13, 21:35
	OpenMP - ЧАСТЬ апстрима GCC. внезапно. самая быстрорастующая, причем, кроме изувеченного форка от интел.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	68. "Для компилятра Clang реализована поддержка OpenMP"	+1 +/–
	Сообщение от Аноним (??) on 02-Сен-13, 04:05
	>  как ничего кроме мата  не вызывал так и не вызывает. Пока вы генерите мат, куча софта вполне себе оным пользуется и в ус не дует. А эппл как обычно - пытаются корчить из себя независимую фирму. Что у изобретателей скругленных параллелепипедов, понадергавших халявы из открытых проектов - получается довольно туго.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема