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

зы

оказывается, я не правильно понял. разрабатываемая ветка сначала перейдет в stage 4, и после, в феврале, ожидается релиз.
в stage 4 ветка уже перешла.

Это сообщение отредактировал(а) boostcoder - 10.1.2012, 10:20

с гордостью хочу сообщить о том, что исправил последний мне известный баг MinGW, вынуждающий использовать статическую линковку при использовании std_threads!
некоторое время я (на пару с вами) буду тестить этот fix, после чего закоммичу патч.

так же, исправил баг LTO в сборках 4.7.0, который не давал мне покоя уже 4 месяца.

выложил snapshot сборки 4.7.0.
готовлюсь к релизу  

качать тут.

Это сообщение отредактировал(а) boostcoder - 19.1.2012, 19:25

не к холивару будет пост, но только что в списке рассылки GCC были опубликованы сравнительные результаты тестирования компиляторов проводимые Willus.com.
в тестировании принимали участие компиляторы: MinGW (gcc 4.6.3), Intel 2011, Microsoft 2010 Visual C/C++ Express, и др.(Tiny CC, Digital Mars, MinGW (gcc 3.4.2)). использовались следующие опции. тестировались такие проекты как: BW1D, BZIP2, CRAFTY, K2PDFOPT, LAME, MESHER, MODEL3D, RESIZER, TRANSCEND, X264. тесты проводились в таком окружении:

в пяти из десяти тестов GCC-4.6.3 незначительно отставал от MSVC.
усредненное значение пересчитанное мною таково:
GCC - 15.13
MSVC - 15.12

т.е. MSVC на одну сотую секунды быстрее из суммы всех времен тестов. а Intel рвет всех.

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

Up.
хотя в результатах тестирования, такие результаты:
gcc-4.6.3-32: 1.38
gcc-4.6.3-64: 1.18
Intel-11-32: 1.21
Intel-11-64: 1.10
msvc2010: 1.59

тут можно скорее сказать, что gcc идет в ногу с intel, чем в ногу с msvc ;)


Это сообщение отредактировал(а) boostcoder - 19.1.2012, 19:31

Несколько раз перечитал описание данного бенчмарка - ничего не понял. Вернее не понял что это за параметр normalized run time
Вот это

перевести то перевёл, но что это значит - не понял. Зачем делить все времена (и что значит все??? сумму всех?) на лучший результат ?
Можешь разжевать для тупого ?

Можешь считать это средним результатом после проведения серии экспериментов.

Добавлено через 2 минуты и 30 секунд
Гцц оказался еще и самым тормозным в плане времени компиляции. Хотя это уже давно известно.

угу.


не нужно быть голословной.
все дело в том, что MSVC как и Intel производят сборку в несколько потоков. по умолчанию - сколько ядер. а gcc, точнее make.exe в венде работает в один поток. т.е. опция -j не дает эффекта ;)

скорее это говорит о разбросе в серии тестов. вот взять, например, первый тест.

и

вроде бы и время работы у tcc925 бешенное (91,1) и этот злополучный параметр плохой (5,31). Но ведь если время выполнения 91,1 сек, а отношение этого времени к лучшему = 5,3, то лучшее время 91,1 / 5,31 = 17,2. А у интела - 17,1 / 1,0 = 17,1.
Нифига не понимаю.   

на сколько я помню, это вообще Си компилятор, при том не оптимизирующий. нафег его вообще приплели к тестам?


в моих расчетах, я суммировал время работы теста(не компиляции) и поделил на кол-во тестов.

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

Добавлено через 3 минуты и 21 секунду
Я знаю про этот баг, но гцц все равно тормоз в соотношении качество/скорость компиляции.

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

newbee, нет, ты чтоб не потроллить о наболевшем, не можешь.

Дохтур, у меня ничего не болит, вы о чем вообще? ;;я честно не поняла, где троллинг.

Добавлено через 8 минут и 11 секунд
Я еще чуть чуть почитала про тцц и повнимательней посмотрела статистику, так этот тцц быстрее всех компилирует - чем не повод засунуть его в эксперимент?

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

скажите, кому либо в моих сборках, нужны ли Objective-C, Objective-C++, Fortran? хочу их исключить. за ненадобностью.

спасибо.

Objective-C и Objective-C++ были исключены за ненадобностью.

залил новые сборки версий 4.6.3-prerelease и 4.7.0-snapshot.

добавил новые сборки 4.6.2-release с фиксом динамической линковки при использовании std_threads.