ВУЗ для IT специалиста: взгляд изнутри

← →
картман © (2013-05-16 14:41) [80]

> Kerk © (16.05.13 14:31) [77]

> могу только свою имху транслировать

ну да, имха и интересовала))

> кто-то в Intel занимается распознаванием изображений и ИИ
> всякими. В первом случае крутая вышка действительно не нужна,
> а во втором не получится человека с улицы взять и натаскать,
> нужен какой-то фундамент.

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

> Что-то типа производственной практики могло бы помочь это
> исправить.

да, тут согласен на все 100

← →
Ega23 © (2013-05-16 14:42) [81]

> Я потому и настаиваю, что нужно сделать нормальные программистские
> техникумы (колледжи, как угодно назвать) и снять с ВУЗов
> нетипичную для них нагрузку.

В целом согласен.

← →
картман © (2013-05-16 14:45) [82]

> DevilDevil © (16.05.13 14:37) [78]
>
> > картман © (16.05.13 14:31) [76]
> >
> > > Я сначала оптимизировал на ЯВУ, а потом вообще реализовал
> > > на ассемблере
> >
> > и какой получился прирост скорости?
>
> дохрененный :)

Не верю. Если, конечно, по какой-то неведомой причине то же самое на асме получилось O(n), против какого-нибудь O(nLog(n))

← →
DevilDevil © (2013-05-16 14:50) [83]

> Ega23 © (16.05.13 14:41) [79]

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

Разумеется. Из постановки твоего вопроса я сделал вывод, что ты говоришь об общем случае. Для трёх элементов никаких алгоритмов сортировки не нужно. В следующий раз чётче формулируй условия вопроса. В любом случае, как я уже говорил, твой пример ничего общего с предметами высшей математики, преподаваемых в ВУЗ-ах - не имеет

← →
DevilDevil © (2013-05-16 14:56) [84]

> картман © (16.05.13 14:45) [82]

> Не верю. Если, конечно, по какой-то неведомой причине то
> же самое на асме получилось O(n), против какого-нибудь O(nLog(n))

Хочется сказать "ты смешной", но боюсь, что опять сообщение удалят. Время выполнения кода зависит от объёма расходуемых тактов и задержек, а не от "временной сложности алгоритма". Стоит ли говорить, что Delphi имеет далеко не самый производительный компилятор. А разработчик, размышляющий в терминах ЯВУ может упустить факторы, доступные разработчику, размышляющему в системе тактов

← →
картман © (2013-05-16 14:59) [85]

> Время выполнения кода зависит от объёма расходуемых тактов
> и задержек, а не от "временной сложности алгоритма".

хотелось бы узнать, от чего зависит "объем расходуемых тактов"?

← →
Ega23 © (2013-05-16 15:03) [86]

> В следующий раз чётче формулируй условия вопроса.

Ты инженер-программист, или кодер, работающий строго по ТЗ? Если тебе непонятно - задай вопрос.
Собственно, изначально вопрос состоял в оценке выбора алгоритма в зависимости от количества элементов. И, на-минуточку, этим делом никто иной как матан занимается. Странно, правда? Но я вспомнил, математика же не нужна.

← →
Игорь Шевченко © (2013-05-16 15:03) [87]

если можно, все-таки в русле темы

← →
Romkin © (2013-05-16 15:06) [88]

> а все ж интересно, чего бы могли дать в ВУЗе? Не что дают,
> а взять идеал - вот что надо дать, чтоб выпускник был..
> . в общем, с корабля на бал - сразу по выпуску мог бы принести
> пользу ИТ-конторе, нанявшего его.

http://ocw.mit.edu/courses/electrical-engineering-and-computer-science/

← →
Ega23 © (2013-05-16 15:07) [89]

> Хочется сказать "ты смешной", но боюсь, что опять сообщение
> удалят. Время выполнения кода зависит от объёма расходуемых
> тактов и задержек, а не от "временной сложности алгоритма".
> Стоит ли говорить, что Delphi имеет далеко не самый производительный
> компилятор. А разработчик, размышляющий в терминах ЯВУ может
> упустить факторы, доступные разработчику, размышляющему
> в системе тактов

Какая разница? Хучь на ЯВУ, чучь сразу в машкодах - отношение вычислительных сложностей двух алгоритмов будет одинаковым. Может быть на асме чуть-чуть побыстрее. Но отношение будет одинаково.

← →
Думкин_ (2013-05-16 15:10) [90]

> Я потому и настаиваю, что нужно сделать нормальные программистские
> техникумы (колледжи, как угодно назвать) и снять с ВУЗов
> нетипичную для них нагрузку.

Так есть же уже.

← →
Ega23 © (2013-05-16 15:11) [91]

> Romkin © (16.05.13 15:06) [88]

Ну MIT недаром ВУЗом №1 считается в планетарном масштабе...

← →
Ega23 © (2013-05-16 15:11) [92]

> Так есть же уже.

Мало пока.

← →
DevilDevil © (2013-05-16 15:12) [93]

Удалено модератором

← →
DevilDevil © (2013-05-16 15:12) [94]

Удалено модератором

← →
DevilDevil © (2013-05-16 15:19) [95]

Удалено модератором

← →
Ega23 © (2013-05-16 15:21) [96]

Удалено модератором

← →
DevilDevil © (2013-05-16 15:21) [97]

> Ega23 © (16.05.13 15:11) [91]

> Какая разница? Хучь на ЯВУ, чучь сразу в машкодах - отношение
> вычислительных сложностей двух алгоритмов будет одинаковым.
> Может быть на асме чуть-чуть побыстрее. Но отношение будет
> одинаково.

Алгоритмическая сложность одна. Производительность принципиально разная. Вот и вся разница

← →
DevilDevil © (2013-05-16 15:23) [98]

Удалено модератором

← →
картман © (2013-05-16 15:25) [99]

> DevilDevil © (16.05.13 15:21) [97]
> Алгоритмическая сложность одна. Производительность принципиально
> разная. Вот и вся разница

я у тебя спрашивал: какая разница между реализациями одного и того же алгоритма на яве и на ассемблере?

← →
Ega23 © (2013-05-16 15:25) [100]

> Алгоритмическая сложность одна. Производительность принципиально
> разная. Вот и вся разница

Для отношения????
Ну извините, почтительно умолкаю и отваливаю в сторону.

← →
DevilDevil © (2013-05-16 15:34) [101]

> картман © (16.05.13 15:25) [99]

> я у тебя спрашивал: какая разница между реализациями одного
> и того же алгоритма на яве и на ассемблере?

ты наверное имеешь ввиду не Яву, а ЯВУ :)
я сравнивал, но это года 3 назад было

давай приведу пример из недавней жизни
Недавно я выложил в общий доступ библиотеку CachedBuffers. А потом ещё доделывал потихоньку. Вот скриншот одного из бенчмарков последней версии:
http://a.fsdn.com/con/app/proj/cachedbuffers/screenshots/screen_writing.png

Данный бенчмарк выполняет запись 100мб текстового файла.
Обрати внимание на запись "Simple CachedFileWriter"
В рамках этой реализации многократно вызывается метод "класса" (как у TStream):
procedure Write(const Buffer; const Count: integer);

Смысл этого метода в том, чтобы скопировать кусок памяти во внутренний буфер, применяя ряд условий, немного логики. Так вот раньше этот метод был реализован на ЯВУ и реализация выполнялась больше секунды. Сейчас она частично переписана на ассемблер и выполняется 265 миллисекунд. Получается разница где-то в 4 раза. Вот тебе и пример.

← →
Romkin © (2013-05-16 15:36) [102]

> и где остался твой матан, когда ты реализовал сортировку
> деревом (небалансированным) вместо хеша, и TList вместо
> одно/дву связного списка? Я молчу про string вместо pchar

Вся беда в том, что те, кто не получил хорошего образования, просто не замечают его отсутствия. Поэтому и считают, что оно ничего особого не дает.
Спорить зачем? Посмотри http://www.eecs.mit.edu/academics-admissions/undergraduate-programs/course-6-3-computer-science-and-engineering что там требуется, диаграмма связей есть. Это - минимум :)

← →
знайка (2013-05-16 15:36) [103]

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

← →
Kerk © (2013-05-16 15:38) [104]

> Думкин_ (16.05.13 15:10) [90]
>
> > Я потому и настаиваю, что нужно сделать нормальные программистские
> > техникумы (колледжи, как угодно назвать) и снять с ВУЗов
> > нетипичную для них нагрузку.
>
> Так есть же уже.

Не слышал. Но если есть, то хорошо :)

← →
DevilDevil © (2013-05-16 15:38) [105]

> Ega23 © (16.05.13 15:25) [100]

для какого нафиг отношения ?
программа это конкретный продукт, которым пользуются пользователи. И вот эта программа (которую пишут люди) имеет определённую производительность. И производительность зависит от количества тактов и задержек. А ты про отношения

я не против математики. Я за расстановку приоритетов. В рамках которых место высшей математики ДАЛЕКО не первое. Эта мысль ясна?

← →
Ega23 © (2013-05-16 15:41) [106]

> > и где остался твой матан, когда ты реализовал сортировку
> > деревом (небалансированным) вместо хеша, и TList вместо
> > одно/дву связного списка? Я молчу про string вместо pchar

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

← →
Думкин_ (2013-05-16 15:44) [107]

> Kerk © (16.05.13 15:38) [104]

http://www.ci.nsu.ru/

← →
Ega23 © (2013-05-16 15:45) [108]

> программа это конкретный продукт, которым пользуются пользователи.
> И вот эта программа (которую пишут люди) имеет определённую
> производительность. И производительность зависит от количества
> тактов и задержек. А ты про отношения

Есть алгоритм А с вычислительной сложностью А1. Есть алгоритм Б с вычислительной сложностью Б1.
Отношение этих вычислительных сложностей будет одинаковым для реализации этих алгоритмов в различных языках, хоть высокого, хоть низкого уровней.

> я не против математики. Я за расстановку приоритетов. В
> рамках которых место высшей математики ДАЛЕКО не первое.
> Эта мысль ясна?

Ты очень сильно ошибаешься. Математика - это не наука. Математика - это инструмент, применимый где угодно. И знать этот инструмент - очень даже полезно, а зачастую просто необходимо.

← →
Думкин_ (2013-05-16 15:55) [110]

> Математика - это не наука.

смотрит.

Удалено модератором

> Ega23 © (16.05.13 15:41) [106]

> Потому что хэш-функция не гарантирует уникальности значения
> относительно разных параметров.

аааа
до меня дошло
сила хеш-таблиц не в уникальности. А в минимизации "коллизий". В данном случае производительность доступа будет почти O(1), выражаясь вашим математическим языком

> чего? ты уверен ?

В чём? В том, что hash(x1) может быть равен hash(x2) при x1 <> x2?
Ну как бэ это вот такое вот свойство хэширования. Помидор - ягода, Солнце - звезда, значения хэшей - могут совпадать.
Так устроен мир.

Удалено модератором

> сила хеш-таблиц не в уникальности. А в минимизации "коллизий".
> В данном случае производительность доступа будет почти
> O(1), выражаясь вашим математическим языком

Сила хэш-таблиц не в минимизации, а в одинаковом (и предсказуемом) времени получения элемента.
Минимизация коллизий - это усложнение непосредственно хэш-функции, к хэш-таблице это уже отношения не имеет.
Непосредственное вычисление достаточно-минимизированной хэш-функции от какого-то параметра занимает время дольше, чем дихотомия на заранее сортированном списке при данном количестве элементов.
Ну и самое главное - хэш-таблица тут в принципе не подходит. Как раз из-за той самой ненулевой вероятности коллизии.

> Ega23 © (16.05.13 16:10) [115]

вот очень хороший пример, когда теория (в данном случае математическая) сильно расходится с практикой. В итоге ты реализовал ~20 строковых сравнений на вставку одного элемента

я наверно ещё больше расстрою твои убеждения. В качестве размера массива значительно эффективнее брать не простое число (как в теории), а число степени двойки. И компания Google Inc со мной солидарна. Это так, если одного моего слова о хеш-таблицах не достаточно :))

> В качестве размера массива значительно эффективнее брать
> не простое число (как в теории), а число степени двойки

собственно, идея выравнивания данных на границы степеней двойки стара, как и адресная арифметика

> В итоге ты реализовал ~20 строковых сравнений на вставку одного элемента

Скорость вставки вообще фиолетова, клиент только вычитывает данные.

> я наверно ещё больше расстрою твои убеждения. В качестве
> размера массива значительно эффективнее брать не простое
> число (как в теории), а число степени двойки. И компания
> Google Inc со мной солидарна. Это так, если одного моего
> слова о хеш-таблицах не достаточно :))

Это вообще к чему было сказано?

Причём ладно бы ты просто стравнивал строки
Но это же реально шедевр оптимизаций:

function TrimInt(Value: Integer): Integer; begin if Value = 0 then Result := 0 else if Value > 0 then Result := 1 else Result := -1; end;

case TrimInt(CompareStr(T1, T2)) of -1: ... 0: ... 1: ... end;

Только не говори ради бога, что ты не видишь ничего "шедеврального" )

> DevilDevil © (16.05.13 15:34) [101]

>
> Смысл этого метода в том, чтобы скопировать кусок памяти
> во внутренний буфер, применяя ряд условий, немного логики.

тут вроде речь не идет о ЯП, не так ли?

Данный бенчмарк выполняет запись 100мб текстового файла.
...
Так вот раньше этот метод был реализован на ЯВУ и реализация
> выполнялась больше секунды. Сейчас она частично переписана
> на ассемблер и выполняется 265 миллисекунд

а у меня даже SSD не пишет со скоростью 400Мб/сек, что за железо? Даже есть за 156мсек - 640 Мб/сек, шикарно. Есть уверенность, что измеряется скорость записи на диск?

ВУЗ для IT специалиста: взгляд изнутри Найти похожие ветки