1.2, Аноним (-), 11:30, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +3 +/– |
Мне кажется Intel стоит приложиться для улучшения оптимизации кода для их платформ в GCC/CLang, чем дальше развивать свой компилятор
| |
|
2.7, Аноним (-), 11:56, 05/11/2013 [^] [^^] [^^^] [ответить]
| +5 +/– |
Они продают свой компилятор. Стоит ли особо упорствовать в разработке конкурента?
| |
|
3.26, Аноним (-), 15:50, 05/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Вообще-то интел извествен в основном продажами своих процессоров. А компилятор для них - сильно побочная хрень. Так что они известны и тем что например gcc допиливали под свои процессоры.
| |
|
4.35, pavlinux (ok), 17:01, 05/11/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
причём насильно, заставляя майнтенеров gcc и glibc вкуячивать свой код.
| |
|
5.47, Аноним (-), 19:21, 05/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
> причём насильно, заставляя майнтенеров gcc и glibc вкуячивать свой код.
Выкручивали руки, били ногами по яйцам, пытали электрошоком?
Как страшно жить...
| |
|
|
|
2.58, nagual (ok), 15:42, 06/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Мне кажется Intel стоит приложиться для улучшения оптимизации кода для их платформ
> в GCC/CLang, чем дальше развивать свой компилятор
А кто такой slashdot.org новый друг похороникса ? И почему новый друг похороникса забыл о сан студии ? Или о процах амд он тоже не в курсе ? Этакая скрытая реклама интела ?
| |
|
|
2.22, arisu (ok), 14:46, 05/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> зачес нам скорость ?
…ведь наш приветмир всё равно собирается мгновенно!
| |
|
1.4, Аноним (-), 11:42, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Это всё равно что сравнивать 32-битные и 64-битные приложения по размерам бинарников. Почему нет сравнения скорости работы самих приложений?
| |
|
|
|
4.24, Аноним (-), 15:27, 05/11/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
гугл с яблоком не хотят, чтобы вы это видели.
поэтому они очень заинтерисованы в проведении подобных сравнений с сильно подчёркнутым первенством цланга.
| |
|
3.15, Аноним (-), 12:56, 05/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
Oh my God! Аж одна какая-то тестовая программка! Ура! Ну теперь я валю с GCC
| |
|
|
3.36, pavlinux (ok), 17:05, 05/11/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> А зачем? Размер то один и внутри только единички и нули))
Всего то 2^64 * 8329! вариантов. (! - факториал.)
| |
|
4.48, Аноним (-), 19:23, 05/11/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
> Всего то 2^64 * 8329! вариантов. (! - факториал.)
на самом деле 2^(8*8329)!
(! - не факториал, а восклицательный знак)
| |
|
5.51, AlexAT (ok), 22:26, 05/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
Плюсую.
2^64*8329! меня сначала вогнало в ступор конкретно. Это получается число перестановок для 8329 уникальных позиций, с наличием дополнительного уникального параметра размером 64 бита, но никак не число вариантов для 8329 байт ")
| |
|
|
|
|
1.10, Аноним (10), 12:29, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +8 +/– |
интел по традиции в бинарник, пихает две нити кода. Одну быструю, для своих процессоров, и вторую огромную и тормозную, для всех остальных.
| |
|
2.12, annulen (ok), 12:42, 05/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
>интел по традиции в бинарник, пихает две нити кода.
Посмотри в ассемблер, умник
| |
|
|
4.32, annulen (ok), 16:37, 05/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Куда посмотреть, прости?
Собери файл с -S и убедись, что там нет никакой "второй нитки"
| |
|
5.33, annulen (ok), 16:37, 05/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
>> Куда посмотреть, прости?
> Собери файл с -S и убедись, что там нет никакой "второй нити" | |
5.34, Inome (ok), 16:41, 05/11/2013 [^] [^^] [^^^] [ответить]
| +3 +/– |
Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает мне бинарник в дизассемблере или objdump -S ./elf. В это случаи у gcc самый лучший вывод, хотя и в нем мусора хватает.
| |
|
6.38, pavlinux (ok), 17:22, 05/11/2013 [^] [^^] [^^^] [ответить]
| –3 +/– |
> Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает
gcc -O0 -mcpu=generic -S (и куча других -fno-* )
> мне бинарник в дизассемблере или objdump -S ./elf. В это случаи
> у gcc самый лучший вывод, хотя и в нем мусора хватает.
asm volatile( "cpuid" : "=a"(*a), "=d"(*d) : "0"(code) : "ebx", "ecx");
...
Закатать в бинарь проверку на CPU и замену syscall и библиотечных функций как два байта об асфальт.
Работу через CR регистры, которые обычные дизасмы не ловят. Самомодифицирующийся код...
| |
|
7.40, Crazy Alex (ok), 17:57, 05/11/2013 [^] [^^] [^^^] [ответить]
| +4 +/– |
Угу. А заодно они сотрудничают с инопланетянами. Прими таблетки уже, а то паранойя больше тебя.
| |
7.52, AlexAT (ok), 22:31, 05/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
>>> Самомодифицирующийся код...
Умер, как только появились кеши предвыборки и параллелизм/конвееры. Встречается либо в виде исключений, либо (чаще) в виде JIT, но это специфичные применения, сопровождающиеся командами, сбрасывающими очередь исполнения при переходе на собранный участок. Накладные расходы на сие велики, и допустимы только при приличном размере собранного кода.
| |
|
|
9.62, AlexAT (ok), 20:45, 06/11/2013 [^] [^^] [^^^] [ответить] | +/– | В целом да, но есть такая категория JIT-компиляторов pre-JIT, я бы сказал , как... текст свёрнут, показать | |
|
|
|
6.60, annulen (ok), 20:37, 06/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Тот вывод, что даёт флаг -S совершенно отличается от того, что выдает
> мне бинарник в дизассемблере или objdump -S ./elf.
Естественно, у icc там подробностей больше. Что сказать-то хотел?
>В это случаи у gcc самый лучший вывод, хотя и в нем мусора хватает.
Если под "лучшим" выводом понимается отсутствие комментариев от оптимизатора, то да, лучший.
| |
|
|
|
|
|
1.13, Аноним (-), 12:54, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +7 +/– |
> Лидером по скорости процесса сборки
А мне не пофиг какая будет скорость сборки? Мне важно какой будет скорость бинарника.
До сих пор не понимаю почему все так переключись мерятся скоростью сборки, тем более когда разница на деле не так уж велика. Выглядит как маркетинг.
| |
|
|
3.19, Аноним (-), 13:54, 05/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Может лучше использовать другие инструменты для сборки или научиться самому писать makefile, а не пересобирать весь проект при изменении одного файла, в котором не меняется API.
| |
|
4.20, NikolayV81 (ok), 14:22, 05/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> Может лучше использовать другие инструменты для сборки или научиться самому писать makefile,
> а не пересобирать весь проект при изменении одного файла, в котором
> не меняется API.
Может быть не знаю, на это тоже время тратить надо ;)
p.s. Предыдуще-текущие основные компилятор + среда собирали проект (как тут люди любят говорить с набросанными на формы кнопками и гридами в количестве большем сотни ) целиком за пару десятков секунд, при полном билде, а отладка запускалась на уровне скорости открытия форточки в ос. Но он не особо правильный идеологически, при этом ничего писать не надо было. Текуще-будущий комплект делает это дольше (но не дольше чем Qt), даже для формочки с 1-й кнопкой но он ещё менее идеологически чист, и повлиять на него не представляется возможным.
| |
|
5.46, Аноним (-), 19:20, 05/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Может быть не знаю, на это тоже время тратить надо ;)
Не тратьте времени на отладку. Вам она все равно ни к чему.
| |
|
|
|
2.30, Аноним (-), 16:31, 05/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Проекты выросли, поэтому. В сборке того же Chromium CLang делает GCC как по времени так и по потребляемой памяти при сборке. Там больше 8 ГБ рама нужно, если ничего не путаю. С ростом проектов, разница во времени сборки и потребляемой памяти будет всё более ощутимой.
| |
|
3.41, Crazy Alex (ok), 18:04, 05/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
Путаешь, наверное. Во всяком случае, с 4-мя гигами рамы и полутора свопа собирается.
| |
3.44, all_glory_to_the_hypnotoad (ok), 18:28, 05/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
память в таких проектах при сборке жрут ar и ld, особенно если собирать с отладочными данными. Именно на линкове вылетают сборки при недостаточном кол-ве ram, своп при этом не помогает.
| |
|
4.45, Crazy Alex (ok), 19:17, 05/11/2013 [^] [^^] [^^^] [ответить]
| +1 +/– |
Чего это ради он не будет помогать? Помогает, еще и как. И да, линковка - самый прожорливый этап, а если с LTO - вообще весело.
| |
|
5.49, all_glory_to_the_hypnotoad (ok), 20:41, 05/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
а хз почему так. Как только rss у ar/ld доходит до предела свободной памяти сразу падает, в своп не уходит. Мб это какие-то мои локальные особенности
| |
|
6.50, Crazy Alex (ok), 21:33, 05/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
Наверное. Я гентушник, и у меня сборка хрома и файрфокса лечилась именно включеним свопа.
| |
|
7.53, all_glory_to_the_hypnotoad (ok), 01:13, 06/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
о, я тоже. Сборка pypy валится как раз на ar/ld и своп не юзает. А с ff никогда проблем таких не было. С вебкитом такая же фигня если собирать с дебаг символами.
| |
|
|
|
|
|
|
1.17, anonymous (??), 13:10, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
А я могу печатать со скоростью 600 знаков в минуту. Правда, такая фигня получается.
| |
1.23, Аноним (-), 15:01, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
slashdot обнаглел и редиректит с https на http, у меня из-за httpseverywhere вкладка ушла в бесконечный редирект
| |
|
2.39, Аноним (-), 17:28, 05/11/2013 [^] [^^] [^^^] [ответить]
| +2 +/– |
Нет там никаких редиректов. Проверьте, не устраивает ли вам СОРМ MITM.
| |
|
1.42, Sylvia (ok), 18:18, 05/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
лучше бы они соревнования по поеданию хотдогов устраивали,
3 секунды, очень показательно... ни о чём
И кто будет смотреть производительность результирующего кода? И самое главное - его стабильность ?
| |
1.54, Adblog (ok), 13:01, 06/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
Странные люди. Какая разница сколько компилируется, главное - каков результат. Как по мне пусть лучше сам компилятор будет тормозным, но на выходе дает быстрый код, чем наоборот ...
| |
|
2.55, arisu (ok), 13:41, 06/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
я понял: это из-за таких, как ты, в gcc 4.8 появилась идиотская каретка, включеная по умолчанию!
| |
|
3.56, Adblog (ok), 14:17, 06/11/2013 [^] [^^] [^^^] [ответить]
| –1 +/– |
> я понял: это из-за таких, как ты, в gcc 4.8 появилась идиотская
> каретка, включеная по умолчанию!
А причем тут каретка-то? Она что как-то влияет на производительность? Оо
| |
|
4.57, arisu (ok), 14:20, 06/11/2013 [^] [^^] [^^^] [ответить]
| –2 +/– |
> А причем тут каретка-то?
да всё при том же. одним плевать на скорость компиляции, другим плевать на то, что строки в терминале расходуются без пользы.
| |
|
5.64, Vkni (ok), 10:15, 07/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
Положим, со скоростью компиляции горбатого могила исправит.
| |
|
6.65, arisu (ok), 10:21, 07/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
> Положим, со скоростью компиляции горбатого могила исправит.
а не спеши ты нас хоронить! :3
| |
|
7.66, Vkni (ok), 21:52, 07/11/2013 [^] [^^] [^^^] [ответить]
| +/– |
> а не спеши ты нас хоронить! :3
А не спешу, дел действительно много, но скорость, увы, не исправить.
| |
|
|
|
|
|
|
1.63, freehck (ok), 22:59, 06/11/2013 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Прошу поклонников Шланга и GCC в целях разжигания нового холивора и тыканья пальцем, обратить внимание, что в единственном тесте, где победа осталась за Шлангом:
"Параллельное приложение, написанное с использованием Cilk Plus, было выполнено при компиляции в ICC за 9.98 сек., GCC - 11.28 сек., Clang - 10.96 сек."
Согласно оригинальной статье, пользовательское время для gcc было в полтора раза меньше, а сравнение по системному времени, учитывая что производилось массовое распараллеливание, вообще говоря некорректно, ибо сильно зависит от настроения планировщика, и раз на раз не приходится.
| |
|