|
2.4, Andrey Mitrofanov (?), 10:49, 09/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Можно использовать совместно с Mesa/DRI 11.0.8?
На софтваре-растерайзер потянуло? Невидиа жмёт?! Пользуйся, чего уж, разрешаю.
The Gallium llvmpipe driver is a software rasterizer that uses LLVM to do runtime [...]
[...]
* LLVM: version 3.4 recommended; 3.3 or later required.
http://www.mesa3d.org/llvmpipe.html
| |
|
|
4.8, Andrey Mitrofanov (?), 12:30, 09/03/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
*>>Пользуйся, чего уж, разрешаю.
*>> * LLVM: version 3.4 recommended; 3.3 or later required.
> То есть - нельзя.
Эппле не такой добрый, как я? Или коре тиим жмётся? Кто обидел нашего рубаху-парня?!
| |
|
3.10, Аноним (-), 14:25, 09/03/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
Ну почему же сразу софтваре-растерайзер? Как же gallium3d и AMDGPU-бэкенд?
| |
|
4.12, Andrey Mitrofanov (?), 15:27, 09/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Ну почему же сразу софтваре-растерайзер? Как же gallium3d и AMDGPU-бэкенд?
У него невидия. Исколючительно и только. Но он почему-то не спросил, можно ли ему с блобом невидии "использовать" llvm. Видимо знал, куда идти -- сразу.
| |
|
5.34, iZEN (ok), 21:56, 11/03/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
> glxgears
Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
300 frames in 5.0 seconds = 59.883 FPS
300 frames in 5.0 seconds = 59.964 FPS
300 frames in 5.0 seconds = 59.964 FPS
299 frames in 5.0 seconds = 59.760 FPS
300 frames in 5.0 seconds = 59.966 FPS
- на AMD 785G (RS880, Radeon HD 4200)
| |
|
|
|
|
|
|
|
4.35, pavlinux (ok), 03:20, 12/03/2016 [^] [^^] [^^^] [ответить]
| +5 +/– |
> Именно крашиться он всё равно не должен.
Срочно в Microsoft резюме отправляй. В конце допиши "Мои проекты все без багов и всегда работают"
| |
|
3.25, Аноним (-), 22:03, 09/03/2016 [^] [^^] [^^^] [ответить]
| –4 +/– |
Ога. Вываливается с бектрейсом и просит отправить сырцы на багтрекер.
А то что гцц и мсвц все собирают я даже и не говорю.
| |
|
4.41, Владимир (??), 09:21, 13/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
Похоже, местные аналитики опеннета считают, что краш программы при обработке пользовательских данных - вполне себе нормальное поведение.
Да будь там хоть гигабайтный исходный файл на входе или 14000 вложенных циклов - пусть ошибку выдает, раз не может справиться.
Еще и заминусовали человека. Бред.
| |
|
|
|
1.9, Аноним (-), 13:56, 09/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Никто не знает, появилась ли возможность указывать линкеру скрипт с расположением секций и участков памяти, как в gcc? Без этого собирать под embedded довольно проблематично, приходится отдельно линковать gcc-шным ld, а это уныло. :(
| |
1.13, Штунц (?), 16:15, 09/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| –1 +/– |
объясните, зачем этот режим интерпретатора "псевдокод может быть преобразован при помощи JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы"
| |
|
2.16, Andrey Mitrofanov (?), 17:27, 09/03/2016 [^] [^^] [^^^] [ответить]
| –2 +/– |
> объясните, зачем этот режим интерпретатора "псевдокод может быть преобразован при помощи
> JIT-компилятора в машинные инструкции непосредственно в момент выполнения программы"
Очевидно же! Чтобы выполняь маш.код вместо выполнения байт-кода. Это быстрее>/<
| |
|
1.14, Аноним (-), 17:09, 09/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +1 +/– |
Генерирует все такой же ужасный код на Hello world в 70 инструкций, в отличии от GCC
| |
|
|
|
4.30, 1 (??), 09:09, 10/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
однако если вместо
zero *= a;
написать
zero += (a + 1);
то сворачивает нормально.
| |
|
|
|
1.17, Андрей (??), 17:40, 09/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
Новость хорошая. Но на форониксе недавно тестировали, и оказалось, что самый быстрый код генерировал 3.6. У 3.7 результаты хуже, а у 3.8-snapshot - ещё хуже. Странно.
| |
|
2.19, Andrey Mitrofanov (?), 17:55, 09/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
> Новость хорошая. Но на форониксе недавно тестировали, и оказалось, что самый быстрый
> код генерировал 3.6. У 3.7 результаты хуже, а у 3.8-snapshot -
> ещё хуже. Странно.
Действительно странно. Почему Вы не поминаете, что код из-под gcc был быстрее во всех случаях, кроме 1-2 (из 15 или 20, какжется).
| |
|
3.21, Андрей (??), 18:26, 09/03/2016 [^] [^^] [^^^] [ответить]
| +2 +/– |
Вообще-то я говорил исключительно о развитии llvm (а не о сравнении с gcc). Ведь это должно быть развитие, а не деградация. Сравнение с gcc - отдельный вопрос.
| |
3.23, Андрей (??), 18:52, 09/03/2016 [^] [^^] [^^^] [ответить]
| +/– |
А ещё по тестам он от версии к версии всё медленнее компилирует. А именно скорость компиляции вообще-то является его замечательной отличительной особенностью.
| |
|
4.24, Andrey Mitrofanov (?), 19:16, 09/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> А ещё по тестам он от версии к версии всё медленнее компилирует.
> А именно скорость компиляции вообще-то является его замечательной отличительной особенностью.
-O0, tcc и pcc в помощь.
| |
|
5.29, Андрей (??), 06:06, 10/03/2016 [^] [^^] [^^^] [ответить]
| –1 +/– |
как современного оптимизирующего компилятора как Си, так и Си++.
| |
|
|
|
2.20, Andrey Mitrofanov (?), 18:07, 09/03/2016 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Новость хорошая. Но на форониксе недавно тестировали, и оказалось, что самый быстрый
> код генерировал 3.6. У 3.7 результаты хуже, а у 3.8-snapshot -
> ещё хуже. Странно.
Где это было? Вот тут http://www.phoronix.com/scan.php?page=article&item=ubuntu-1604-compilers&num= Ларабель весь обизворачивался, рассказывая, как "не намного" (но много раз...) llvm отстаёт от gcc. Но там, кажется, нет 3.6.
Где он сравнивал 3.6 с 3.8? Или "недавно тестировали" заключалось в сложении "в уме" сравнений 3.6 с 3.7 и 3.7 с 3.8?
| |
|
1.28, Аноним (-), 01:03, 10/03/2016 [ответить] [﹢﹢﹢] [ · · · ]
| +/– |
>Из параллельно **развивающихся** проектов, основанных на LLVM, можно отметить:
>LLVM-Lua
>Самый новый коммит 4 года назад
Убери, оно протухло
| |
|