The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

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

"Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от opennews (??) on 04-Дек-11, 21:07 
Ресурс Phoronix провёл (http://www.phoronix.com/scan.php?page=article&item=gcc_42_47...) тестировние производительности кода, собранного различными версиями GCC (4.2.4, 4.3.6, 4.4.6, 4.5.3, 4.6.1 и 4.7-dev). Тестирование было выполнено на системе с процессором AMD FX-8150, основанным на новой архитектуре AMD Bulldozer. Сборка была произведена с опциями "-march=native -mtune=native -O3".


В тесте C-Ray отмечается заметное повышение производительности при использовании тестового снапшота GCC 4.7. В тестах LAME и  Flac заметен небольшой прирост производительности при использовании GCC 4.7. В тестах 7-Zip и FFmpeg все версии GCC показали примерно одинаковые результаты. В тесте GraphicsMagick отмечается существенное замедление работы при использовании GCC 4.7, в  то время как GCC 4.6.1 показал наилучшие результаты. При измерении времени сборки PHP и Apache, отмечается небольшое уменьшение скорости сборки в GCC 4.7.
<center><img src="http://www.opennet.dev/opennews/pics_base/3...

URL: http://www.phoronix.com/scan.php?page=article&item=gcc_42_47...
Новость: http://www.opennet.dev/opennews/art.shtml?num=32461

Ответить | Правка | Cообщить модератору

Оглавление

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


2. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 04-Дек-11, 21:11 
зачем -O3 ??
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

3. "Оценка производительности GCC на новых процессорах AMD"  +3 +/
Сообщение от XPEH email on 04-Дек-11, 21:34 
Патамушта эта крута. Фороникс же.
Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

44. "Оценка производительности GCC на новых процессорах AMD"  +1 +/
Сообщение от Аноним (??) on 05-Дек-11, 15:14 
> Патамушта эта крута. Фороникс же.

Ну вы же не сделали бенчмарков лучше. Вот и приходится довольствоваться форониксом.

Ну, покажите всем вашу круть! Сделайте лучше! (А мы обосрем, как вы фороникс)

Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

4. "Оценка производительности GCC на новых процессорах AMD"  +2 +/
Сообщение от Аноним (??) on 04-Дек-11, 21:39 
> -march=native -mtune=native

Что за нелепый набор опций? AFAIK, -march оптимизирует под конкретную модель процессора с потерей совместимости со всеми остальными, -mtune оставляет совместимость ценой недостаточной оптимизации (т.е., например, инструкции нового процессора не используются)

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

8. "Оценка производительности GCC на новых процессорах AMD"  –1 +/
Сообщение от Анонимко on 04-Дек-11, 22:17 
>-march оптимизирует под конкретную модель процессора

А что по-твоему делает -mcpu?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

9. "Оценка производительности GCC на новых процессорах AMD"  +3 +/
Сообщение от Аноним (??) on 04-Дек-11, 22:22 
Это устаревший аналог -mtune
Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

15. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 00:56 
> с потерей совместимости со всеми остальными, -

Ну так фороникс тестил чего в принципе можно выжать на бульдозере. А зачем вам совместимость с атомом если у вас бульдозер и вы билдите лично для себя, например?

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

17. "Оценка производительности GCC на новых процессорах AMD"  +5 +/
Сообщение от Аноним (??) on 05-Дек-11, 01:10 
Для этого есть -march, и как раз его надо было использовать. Для сохранения совместимости есть -mtune, а Похороникс умудрился заюзать оба сразу. Это похоже на попытки ниасилившего ман ламера напихать побольше ключей, "шоп наверняка". Хорошо еще, что не указали сразу x86 и x64
Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

21. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 08:40 
> Для этого есть -march, и как раз его надо было использовать. Для
> сохранения совместимости есть -mtune, а Похороникс умудрился заюзать оба сразу.

Ну да, однако тут вполне работает принцип "кашу маслом не испортишь". В смысле, форсануть набор команд в именно такой, а потом еще и захинтить что надо оптимизить под этот же проц вроде ничему такому особо не противоречит, хоть и избыточно.

> Это похоже на попытки ниасилившего ман ламера напихать побольше ключей, "шоп наверняка".
> Хорошо еще, что не указали сразу x86 и x64

Да я не сомневаюсь что лэйбаки клеить проще чем бенчи проводить. Поэтому читаем мы все-таки похороникса, у которого хоть какие-то бенчи есть.

Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

27. "Оценка производительности GCC на новых процессорах AMD"  –4 +/
Сообщение от Клован on 05-Дек-11, 09:10 
Да, все верно. Но компилируется же исходник на стороне пользователя, и ему такая оптимизация очень даже.
А... Забыл, на линуксе ведь все распространяется через собранные где то там под каким то там железом пакеты? Ну чтож, ССЗБ. Этой проблемы в FreeBSD нет например. Потому что опенсорс - это способность собирать из сорцов. И не надо кричать, что "долго ждать пока все соберется" - при сегодняшних мощностях железа это уже минуты.  
Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

33. "Оценка производительности GCC на новых процессорах AMD"  +3 +/
Сообщение от daks (ok) on 05-Дек-11, 10:56 
Открой для себя Gentoo и производные (Sabayon, Calculate и тп.), о юный адепт бсд. Хотя чё й то я такого толстого кормлю..
Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

34. "Оценка производительности GCC на новых процессорах AMD"  –6 +/
Сообщение от Клован on 05-Дек-11, 12:05 
> Открой для себя Gentoo и производные (Sabayon, Calculate и тп.)

Спасибо, только закрыл.

Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

37. "Оценка производительности GCC на новых процессорах AMD"  +1 +/
Сообщение от Аноним (??) on 05-Дек-11, 13:19 
> Спасибо, только закрыл.

Судя по тому, как вы распространялись выше о бинарных линуксах, слово gentoo вы явно увидели в первый раз.

Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

36. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 13:18 
> Забыл, на линуксе ведь все распространяется через собранные где то там под каким то там железом пакеты? Ну чтож, ССЗБ. Этой проблемы в FreeBSD нет например.

Вранье. Во фре тоже бинарные пакеты =)

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

38. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 13:24 
> Да, все верно. Но компилируется же исходник на стороне пользователя, и ему такая оптимизация очень даже.

Как показывали неоднократные бенчмарки, компиляция под конкретный проц дает в среднем 1-2% прироста производительности. С точки зрения обычного пользователя, игра не строит свеч.

> И не надо кричать, что "долго ждать пока все соберется" - при сегодняшних мощностях железа это уже минуты.

Ну, если кому-то мамочка постоянно дает деньги на топовый игровой комп...
А у людей, которые ценят свои деньги и адекватно расходуют их, компы обычно не самые топовые. И на установку крупных пакетов софта могут уходить часы. Учитывая необходимость периодических обновлений, этот пресловутый 1% прироста в любом случае не оправдан.

Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

41. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от фтыш on 05-Дек-11, 14:19 
Ох уж эти сказочники.
У меня на одноядерном атлоне за 5 лет использования генту статистика дает следующее - на сборку тратится в среднем 5-10 минут 100% загрузки CPU в день.
Да у меня проигрывание видео с pp7,hqdn3d,gradfun на порядок-два больше забирает ресурсов.
Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

42. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от FractalizeR email(ok) on 05-Дек-11, 14:31 
GIMP сколько собирается?
Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

58. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Он (??) on 28-Дек-11, 17:02 
Wed Oct 19 18:27:52 2011 >>> media-gfx/gimp-2.6.11-r5
       merge time: 4 minutes and 12 seconds.
Ответить | Правка | ^ к родителю #42 | Наверх | Cообщить модератору

43. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от vayerx (ok) on 05-Дек-11, 15:08 
specifying -march=cpu-type implies -mtune=cpu-type

-mtune=cpu-type
Tune to cpu-type everything applicable about the generated code, except for the ABI and the set of available instructions.

-march=cpu-type
Generate instructions for the machine type cpu-type. The choices for cpu-type are the same as for -mtune. Moreover, specifying -march=cpu-type implies -mtune=cpu-type.

Ответить | Правка | ^ к родителю #4 | Наверх | Cообщить модератору

12. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 00:12 
Да фигня это все. Сегодня есть проблема, а завтра пофиксили. В Bulldozer есть издержки из-за архитектуры, но и это компенсируется с лихвой. Сейчас качество софта и прямота рук программиста куда важнее чем микрооптимизация.

P.S.: А с -O3 я бы не стал собирать, так как бывают проблемы. Кому интересно - попробуйте собрать zlib, firefox (вероятно в новых версиях уже пофиксили).

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

22. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 08:57 
> P.S.: А с -O3 я бы не стал собирать, так как бывают проблемы.
> Кому интересно - попробуйте собрать zlib, firefox (вероятно в новых версиях уже пофиксили).

Бывают, факт. Что-то сверх -O2 и -Os - для любителей поэкспериментировать.

Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

13. "Оценка производительности GCC на новых процессорах AMD"  –1 +/
Сообщение от anonymous (??) on 05-Дек-11, 00:12 
И откуда такая регрессия в производительности? gcc начал скатываться?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

16. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 01:06 
>И откуда такая регрессия в производительности? gcc начал скатываться?

Нет, скорее регрессия от того что архитектура новая и, как и полагается, под новую архитектуру надо соответствующие способы тюнинга кода. Ничего страшного в этом нет - код дополнят/доработают под новые требования.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

18. "Оценка производительности GCC на новых процессорах AMD"  +1 +/
Сообщение от anonymous (??) on 05-Дек-11, 03:32 
4.7 != 4.6, и выйдет только в марте или апреле 2012г. http://gcc.gnu.org/ml/gcc/2011-11/msg00200.html

Ваш К. О.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

19. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от ананим on 05-Дек-11, 06:43 
Угу.
В 3 тестах увеличение производительности, в 2 примерно таже и в 1 уменьшение.
Тролячий вывод на лицо — ажназначна начал скатываться.
Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

23. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 08:58 
> И откуда такая регрессия в производительности? gcc начал скатываться?

Наверное оттуда что это хрензнаеткакая экспериментальная версия :)). А вам gcc чем-то мешает жить что вы ему пытаетесь приписать что-нить нелестное?

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

31. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от kuku on 05-Дек-11, 10:19 
Первое
Знаешь, я незнаю строение компилятора, но знаю одно:
что на стадии генерации инструкции процессора происходит
глубокий анализ и переработка инструкции в несколько
проходов. А это значит, что компилятор на N-ом проходе
по тем или иным признакам ищет цепочку инструкций которую
можно оптимизировать.

Второе
С архитектурой процессоров знаком ? Например, что такое
конвейер ? Сколько их в ядре ? Сколько ядер в процессоре ?
Сколько процессоров в системе ? Сколько диспетчеров, то есть
координирующих узлов в системе или процессоре ?
А может это не процессор, а нечто имеющее несколько
вычислительных узлов и мощный, многоуровневый менеджер памяти ?

Третье
Компилятор поддерживает ли "специфику" той системы на которой он
работает ? Хорошо ли согласуется выполнение программы с
операционной системой ?

Подумай...
Посмотри на PathScale...

А GCC эээ... это как бы компилятор рассчитанный на поддержку
многих платформ, или систем, кому как. То есть что-то близко
к универсальному... Да ?

Если есть ошибки поправьте.

Ответить | Правка | ^ к родителю #13 | Наверх | Cообщить модератору

14. "Оценка производительности GCC на новых процессорах AMD"  +1 +/
Сообщение от Аноним (??) on 05-Дек-11, 00:49 
Это важно насколько долго собирается софт? Пусть собирается сутки, но работает на 2% быстрее.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

20. "Оценка производительности GCC на новых процессорах AMD"  +1 +/
Сообщение от dalco (ok) on 05-Дек-11, 07:52 
Зависит от...

Если софтина будет годами крутиться на кластере из тысяч нод, то, ясен пень, лишние сутки сборки роли не играют.

Если требуется замутить нечто одноразовое, выдающее результат через 10 секунд расчетов, то ждать сборки лишние сутки, мягко говоря, не оптимально.

Ваш К.О.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

26. "Оценка производительности GCC на новых процессорах AMD"  –1 +/
Сообщение от Аноним (??) on 05-Дек-11, 09:06 
>кластере из тысяч нод
>AMD

Сомнительно.

Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

30. "Оценка производительности GCC на новых процессорах AMD"  +1 +/
Сообщение от Аноним (??) on 05-Дек-11, 09:55 
http://www.nccs.gov/computing-resources/jaguar/
Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

29. "Оценка производительности GCC на новых процессорах AMD"  –1 +/
Сообщение от iZEN (ok) on 05-Дек-11, 09:48 
> Это важно насколько долго собирается софт? Пусть собирается сутки, но работает на 2% быстрее.

В системах с непрерывной интеграцией ВАЖНО сколько времени отводится на сборку ПО. Так как непрерывный цикл разработки предполагает быстрые изменения, а C++ ещё не научили модульности на уровне исходного кода (в отличие от Pascal и Java), когда единицей компиляции является один файл, а для его компиляции нужны только уже откомпилированные бинарные модули (.tpu в архаичном Borland Pascal, .dcu в устаревшем Delphi, .class в Java и т.д.). Для сборки больших C++ программ приходится изобретать различные ухищрения, так как компиляция фактически сборной простыни из "инклюдов", собранной препроцессором из исходников, отнимает непозволительно много времени.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

35. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 13:12 
я конечно, не профессионал, но... *.o файлы не то же самое?

и Pascal и Java "компилируются" в байткод.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

46. "Оценка производительности GCC на новых процессорах AMD"  –1 +/
Сообщение от Аноним (??) on 05-Дек-11, 15:26 
> В системах с непрерывной интеграцией ВАЖНО сколько времени отводится на сборку ПО.

Отсюда вытекает мораль: тебе и твоей бсде в продакшне делать нечего. Большинству людей в хрен не вперлась какая-то там непрерывная интеграция, им непрерывно работающие системы нужны. Стабильно. Чем системы с непрерывной интеграцией как-то не очень могут похвастать - такой принцип автоматически подразумевает риск отвала башки.

Для сравнения: в бинарном дистре линукса на компиляцию тратится 0 минут 0 секунд, а грабли с пакетами вообще майнтайнеры разгребают. Что как-то сильно рулит когда надо достигать результатов а не страдать фигней с постоянной пересборкой там и тут.

> Так как непрерывный цикл разработки предполагает быстрые изменения, а C++ ещё
> не научили модульности на уровне исходного кода (в отличие от Pascal и Java),

С нетерпением жду когда ты уже перепишешь свою систему на паскаль или яву :D

> фактически сборной простыни из "инклюдов", собранной препроцессором из исходников, отнимает
> непозволительно много времени.

Так и скажи, не осилил пересборку только измененного :)

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

52. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Ytch on 05-Дек-11, 22:46 
>> фактически сборной простыни из "инклюдов", собранной препроцессором из исходников, отнимает непозволительно много времени.
> Так и скажи, не осилил пересборку только измененного :)

Еще про precompiled header расскажи...

Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

51. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 22:45 
.tpu в архаичном Borland Pascal, .dcu в устаревшем Delphi, .class в ненужной Java

извините, не удержался :)

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

53. "Оценка производительности GCC на новых процессорах AMD"  +2 +/
Сообщение от Аноним (??) on 05-Дек-11, 22:59 
В основном C++ долго компилируется, т.к. язык намного сложнее для разбора, в сравнении с Pascal/Java. Это плата за те выразительные возможности, гибкость и мощь, который получает разработчик.

Меры ускорения сборки в C++ (то что сходу вспомнил):
- предварительные объявления в .h-файлах вместо инклудов
- идиома PIMPL (по крайней мере для библиотечных классов и классов инструментария проекта)
- закешированные скомпилированные единицы трансляции (объектные файлы .o) не перекомпилируются при следующей сборке, пока сами исходники не изменятся
- грамотно разбивать части проекта на отдельные либы (пусть даже статические), подпроекты и приложения - чтобы каждый раз не собирать 100500 исходников
- делать прекомпилированные хедеры
- для сборки на многоядерных процах - использовать опцию -j
- есть также системы для сборки проекта на нескольких компах
- не использовать ущербный mingw (не сидеть под оффтопиком), писать на linux, а под оффтопик кросскомпилировать через линуксовый mingw только для финальных релизов и тестов (если позволяет проект)

В общем, если сильно захотеть - всё делается. К тому же эти вещи нужно бы делать вне зависимости от наличия/отсутствия модульности, т.е. это не "различные ухищрения". И да, как бы вам не нравился C/C++ - но других языков с такой же эффективной компиляцией в нативный код не придумали пока, да и не нужно. Про управляемый код даже говорить не буду - попросту не нужно.

Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

39. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 13:27 
> Это важно насколько долго собирается софт? Пусть собирается сутки, но работает на
> 2% быстрее.

Если обновлять хотя бы раз в месяц, то 2% явно не оправдают потери 1/30 (3,3%) рабочего времени.

Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

40. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 13:28 
> Если обновлять хотя бы раз в месяц, то 2% явно не оправдают

А обычно оно гораздо меньше, повезет, если больше одного процента.

Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

47. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 15:27 
> А обычно оно гораздо меньше, повезет, если больше одного процента.

Correct. Но бывают случаи когда некое сочетание параметров может выстрелить и в пару раз. Типа как pathscale на амд в бенчах фороникса на паре тестов.

Ответить | Правка | ^ к родителю #40 | Наверх | Cообщить модератору

28. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 09:38 
У меня ОпенФоам, который окончательные вычисления делает больше недели на i7....
О3 - дает 10-30% ускорения (зависит от модели)
мне не ставить О3?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

32. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Аноним (??) on 05-Дек-11, 10:42 
с флагом компиляции -O3 велика вероятность получить глючный исполняемй код.
Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

45. "Оценка производительности GCC на новых процессорах AMD"  +1 +/
Сообщение от Аноним (??) on 05-Дек-11, 15:19 
С этим флагом велика вероятность не получить вообще никакого кода.
Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

49. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от okruzhor on 05-Дек-11, 18:00 
Извините , что мимо темы . Не нашёл , куда сообщать о технических проблемах . Не к модераторам же стучать ...

На многих беседах (и на этой тоже) одна беда : нельзя получить плоский вид с сортировкой постингов по времени . Нажатие на "сортировку по времени" переносит в "Релиз Linux-дистрибутива ZevenOS 4.0 ...."

Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

50. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Maxim Chirkov email(ok) on 05-Дек-11, 22:34 
> На многих беседах (и на этой тоже) одна беда : нельзя получить
> плоский вид с сортировкой постингов по времени . Нажатие на "сортировку

На какой странице (в новостях или форуме) и на какую именно ссылку вы нажимайте ? Каким браузером пользуйтесь. Выход в сеть не через прокси ?

> по времени" переносит в "Релиз Linux-дистрибутива ZevenOS 4.0 ...."

Такое ощущение, что у вас из локального кэша это выдаётся без обращения к сайту.

Ответить | Правка | ^ к родителю #49 | Наверх | Cообщить модератору

54. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от okruzhor on 07-Дек-11, 16:34 
>> На многих беседах (и на этой тоже) одна беда : нельзя получить плоский вид с сортировкой постингов по времени . Нажатие на "сортировку по времени"
> На какой странице (в новостях или форуме) и на какую именно ссылку вы нажимайте ? Каким браузером пользуйтесь. Выход в сеть не через прокси ?

На этой самой (новость) , ссылка "сортировка по времени" :-)

Opera 11.52 . Через прокси

> Такое ощущение, что у вас из локального кэша это выдаётся без обращения к сайту.

Да . У меня была отключена проверка обновления файлов в кэше . Получается , что для различных страниц с "сортировкой времени" генерируется одно и тоже имя файла в кэше ?

Включил такую проверку "всегда" . Сработало , после того как обновил страницу с сортировкой по ответам

Спасибо !

Ответить | Правка | ^ к родителю #50 | Наверх | Cообщить модератору

55. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от okruzhor on 07-Дек-11, 16:40 
Хм! Продолжаю оффтоп . Править моё сообщение движок не даёт , мол "не ваше" . Однако создавать сообщение под своим ником я могу ! Значит всяк может постить с любым ником ? Пробовать не хочу , но это странная авторизация ...

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

57. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Maxim Chirkov email(ok) on 07-Дек-11, 17:06 
> Хм! Продолжаю оффтоп . Править моё сообщение движок не даёт , мол
> "не ваше".

Править свои тексты можно войдя в форум как зарегистрированный пользователь.

> Однако создавать сообщение под своим ником я могу. Значит всяк может постить с любым ником ?

Если ник свободен то его можно свободно использовать. Если ник зарегистрирован, то написать под ним без входа в форум можно только специально указав это в настройках, по умолчанию ник резервируется. В случае ника "okruzhor" - это анонимный свободный ник, зарегистрируйтесь в форуме и он будет привязан к вашему аккаунту.

Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

56. "Оценка производительности GCC на новых процессорах AMD"  +/
Сообщение от Maxim Chirkov email(ok) on 07-Дек-11, 17:03 
> Да . У меня была отключена проверка обновления файлов в кэше .
> Получается , что для различных страниц с "сортировкой времени" генерируется одно
> и тоже имя файла в кэше ?

Да, при нажатии на ссылку сортировки по времени вызывается один скрипт, который устанавливает Cookie и делает редирект на основе содержимого http_referer.

Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

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

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




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру