Новый проект IBM по усовершенствования поддержки нитей в GNU/Linux

Не понял, в новых нитях что хорошего - performance improvements или capabilities с irix и aix?

Сдается мне что это попытка перетянуть Posix threads к стандарту AIX, IRIX - если честно то не знаю насколько хороши эти threads'ы в AIX, IRIX. Потом Sun возьмется за дело и будет тянуть на себя :)

А чем их не устраивают pthread_xxx?

Давно пора. А то клонирование процессов несет в себе слишком много ограничений.

lb: ты понял что сказал?

Очень даже. Сравни работу потоков/нитей в Windows и в Linux. Уж на что я поклонник Линуха, но тут он проигрывает по всем статьям.

по каким статьям? скорости? надежности?

как минимум функциональности - я сейчас портирую прилагу из Windows и Linux, так pthreads мягко говоря не дотягивают...

2chuchelo: Функциональности и ресурсоемкости. Нет возможности запустить несколько ниток в пределах одного процесса.

Точнее говоря, если надо распараллелить выполнение в одном месте программы, в Линухе приходится создавать полную копию текущего процесса. В виндах -- на раз. Вызовом одной функции.

Все *threads которые я видел под Линух используют fork(). След-но обладают всема причитающимися недостатками ;-(((

Кто помнит что я говорил на тему зачем IBM поддерживает линукс? Не правда ли эта ветка хорошое док-во моих слов...;)

2lb: к слову - похоже Вы согласны что линукс проигрывает виндам по поддержке SMP? :)

Я думаю, что в свете http://www.zdnet.com/zdnn/stories/news/0,4586,2685122,00.html IBM решил начать ценовую войну с Sun.

Что-то Вы, Irsi, "гоните" в этот раз. У нас posix-threads нет, это да, вернее, если быть честным, то у нас вообще нормально работающих threads нет. :( Но при чем здесь SMP -- я не пойму.

P.S. Irsi, я надеюсь, Вы не разделяете заблуждение, что добавив -lpthread Вы автоматически получите параллелльно исполняющуюся программу. :)

Yesssssssssssss!!! Наконец-то! Ещё б VM от BSD перетянули... Чтоб fork быстрым был... :)))))))))))))

К SMP имеет прямое отношение kernel multi-threading. Так что не трогайте Irsi. На Linux ниток нет и не будет из-за архитектурных особенностей. Они бы лучше озаботились развитием Hurd, у которого с нитками все в порядке.

Интересно имеет ли шанс эта штука попасть в официальный Linux?
Я слышал, что Линус ни в какую не хочет появления в Linux нормальных Posix threads, идо считает, что они suxx, а придумать что-нибудь лучше что бы ему понравилось тоже ни у кого не получилось пока.
--
Nik

2Dronov: нет, я не настолько наивен...:)
А на счет как треды и SMP к друг-другу относятся Вам рассказать или сами догадаетесь? :)

BTW нормальная работа с SMP возможна не только с помощью threads. так что нефиг нести бред про зависимость качества SMP и реализации threads.
Может вы помните, что раньше threads небыло ни в каких юниксах, но это не мешало делать распараллеливаемые системы,
--
Nik

2Nik: ну расскажите про "нормальную работу с SMP без threads" А я с удовольствием послушаю...:)

P.S. Раньше нормально работали и вообще без всяких ОС, FS и прочей муры...:)

Хмм, Вам SMP как самоцель? "Шоб було"? :) Тогда без threads никак, но это ничем не отличается от упомянутого мной клинического случая святой веры в -lpthread. :) Точнее, у всех, кроме NT и Solaris "никак".

А для распараллеливания... Можно "10 преимуществ threads перед fork не употребляя 'если' и 'но'"? :))

Это я к тому, что людей, умеющих грамотно "параллелиться" через fork, намного больше, чем тех, кто умеет то же, но через threads. Неправильно сказал, точнее так: все, кто может "распараллелиться" на fork, безусловно, может это сделать и на threads, но вот вообще таких _очень_ мало.

2lb:
> Все *threads которые я видел под Линух используют fork()
Вы, наверное, имели в виду clone() ?
> След-но обладают всема причитающимися недостатками ;-(((
И какими же?
Опять сейчас пойдет этот бред про "легкие нити", "ядерные нити"...

Мне почти всегда хватало system() :)

SMP -- ОЧЕНЬ специфическая штука, и использовать ее в
повседневной жизни, как принято в NT...

Можно, конечно, микроскопом гвозди заколачивать...

Простой пример: запустите time <ваша любимая программа>,
и посмотрите, сколько времени она провела в режиме ядра.
И осознайте, что всеми любимое ядерное распараллеливание
максимум поделит это (ничтожное!) время между процессорами.
(Если, конечно, Вы не пишете real time server.)

lb: Ваше незнание linux-threads так и прет наружу. Функциональности им не занимать, просто ваших знаний не достаточно. Linux-threads это почти полное соответсвие posix, а в посиксе всего хватает. Быстродействие: не путайте fork() котоый создает новый процесс и clone() который создаеи урезанный процесс (то есть thread). Многоие программы "в целях совместимости" были написаны с использованием fork вместо threads, я думаю это никак не проблема линукса а проблема этих программ.

Вот, вот! Irsi, вот именно об этом я и говорил. В _реальном_ мире SMP и threads не соотносятся _НИКАК_ ("... Linux-threads это почти полное соответсвие posix...", ужас) просто потому что почти никто "это" не использует (что я и говорил раньше).

2 Irsi: насчет SMP тебе вроде уже ответили. могу повторить -
man fork; man signal, man kill, etc
--
Nik

В Linux Threads действительно кое чего не хватает до полной совместимости с POSIX Threads. Поэтому это просто здорово если кто-то доведет поддержку POSIX Threads до ума.

Задача в процессе выполнения создает 100 ниток.
1xPII-266 128 RAM: НТ - 18:04 мин, linux - 17:43
2xPIII-850 256 RAM: НТ - 5:35, linux - 8:11.
4xPIII-800 2048RAM: НТ - 2:52, linux - 6:02 ;-((( Код один о тот-же. Никаких GUI.

lb: для 2.2.x так оно и было, в связи с плохой маштабируемостью, но однако уже 2.4 на дворе

2chuchelo: 2.4.0-test10 ;-))) SMP в 2.2.x очень медленно перебрасывает управление. Плюс у меня были проблемы с shm-locks ;-(((

2 lb:
А что софтина-то делает (с диском сильно работает, что-то считает или что)?
Интересно, какая будет длительность работы проги на FreeBSD и Solaris x86 на тех же железках...

2hvv: Голая математика (FP). Память используется не очень -- в своп не залазит. HDD I/O = 0. Тормоза определяются именно process manager-ом и SMP.
На фре не пробовал. Будет время -- попробую. С solaris знаком только "визуально" -- смотрел на Sun ~93 года рождения ;-((

А что такое FP? На чем все писано? Мне почему-то кажется, что SMP вообще не виновато особо - может просто под линуксом другой доступ к памяти (в смысле, типа он L2-кэш просто отрубает...) или просто драйвера для чипсета не используются. Вообще, память сильно задача юзает? А юзание nice не как не влияет?
Я бы порекомендовал такой тест: выделяется память (например 128 мегов) и каждый из потоков ее только читает (скажем 10000 раз) - без всяких блокировок, мьютексов и пр. Второй вариант (лучше и первый попробовать конечно) - каждый поток пишет в свой диапазон памяти (то есть диапазоны не пересекаются), без всяких блокировок. Было бы интересно посмотреть на время выполнения подобных задач на линухе и винде.
И еще - имело бы смысл попробовать 2.4 тоже наверно..

lb: все с тобой ясно... 2.4.1 однако последнее...

2hvv: FP = floating point. Вся память выделяется статически, до начала замеров. Так что дело в количестве процессов использующих CPU.

2chuchelo: Если ты позволишь мне иметь собственное мнение, то я скажу -- test10 _намного_ лучше работает чем все последующие. С pre3 вроде ситуёвина улучшается, а там посмотрим.

Товарищи "портеры" 8-) а причем здесь *fork и нити в Линуксе?
то что на каждую нить ты видешь свою запись в ps еще не говорит о том что выполнился fork

Товарищи "портеры" 8-) а причем здесь *fork и нити в Линуксе?
то что на каждую нить ты видешь свою запись в ps еще не говорит о том что выполнился fork
для тестов используется pthread_create или clone (без обвязки?)
> Задача в процессе выполнения создает 100 ниток.
> 1xPII-266 128 RAM: НТ - 18:04 мин, linux - 17:43
> 2xPIII-850 256 RAM: НТ - 5:35, linux - 8:11.
> 4xPIII-800 2048RAM: НТ - 2:52, linux - 6:02 ;-((( Код один о тот-же. Никаких GUI.
интресно услышать кстати обьяснение чем же занимается НТ на 1 процессоре так долго
разница далеко не в 4 раза между 2:52 и 18:04
т е что-то там плохо совсем в однопроцессорной конфигурации
или прога меряет таки попугаи

Сорри - нен увидел что машины разные 8-(

> Точнее говоря, если надо распараллелить выполнение в одном месте программы, в Линухе приходится создавать > полную копию текущего процесса. В виндах -- на раз. Вызовом одной функции. > Все *threads которые я видел под Линух используют fork(). След-но обладают всема причитающимися недостатками > ;-((( кстати откуда эта инфа? все в Линуксе работает через clone с разными флагами, но не в коем случае не через fork не в коем случае. кстати можно ли глянуть на тестовую прорамму в исходниках?

Замеры приведены с clone().

Гыгы, вот замеры произведены: 1xPIII 800 NT-30:17 linux-28:02 2xPIII 800 NT-17:58 linux-12:17 4xPIII 800 NT-10:12 linux-6:03 что тестировали, как тестировали, наверное не важно P.S. от фанаря написал, так что не просите ничего :-)

#include <pthread.h>
#include <stdio.h>
                                                                                                                                            void *my_pthread_func(void *){
	pthread_exit(NULL);
	return(NULL);
};

int my_pthread_create(pthread_t *id){
	pthread_attr_t attr_p;
	pthread_attr_init(&attr_p);
	pthread_attr_setdetachstate(&attr_p,PTHREAD_CREATE_JOINABLE);
	pthread_attr_setscope(&attr_p,PTHREAD_SCOPE_SYSTEM);
	if (pthread_create(id,&attr_p,my_pthread_func,(void *)NULL)){
		return(-1);
	};
	return(0);
}
int main(){
	int i;
	pthread_t id;
	void *result;
	for (i=0;i<100000;i++){
		if (my_pthread_create(&id)==0)
			pthread_join(id,&result);
		else{
			printf("Failed!\n");
			break;
		};
	};
	return(0);
};

-------------------------------------------------
тестовая прога, машина Celeron 700Mhz (256Mb RAM)
time test_prog
ядро 2.2.18
real 5.991
user 1.430
sys 4.560

ядро 2.4.0
real 8.682
user 1.700
sys 6.980
---------------------------------------------------
интересно как с SMP это дело будет работать?

2chuchelo:
Давай мылом. lbast@mail.ru