Добро пожаловать в сеть Intel® Software Network вход | зарегистрироваться | помощь |
Поиск в форумах и блогах Intel® Software Network
в Вперед

общий вопрос

Последнее сообщение 06-21-2008, 17:19 размещено mt2. Ответов - 52.
Стр. 4 из 4(элементов - 53)   < Назад 1 2 3 4
Сортировать сообщения: Назад Вперед
 02-18-2008, 11:54 30221074 в ответ на30221073  

На: общий вопрос

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


 
 02-18-2008, 16:44 30221076 в ответ на30221074  

На: общий вопрос

А речь, в частности, идет и о проблемах управления проектами, когда язык добавляет проблем всему проекту. Типовой случай - это С++, со сверхбогатыми возможностями - множественное наследование, неоднозначности, низкоуровневые и т.д. Одни, как правило, более опытные, программисты видят в них потенциальный источник ошибок, относятся к таким возможностям очень сдержанно и пытаются применять их как можно реже, а что-то не применять совсем, зато другие видят в  этом мощь и гибкость языка и применяют все подряд без всякой меры. И вот представьте себе бедного руководителя проекта, к которому приходят два таких оппонента с противоположными взглядами и предъявляют взаимные претензии - один недоволен стилем другого, не хочет работать с таким кодом другого, и в результате проект тормозится. Как отмечал когда-то Кауфман - каждый высокоуровневый язык практически неизбежно имеет "темные места" (языковые ямы), но одни языки пытаются минимизировать их количество, а другие максимизируют в погоне за пресловутой гибкостью. Так что нашему руководителю как минимум придется отказаться от услуг одного из оппонентов или уволить сразу обоих, а в идеале сменить язык! Хуже, когда оппоненты разнесены по времени: типичный прием - все неудачи проекта списываются на неправильный стиль предшественника. Некоторых "прагматиков" низшего звена такое положение, видимо, устраивает - требуется минимум усилий на халтуру, еще и поэтому некоторые языки сегодня имеют ничем не объяснимую популярность. К сожалению, во многих институтах студентов учат именно этим языкам... А насчет четко задокументированного задания - увы! - данный конкурс прекрасная иллюстрация недостижимости идеала - даже экспертам Интела не удается четко сформулировать конкурсные задания, а ведь они (конкурсные задания) в общем-то искусственные и не такие сложные, не такие трудноформализуемые, как часто бывает на практике... Совершенно с Вами согласен, что документирование обязательное условие успеха проекта. Хороший однозначный код на подходящем языке обладает свойством самодокументируемости. Это очень важное свойство, дополняющее, но не отменяющее подробного документирования и детального тестирования.

-- Михаил.

 

 
 03-24-2008, 10:44 30221117 в ответ на30221076  

На: общий вопрос

"Theoretically the programs that use Intel's library will perform the best and there's no need to assign bonus points for this subjectively."

http://softwarecommunity.intel.com/isn/Community/en-US/forums/permalink/30251320/30251297/ShowThread.aspx#30251297

 
 04-13-2008, 20:24 30221198 в ответ на30221117  

На: общий вопрос

За время, прошедшее с последнего поста, количество просмотров этой темы увеличилось еще на 10 тысяч, а общее количество просмотров перевалило при этом за 60 тысяч  - умопомрачительная цифра для этого и других форумов Интел! И вот за это время поднакопился новый материал – конкурс-то идет своим ходом:

 

Во-первых, в шестом туре премию ожидаемо получило решение, сообщающее правильный или НЕправильный результат в зависимости от исходных данных - т.е. решение не совсем неправильное, а только частично – иногда оно все же дает и правильные ответы, можно только удивляться, что все 4 или 5 теста судей (или по-прежнему одного судьи?) такие, что ответ получается правильный и, естественно, самый быстрый. А что при беглом взгляде на алгоритм видно, что он не правильный, это никого, или почти никого, не взволновало (если не считать многочисленные посты участников на американском форуме). Впрочем, об этом уже и на этом форуме был небольшой обмен мнениями.

 

Во-вторых, в теперешнем седьмом туре судьи (судья?) решили (решил?) наступить еще раз на грабли первого тура (go on:)) и оценить быстродействие сортировки – в первом туре была «быстрая» сортировка, в этом сортировка «слиянием» - совместно с быстродействием ввода-вывода. Я, к примеру, получил следующие результаты: CPU Pentium-4 3.0 GHz, OS MS Windows XP SP 2, размер файла  2^26 целых чисел :

 

-         время, потраченное на чтение данных из входного файла 75 сек., время на сортировку 23 сек., время на запись 78 сек.,  (общее время 176 сек.).

 

А для другого жесткого диска и для другой копии Windows XP на том же компьютере я получил:

 

- время, потраченное на чтение данных из входного файла 30 сек., время на сортировку 22 сек., время на запись 141 сек.,  (общее время 193 сек.).

 

Можно начать сортировку, и не дожидаясь окончания чтения, - как только количество прочитанных данных достигнет объема, выделенного очередному потоку сортировки, – тут же этот поток запускать. Я попробовал, и получил общее время 154 сек. Кроме того, можно совместить финальное объединение отсортированных данных с выводом в файл – попробовал – получил 144 сек.

 

Очевидно, что для многоядерных CPU и для лучшей оптимизации алгоритма сортировки

различие между временем сортировки и временем на ввод-вывод будут еще значительней!

 

Что же показывают полученные результаты? А показывают они, что время работы программы (единственная, казалось бы, объективная характеристика решения, не зависящая от судейского произвола) при данной постановке задачи прежде всего зависит от размера файла, от физических характеристик диска (время доступа и т.д.), от формата диска  (FAT, NTFS, Linux форматы и т.д.), от истории диска (его фрагментации), а также от времени, идущего на процедуры стандартного ввода-вывода, которое скорее всего различно для разных компиляторов. И ТУТ МЫ ВОЗВРАЩАЕМСЯ К ТЕМЕ ДАННОГО СООБЩЕНИЯ в ее новой интерпретации – речь идет уже не только о языковой дискриминации, но о системной и компиляторной дискриминации! Теперь и С++ достанется – не факт, что все его I/O процедуры во всех компиляторах работают быстрее всех прочих компиляторов всех прочих языков. Прежде всего, у Юрия как разработчика МС#, появляется реальный шанс сделать специфически быструю процедуру заглатывания больших кусков текстового файла, состоящего из беззнаковых целых чисел по числу в строке… Остальные участники тоже могут оптимизировать свои решения под определенные размеры файлов, типы жестких дисков, и также могут попробовать заменить стандартные процедуры ввода-вывода на оригинальные ;) можно также попробовать организовать параллельное чтение разных кусков входного файла из потоков, рассматривая текстовой файл последовательного доступа как двоичный файл с произвольным доступом. Однако возникает вопрос: действительно ли оптимизация ввода-вывода является основной целью данного задания?

 

Кроме того, решение оптимальное под один тип дисков и под один размер файлов будет явно не оптимальным под другой тип дисков и другой размер входного файла :(

 

Пока с этим конкурсом перманентно продолжаются вышеуказанные перманентные заморочки, я решил мультипоточно попробовать другой конкурс Интел, тоже мультипоточный – может, старейшая игра в мультипоточном режиме будет успешнее – прочитать про нее и проголосовать за :) или против :( нее можно по ссылке: http://softwarecontests-rus.intel.com/gamedemo/entrydetail.php?entryid=95

 

-- Михаил (mt2)

 

 
 05-24-2008, 22:43 30221245 в ответ на30221198  

На: общий вопрос

Количество просмотров этой темы перевалило за 70 тысяч! ;)
 
 05-30-2008, 15:39 30221250 в ответ на30221245  

На: общий вопрос

mt2:
Количество просмотров этой темы перевалило за 70 тысяч! ;)

Это поисковики ее индексируют [;)]

 
 05-30-2008, 15:51 30221251 в ответ на30221250  

На: общий вопрос

YurySerdyuk:

mt2:
Количество просмотров этой темы перевалило за 70 тысяч! ;)

Это поисковики ее индексируют [;)]

И хорошо индексируют по сравнению с другими темами ;)

-- Михаил

 
 06-21-2008, 17:19 30221276 в ответ на30221251  

На: общий вопрос

mt2:
YurySerdyuk:

mt2:
Количество просмотров этой темы перевалило за 70 тысяч! ;)

Это поисковики ее индексируют [;)]

И хорошо индексируют по сравнению с другими темами ;)

-- Михаил

Уже 80 тыс. :) Ура поисковикам :)))

-- Михаил

 
Стр. 4 из 4(элементов - 53)   < Назад 1 2 3 4
Просмотреть как поток новостей RSS в XML

Ярлыки


Тег для данного сообщения

...

Теги сообщества

...