LINUX.ORG.RU

Книга по алгоритмам

 ,


5

3

Здравствуй, ЛОР:)!

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

Заранее спасибо.


Ответ на: комментарий от superhackkiller1997

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

anonymous
()
Ответ на: комментарий от anonymous

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

Нет никаких паралельных поток и ядер. Ты слился, но потом предпринял попытку всплыть на гипертрейдинге, который мне не упал и есть на 10% моделей х86.

А потом я тебя в говне размазал за твою жалкую вонь о том, что integer ALU - это просто и изимодно. На вопрос о том, почему в современных integer pipeline столько стадий ты так ничего сказать и не смог, потому что ты слабоумный.

Это уже особенности длинноконвейерной и мультиюнитовой архитектуры, а не алу. Это не обязательная часть алу. Ты в очередной раз решил съюлить на х86, хотя алу != алу в х86.

Потом ты благополучно слился и перешол на «это 2к строк на верилоге» и прочей ахинее.

Про среднее арифметическое ты уделался вообще феерически. Твое якобы решение в принципе работать не может, потому что ты, как было сказано выше, невежественный и слабоумный.

Только вот оно работает, с иделаьной точностью. А ты в очередной раз слился.

superhackkiller1997
()
Ответ на: комментарий от anonymous

В очередной раз слился, что и требовалось доказать.

Без разницы, лексер часть парсинга? Часть. Не смог придумать ничего лучше ифов и автоматов - твои проблемы.

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

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Как это нет параллельных потоков, шлюшка, когда они есть? Если нужна производительность, будут потоки и множество ядер. А если не нужна, то твои сантехниковские scratch buffers - что мертвому припарки.

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

Кстати, еще один пункт твоего жидкого обсера был в кэше кода, но этого ты даже не заметил.

И повторяю для слабоумных, твое среднее арифметическое НЕ работает. Ты обосрался.

anonymous
()
Ответ на: комментарий от anonymous

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

actics
()
Ответ на: комментарий от superhackkiller1997

Ты сам назвал себя скиллед и царем, так что спросить тебя «чего именно ты добился» вполне уместно.

Конкретно тут где я называл себя царём?

То есть про «скиллед» вопросов нет? А царем - вот, например: Метапрограммирование - проблемы и пути их решения. (комментарий) Правда, в том топике много прикольного, включая «1/1 = 0».

было только «как делают осиляторы» и «как делают не осиляторы»

Ну я и спросил тебя - как скиллед осилятор пишет программы (законченные программы, не сферические куски кода в вакууме), где на это посмотреть можно? Вместо предъявления кода ты сразу засчитал слив _мне_.

А про добился - это к соседям по цеху

Насчет соседей по цеху я и так знаю (а они знают про меня).

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от superhackkiller1997

Шлюха, потвторяю для тупых: покажи автомат с бесконечным lookahead. Что, чмо, обосрался опять? Тебе это свойственно.

Ты в теме вообще не разбираешься. Твой детский лепет про автоматы смешон. Найди автоматы в синтаксическом анализе в gcc, вместе посмеемся.

anonymous
()
Ответ на: комментарий от actics

А вот и еще одно ничтожное школоло вылезло. Еще одна грязная свинья, которой человеческим языком объяснять что бы то ни было просто бесполезно, ибо не осилит никогда. Ни тебе, ни обсуждаемому тут пациенту нет смысла доказывать, что вы ошибаетесь, при вашем-то зашкаливающем чсв и микроскопическом IQ. Таких можно только унижать. Дураки ничего иного не заслуживают.

anonymous
()
Ответ на: комментарий от anonymous

Как это нет параллельных потоков, шлюшка, когда они есть? Если нужна производительность, будут потоки и множество ядер. А если не нужна, то твои сантехниковские scratch buffers - что мертвому припарки.

Есть нити, но они все МОИ я ими управляю. Мне не нужено автоматическое управление кешем, как автоматическое управление оперативой.

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

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

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

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

Да и это уже не алу как таковое.

Кстати, еще один пункт твоего жидкого обсера был в кэше кода, но этого ты даже не заметил.

Кеш кода не нужен для молотилок, ибо код молотилок конпелятор сам разложит в л1 как надо. А для тухлокода хватит кольцевого буфера.

И повторяю для слабоумных, твое среднее арифметическое НЕ работает. Ты обосрался.

Конкретно где и как оно не работает и почему. Из-за обрезки остатка? Но замени деление на деление с остатком и напиши остаток/кол-во чисел.

superhackkiller1997
()
Ответ на: комментарий от anonymous

Дак не доказывай. В интернетах кто-то не прав, все в машину. Пожалей уж свое время, чтож ты тратишь его на свиней.
В прошлый раз ты ворвался в тред (если это ты был), и сразу начал поливать грязью, не слышал от тебя каких-либо рассуждений и доводов. «я прав, а вы все гавно и недоразвитая школота». Это, безусловно, слова взрослого, состоявщегося, как личность, человека.

actics
()
Ответ на: комментарий от tailgunner

Это совершенно нетот тред, отвечай тогда на тот коммент, где я называл себя царём, а не на этот.

Сферические куски кода говорят о много, или ты думаешь, что те, кто сливает в чистую моим кускам кода реально запилять какую-то систему лучше меня?

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

superhackkiller1997
()
Ответ на: комментарий от anonymous

В этом мире нет бесконечноей, таже твои рассуждения о таких словах как «бесконечность» меня смешат.

Писать автоматы для абстрактных понятий мне не упёрлось, а так да, я знаю, что ты проходил это в вузе и тебе рассказывали как это круто и какие автоматы фуфло, но не мне не интересно. Это как лепет жабиста, который рассказывает мне какой ГЦ крутой, а мой ммап фуфло. Говорит мне про какие-то бесконечно и любимые им абстрактные понятие, которые он запомнил с курсов юных жабистов.

superhackkiller1997
()
Ответ на: комментарий от anonymous

И да, это уже оптимизаций всего потока, а не алу. Поэтому не приплетай это к алу.

Ты щас будешь вонять, что ты нихрена не запилишь, не раскидаешь оптимально по юнитам и прочую байду. С х86 ассемблером да - со своим спокойно.

А если запилю поднити. В которые и помещу юниты, а код буду писать для каждой поднити синхронизирую всё руками. Это не сложно, но это упращает всё.

Это и делает твой конвейер, но с чего ты взял, что это единственный выход?

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

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

И еще раз, сливашка, ассемблер к АЛУ вообще никакого отношения не имеет. Совсем. Ни разу.

anonymous
()
Ответ на: комментарий от superhackkiller1997

Бесконечность в данном контексте значит «неопределенная глубина lookahead». Ты даже терминологией не владеешь, тупица.

И ничего абстрактного тут нет, все совершенно конкретное. Конкретный синтаксис конкретных языков.

Итак, сливашка, где автоматы в gcc?

anonymous
()
Ответ на: комментарий от superhackkiller1997

или ты думаешь, что те, кто сливает в чистую моим кускам кода реально запилять какую-то систему лучше меня?

Да. Идеально вылизанная пузырьковая сортировка сольет втупую написанной heapsort.

И кстати, никто не «слил вчистую твоим кускам кода».

tailgunner ★★★★★
()
Ответ на: комментарий от actics

Ты не понял. Говно не «все», а конкретно ты (нищая школота, испытывающая баттхерт от любого упоминания яблок) и пациент (слабоумный подросток, считающий, что умеет программировать). Остальные в порядке.

anonymous
()
Ответ на: комментарий от anonymous

И да, код константа. Стоит синхронезировать его одинраз конпелятору - он будет рективен. Это сразу уберёт все проблемы с непредсказуемостью, сразу будет понятно какой юнит работает, сколько свободных, их оптимальная компоновка для неблокирующей работы с регистрами.

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

superhackkiller1997
()
Ответ на: комментарий от tailgunner

Он, наверное, ссылается на недоделанную и неработающую якобы реализацию среднего арифметического. Да уж, царский код!

anonymous
()
Ответ на: комментарий от tailgunner

Нет. Нет, не сольёт. Да и причем тут твоя сортировка? Если каразтаки их код сортировки и сливал в хламину.

Абсалютно все слили, кроме пары личностей, хотя там ещё до кусков кода не дошло.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Ой-ой, лошок уже научился предсказывать ветвления во время компиляции!

И это, отвечай уж за базар - делай «простой» АЛУ без сложного конвейера, но так, чтоб он был быстрым. Вперед! Или признай, что АЛУ - это адски сложно, и требует формальной верификации и строгого доказательства корректности.

anonymous
()
Ответ на: комментарий от anonymous

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

И еще раз, сливашка, ассемблер к АЛУ вообще никакого отношения не имеет. Совсем. Ни разу.

Причем тут ассмеблер и алу. К алу имеет отношение выхлоп ассемблера(а этот выхлоп руками не пишут), которое после декодеров и дёт в конвейер, а потом уже в алу.

Устройства ведра многонитивое, а машинкода мононитевые. Дак вот задача конвейера и раскидать эту мононить на юниты.

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

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Идеально вылизанная пузырьковая сортировка сольет втупую написанной heapsort.

Нет. Нет, не сольёт.

Мде. Похоже, чтобы приблизить тебя к реальности, необходимы способности и силы, которыми здесь обладает только Alv.

Да и причем тут твоя сортировка?

Это пример. того, как оптимальный алгоритм бьет оптимальную реализацию.

tailgunner ★★★★★
()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от anonymous

Сложно не алу, а какраз-таки оптимально управление алу.

В х86( и его «братьях») вся сложность и заключается в конвейерах, которые раскидывают неоптимальный порядок однопоточных инструкций по юнитам. Это как автоматические системы для распаралеливания кода. Да, это сложно, но это не нужно.

superhackkiller1997
()
Ответ на: комментарий от tailgunner

Alv

Т.е. пока на это способен один человек и то в одной областе в которой я ноль. Мы проверим это.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Забудь про управление! Я говорю про сложность самого АЛУ. Модуля, у которого на входе два или три целых числа и код операции, а на выходе одно или два целых числа - результат операции.

anonymous
()
Ответ на: комментарий от anonymous

Я уже работаю над убийцей сишки, подожи полгодика и мы сравним мою реализацию и гццешную.

Да я не владею вашей терминалогией, ибо я с вами не общался. Ты мне можешь объяснить так, чтобы я понял и тогда ты можешь меня реально слить на моих фейлах, а не на незнании терминалогии.

Говори «как реализовать такую-то часть сишки» и т.п.

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Короче, ты вообще не понимаешь, что такое конвейер. Почитал бы хоть что нибудь, а? У тебя знаний по архитектуре процессоров - ноль без палочки. Адская каша в голове. Конвейером ты, похоже, называешь reservation stations.

Для тупых - конвейер нужен для того, чтобы сократить длину critical path. Чтобы за один такт сигнал прошел как можно меньшее количество элементов цепи. Даже банальная операция умножения делается в виде длинного конвейера с кучей промежуточных регистров.

anonymous
()
Ответ на: комментарий от anonymous

Лол что? Я люблю яблоки, ты путаешь.

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

actics
()
Ответ на: комментарий от anonymous

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

Если там ещё есть какие-то хитрые батамахинации, но всё зависит от их сложности.

Но в целом нужны битоперации в алу - не сложные, а сложность ненужностей я не разбираю, ибо оно не нужно.

Но ты щас запаёшь о том, что в алу у х86 и братье встроен свой конвейер и он ахринетькакойсложный.

superhackkiller1997
()
Ответ на: комментарий от anonymous

Опять в интернетах кто-то не прав, и я опять что-то тут делаю.

actics
()
Ответ на: комментарий от superhackkiller1997

Я уже работаю над убийцей сишки, подожи полгодика и мы сравним мою реализацию и гццешную.

Лол. Попов, ты?

actics
()
Ответ на: комментарий от anonymous

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

Ну операция умножения в алу - это самая сложная из всех нужных операций.

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

Поясни.

superhackkiller1997
()
Ответ на: комментарий от actics

Он тут пока царь лора, и хоть он так говорит - он реально пока единственный, кто не сливается как дитё. Правда на софтварном уровне он дитё, но он не сливается как дитё.

Поэтому ему можно говорить как угодно, пока он разговор держит на уровне.

superhackkiller1997
()
Ответ на: комментарий от tailgunner

Да, так и будет. Хотя это будет не сишка, а управляемый макроассемблер с произвольным синтаксисом и полуавтоматический кодогинерацией.

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

superhackkiller1997
()
Ответ на: комментарий от superhackkiller1997

Ты не увиливай, ты найди свои сраные автоматы хотя бы в одном промышленного качества компиляторе.

Реализуй синтаксис типа в сишке на LALR(1) или еще каком автоматном говне. Поржем. Да, при этом твоя реализация должна еще уметь выдавать внятные сообщения об ошибках, с подсказками, как исправить.

И еще, расскажи сейчас, заранее, какие конкретно оптимзации твоя убийца сишечки делать будет. Начни с рассказа о выбранном тобой способе распределения регистров. Будет смешнее тебя унижать на почве твоей полной невменяемости.

anonymous
()
Ответ на: комментарий от superhackkiller1997

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

А про самое сложное умножение ты тоже обздался. Barrel shift еще сложнее. Да, тот самый << и >> из сишечки.

anonymous
()
Ответ на: комментарий от actics

Розенталь, покарай школоту!!!

anonymous
()
Ответ на: комментарий от anonymous

sarcasm off

А как это делается, если не на LR анализе? И где про это можно почитать, мне интересно. Книга дракона?

actics
()
Ответ на: комментарий от superhackkiller1997

Прочитай наконец, тупица, что такое конвейер. До тебя до сих пор не доходит, что ты жидко обгадился. Хинт для недоумков - у каждого логического элемента ненулевая задержка. Чем больше их на пути сигнала, тем меньше возможная тактовая частота. Конвейер позволяет прерывать путь сигнала, записывая текущие промежуточные значения в регистры. Без конвейера ты даже из ячейки SRAM значение не вытащишь. А уж про битовые сдвиги я и вовсе молчу.

anonymous
()
Ответ на: комментарий от actics

Recursive descent parsing. А про современные подходы читай Томиту и Форда. По сравнению с драконьим говном из семидесятых оно современное, естественно, статья Томиты в 84м вышла.

anonymous
()
Ответ на: комментарий от anonymous

Да, при этом твоя реализация должна еще уметь выдавать внятные сообщения об ошибках, с подсказками, как исправить.

Мне это не нужно.

Что ты понимаешь под «распределение регистров»?

superhackkiller1997
()

Тема скатилась в срач, но всё-таки попробую спросить. Порекомендуйте почитать по компиляторам книгу, только не драгон бук - хочется посовременнее и для введения в тему. Цель - самообразование, написание парсеров для своих конфигов, простой язык накидать. На английском нагуглил 2 книги: 1. Language Implementation Patterns: Create Your Own Domain-Specific and General Programming Languages http://pragprog.com/book/tpdsl/language-implementation-patterns 2. http://www.amazon.com/Programming-Language-Pragmatics-Third-Michael/dp/012374... Есть ещё такая http://createyourproglang.com/ но по-моему слишком по верхам она.

anonymous
()
Ответ на: комментарий от anonymous

Т.е. твой конвейер даёт возможность делать кукурузные такты, а так же не даёт просирать такты, когда что-то делается дольше 1 такта.

Т.е. конвейер позволяет дампить состояние юнитов, чтобы они не забирали такты. Хорошо, только почему битовые опреации в алу работают за 1такт?

Т.е. есть предел задержки за такт - конвейер оптимально распределяет эту задержку по юнитам, а если юнит не успевает отработать за такт - дампит его.

В чём я зафейлил?

superhackkiller1997
()
Ответ на: комментарий от anonymous

«Language Implementation Patterns» хорошая книга, правда, примеры на Яве.

P.S. для конфигов лучше использовать что-нибудь готове - не плоди форматы без нужды.

tailgunner ★★★★★
()
Ответ на: комментарий от superhackkiller1997

Все, что тебе не под силу, ты считаешь ненужным. Лузерский подход.

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

Грубо говоря, как ты будешь выбирать, в каких регистрах хранить переменные?

anonymous
()
Ответ на: комментарий от superhackkiller1997

Какие в сраку юниты? Ты ни хера вообще не понял, чушь несешь. Прочитай хотя бы педивикию про hardware pipeline для начала.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.