[странно, но факт] KDE 3 действительно хорош на 256Mb оперативки

Вброс

>не передергивай. IceWM как WM меня целиком и полностью устраивает - я использую его на совсем слабых машинах. Просто лично мне для комфортной работы нужен DE... Я МОГУ поставить скажем тот же IceWM+rox(idesk)+чо-то там, но это будет кагбе немного не то(хотя работать будет можно и вполне нормально). Главное - теснота интеграции. А тут WM не подходит, класс задач не тот. Тут нужен DE

я предпочитаю подбирать программы самостоятельно. Потому мне DE просто не нужен (как окружение). А вот скорость и память мне часто необходима. Даже если её не так уж и мало.

> Гном тормозит по сравнению с KDE4 даже на 2 гигах памяти.

4.2

Не осилил KScreenshot? :3

> КДЕ4 хорош всегда и везде.

у вас была описка, исправил

*ksnapshot

Даже iphone 3g будет быстрее этого ГМ.

> Я вот тут ткнул мышью рядом с K в третьих кедах, так у меня вся панель задач бесследно пропала, причём как её вернуть - решительно непонятно. К счастью, она появилась после рестарта. И в кедах всегда так было - баг на баге.

Не в «кедах», а в слаке

>Не в «кедах», а в слаке

в других дистрах тоже. Хотя и гном не лучше...

не был установлен.

А компилять на 500 MHz довольно нудно... ах да, gentoo, если что.

>в других дистрах тоже.

4.2

Нефиг звездеть о том, чего не знаешь

я пишу о том, что видел.

Это ты к чему?

Это я к тому, что бинарник выполняется практически с такой же скоростью, что и скрипт.

Вот как должен выполняться настоящий бинарник на той же машине:

int main(int argc, char *argv[])
{
    int d=1;
        for (int i=0;i<10000000;i++)
            d=d*i;
}

time test

real 0m0.054s user 0m0.050s sys 0m0.000s

>Фига се у тебя машинка. У меня на Q9440 вышло 0m2.251s

Дык Phenom X4 Mobile N930(2 GHz) =)

А тест действительно неубедительный, я как-то так написал, что даже не заметил, что там после умножения все время нуль будет в переменной =)

Это специальная кнопка сворачивания панели задач. Она опциональна

>А тест действительно неубедительный, я как-то так написал, что даже не заметил, что там после умножения все время нуль будет в переменной =)

Вы думаете, это как-то скажется на результатах? Конечно тело цикла можно вынести за сам цикл, но python этого не поймёт. Сомневаюсь, что даже g++ -O3 осилит такое.

>Это специальная кнопка сворачивания панели задач. Она опциональна

Это я понял. Вот только оно свернулось вместе с этой кнопкой. Т.е. закрыл, а открывать - нечем. Эпичный баг, причём не всегда проявляется.

>Вы думаете, это как-то скажется на результатах?

Конечно скажется.

Конечно тело цикла можно вынести за сам цикл, но python этого не поймёт. Сомневаюсь, что даже g++ -O3 осилит такое.

Это что еще за индусорешение и к чему это вообще? :)

>Конечно скажется.

каким образом?

Это что еще за индусорешение и к чему это вообще? :)

man оптимизация

>man оптимизация

Вам бы это, man «основы программирования»

>Вам бы это, man «основы программирования»

О великий Гуру!

Соизвольте объяснить, где и в чём я туплю? Ваш высокий полёт мысли непонятен мне, попрошу вас больше не изъяснятся в стиле «что за индусский код?», и «RTFM! ламо!», я не ваш ученик, и к огромному сожалению не читал ваших обширных и монументальных трудов. Вы можете подкинуть мне ссылок, на Ваш man про основы программирования, ибо в своих интернетах я его не смог отыскать :( (конечно это объясняется лишь тем, что меня забанили в гугле).

Соизвольте объяснить, где и в чём я туплю?

Да без проблем:

Вы думаете, это как-то скажется на результатах?

каким образом?

Объясняю:

d=1
for i in range(10000000):
   d=d*i

Работает _гораздо_ быстрее

d=1
for i in range(1,10000000):
   d=d*i

Потому что очевидно, что умножить 0 на 26 гораздо быстрее, чем 620448401733239439360000 умножить на 26 

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

Работает _гораздо_ быстрее

да?

doc@dt:~/tests$ time -p gcc -Wall test1.c -o test1
real 0.22
user 0.06
sys 0.01
doc@dt:~/tests$ time -p gcc -Wall test1.c -o test1
real 0.18
user 0.06
sys 0.02
doc@dt:~/tests$ time -p gcc -Wall test1.c -o test1
real 0.13
user 0.06
sys 0.02
doc@dt:~/tests$ sed 's/j = 0/j = 1/' test1.c 
int main()
{
	long long d, j;
	d = 1;
	for(j = 1; j < 1000000000000LL; j++)
		d *= j;
	return 0;
}
doc@dt:~/tests$ sed 's/j = 0/j = 1/' test1.c -i
doc@dt:~/tests$ gcc -Wall test1.c -o test1
doc@dt:~/tests$ time -p gcc -Wall test1.c -o test1
real 0.25
user 0.06
sys 0.01
doc@dt:~/tests$ time -p gcc -Wall test1.c -o test1
real 0.13
user 0.06
sys 0.01
doc@dt:~/tests$ time -p gcc -Wall test1.c -o test1
real 0.15
user 0.06
sys 0.02

вы таки не гуру. Да, действительно, операция imul выполняется за разное время (выполнялась до iPI без MMX), однако, с тех-же первопнёв мы научились распараллеливать операции, потому время выполнения нивелируется.

Всё дело в том, что компилятор умножает по частям (я использовал 32х битную архитектуру), и компилятор мешает инструкции умножения вместе с другими инструкциями, причём исходя из того, что инструкция будет выполнятся СРЕДНЕЕ время. Даже если инструкция умножения выполнится быстрее, этот конвейер будет ждать, пока выполнится другие инструкции. Кроме того, внутри CPU умножение тоже идёт по частям, и тоже всё распараллеливается с учётом среднего. Я точно не знаю, по сколько бит CPU умножает за раз, но уже начиная ЕМНИП с 80286 далеко не с одного, потому время выполнения imul вовсе не прямо пропорционально числу нулевых групп, а изменяется ступеньками. ЕМНИП в древности таких ступенек было 3 или 4, а сегодня похоже всего одна.

То, что умножение выполняется командой imul доказывает листинг программы (показать?). Впрочем, я не думаю, что это как-то отразится на 64х битной архитектуре - в конце концов, основное время в этой программе тратится на переходы и пересылки, а вовсе не на умножение. За счёт параллельного выполнения умножения, мы можем считать время выполнения imul равным нулю (sic!)

Всё было-бы намного веселее, если-бы компилятор множил числа в FPU используя MMX, тогда можно было-бы строго доказать, что время работы вообще не зависит от времени умножения (сам цикл выполняется настолько долго, что он заведомо дольше времени умножения). Мой компилятор так делать не стал, потому время исполнения может немного отличатся.

В любом случае, ваши слова о том, что множить на ноль намного быстрее - полная чушь. Никакой компилятор (а тем более интерпретатор) не умеет динамически переопределять типы, кроме того, кто вам сказал, что перемножить 8и битные числа в 4 раза быстрее чем 32х битные?! На 16и битном контроллере разве что.

Если-же ваш пайтон сочтёт, что числа надо обработать на FPU, то там вообще не будет никакой разницы - он ещё с 8086 работал параллельно, а числа там всегда 80и битные.

Да, а про пайтон - просто смешно: он на 2-3 порядка дольше парсит, чем умножает, потому вы можете использовать там любые числа - разницы не будет.

Да, и проверьте сначала... Мне лень, я писал про C, я это проверил.

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

RTFM

# Вычисление инвариантов циклов, вынесение общих подвыражений и кода в ветвлениях, вынесение ветвлений из циклов

http://ru.wikipedia.org/wiki/Оптимизация_компилятора

Тут мы имеем инвариантное выражение тождественно равное нулю. Если-бы ты написал не d=i*d, а d=i*0, то компилятор вынес-бы это тождество (d=0) из тела цикла. Ну а так-как сам цикл ничего не делает, то компилятор свернёт и его. А так-как его переменные никому не нужны, то компилятор вообще выбросит на* весь цикл КЕМ. И останется лишь

return 0;

Не надо спорить со старшими:

doc@dt:~/tests$ cat test1.c 
int main()
{
	long long d, j;
	d = 1;
	for(j = 1; j < 1000000000LL; j++)
		d *= 0;
	return d;
}
doc@dt:~/tests$ gcc -Wall -O3 test1.c -o test1
doc@dt:~/tests$ objdump -d test1
...
08048360 <main>:
 8048360:	55                   	push   %ebp
 8048361:	89 e5                	mov    %esp,%ebp
 8048363:	31 c0                	xor    %eax,%eax
 8048365:	5d                   	pop    %ebp
 8048366:	c3                   	ret    

Понял магию gcc -O3 ?

К сожалению, магию математической индукции компилятор пока не понимает, потому у него мозгов не хватило, понять, что если i0 == 0, то d*=iN тождественно равно нулю для любого N.

PS: что-то в прошлом посте я немного ошибся - не учёл, что компилятор выкинул мой цикл. по уточнённым данным время работы вообще не меняется, во всяком случае с -O3 на Celeron D 3000MHz, gcc --version 4.4.4.