Я до конца не понял - то есть предлагается исправить не ПО, чтобы не тормозило, а просто разогнать производительность железа, которое специально аппаратно её понижает, потому что она такая банально не требуется?!
А как же ИИ, который сейчас везде рекламируют, продвигают и внедряют и он быстрее и лучше делает работу неэффективных и ленивых программистов? Неужели целая корпорация не может с помощью ИИ справиться с такой бедой? Хотя почему-то интуитивно думается, что именно ИИ и предложил этот вариант решения проблемы... ;)
Если честно, я просто не в курсе текущего момента) У них же было вроде порядка 1,5к сотрудников! Чем они там все занимаются-то тогда? Или уже всё радикально соптимизировали?
Юмор и интеллект кореллируют, но это корелляция неабсолютна. И нельзя делать выводы только по комментам. Потому что человек посмеялся, поставил плюсик и пошёл дальше. А другой непонял и прокомментировал. Это как отзывы на товар - много людей не пишут, если их устроило, а вот если что-то не то, то негатив будет оставлен обязательно. Выборка по отзывам получается нерепрезентативна.
Это всё так при нормальной реализации интерфейса в блоке передающего мне данные. А если там самописная реализация, то может быть всё что угодно. Конечно это излишний и бредовый контроль если это чисто внутриплисовый стык.
Я почему-то думал, что он конвейерный. Он такой большой и красный, что кажется чем-то фундаментальным. И вообще - а где написано, что он неконвейерный? ) Родство ИИ и ЕИ в том, что это довольно галлюцинирующие штуки - поставишь задачу с чуть неполными условиями и они наделают такого, что не надо.
Потери данных при изменении RDY не будет, если в этом режиме работы выход с А/В защелкивать в начале сдвигового регистра. Но это как-то некрасиво, поэтому в вышеизложенную реализацию такой защелкивающий регистр лучше сделать на выходе А/В - при нормальной работе он будет конвейерным, а при торможении просто сохраняющим. Но в любом случае, если блок А/В не конвейерный, то это всё неважно.
Error должен выставляться в случае запрета приёма данных по входу, но в случае их всё же появления. В этом случае будет потеря данных - я запретил их мне передавать, но они пришли. Возможно у меня профдеформация по обработке нештатных ситуаций, которая потом здорово помогает при отладке.
Отличная задачка на подумать. Сначала прикинул с N блоками А/В, потом решил обойтись одним. За 10-15 минут надумалась схема подсчитывающая время выдачи результата из А/В и в зависимости от этого мультиплексирующая выход A/B с его сигналом VDo на один из N сдвиговых 9-битных регистров (в случае 8-битного слова С), имеющих фиксированную нарастающую задержку от 1 до N (первый регистр = 1 такт, второй = 2... последний = N). Выходы регистров тупо мультиплексируются по ИЛИ - старший бит будет выходом VDo блока, остальные - шина результата блока. Схема контроля содержит N счётчиков, которые разрешаются/сбрасываются сигналами VDi/VDo от А/В. На каждые новые данные запускается свой индивидуальный счётчик, после задействования последнего возвращаемся к первому. Конвейерная задержка блока будет равна то ли N, то ли N+1 - выясняется на этапе разработки.
Разнотактовые входы роли никакой особо тут не сыграют. Введение RDY тоже вроде бы особых проблем не должно составить, так как этот сигнал может управлять EN сдвиговых регистров и разрешением приёма по входу. Если в момент падения RDY А/В будет работать, то вроде бы ничего страшного - схема контроля направит результат на вход нужного регистра. Тут нужно будет подумать при наличии этого сигнала защитить логику - вдруг по входу кто-то VDi выставит - это нужно будет игнорировать и, в идеале, Error выставить.
С возрастом всё самое интересное оказывается в содержании пункта 1. Идея и архитектура под неё, рисуемая квадратиками карандашиком на бумажке. Код писать - это уже рутина и работа. Тем более на доске я синтаксис точно завалю))
Если бы да кабы, а по факту почти все браузеры были подвержены утечке истории даже в приватном режиме. И условному Максу технически ничто не запрещает делать это, наплевав на вашу песочницу. Так что однозначное высказывание "нет, конечно" я бы всё же скорректировал)
Всё это ваше выступление никак не отменяет прискорбного факта о том, что смена руководства ухудшила работу сервиса о чём ведает данная статья. Не нравится - не читайте хабр и комменты на нём, пилите свой собственный радужный вестник IT.
Почему не интересна-то? Интересна! Просто нужно понимать, что обзор схемоты - это довольно узкая выборка из местного контингента. Эта статья теперь будет лежать как вино, постепенно набирая свою ценность)
Ну нельзя же так резко с человеком, у которого в тексте, при наличии точек, ни одной заглавной буквы нет...
Я до конца не понял - то есть предлагается исправить не ПО, чтобы не тормозило, а просто разогнать производительность железа, которое специально аппаратно её понижает, потому что она такая банально не требуется?!
А как же ИИ, который сейчас везде рекламируют, продвигают и внедряют и он быстрее и лучше делает работу неэффективных и ленивых программистов? Неужели целая корпорация не может с помощью ИИ справиться с такой бедой? Хотя почему-то интуитивно думается, что именно ИИ и предложил этот вариант решения проблемы... ;)
Как говорится, вопросов больше не имею!
Если честно, я просто не в курсе текущего момента) У них же было вроде порядка 1,5к сотрудников! Чем они там все занимаются-то тогда? Или уже всё радикально соптимизировали?
Почему не занимается? У них же есть целый офис разработки!
Да уже не только оперативную память, но и диски, SSD и, само-сбой разумеющееся, видюхи!
Юмор и интеллект кореллируют, но это корелляция неабсолютна. И нельзя делать выводы только по комментам. Потому что человек посмеялся, поставил плюсик и пошёл дальше. А другой непонял и прокомментировал. Это как отзывы на товар - много людей не пишут, если их устроило, а вот если что-то не то, то негатив будет оставлен обязательно. Выборка по отзывам получается нерепрезентативна.
А всё почему? Потому что соответствующего тега нет! ;)
Принял их на работу)
https://ru.wikipedia.org/wiki/Звёздная_величина
И ещё вежливость повысится!
Это всё так при нормальной реализации интерфейса в блоке передающего мне данные. А если там самописная реализация, то может быть всё что угодно. Конечно это излишний и бредовый контроль если это чисто внутриплисовый стык.
Я почему-то думал, что он конвейерный. Он такой большой и красный, что кажется чем-то фундаментальным. И вообще - а где написано, что он неконвейерный? ) Родство ИИ и ЕИ в том, что это довольно галлюцинирующие штуки - поставишь задачу с чуть неполными условиями и они наделают такого, что не надо.
Потери данных при изменении RDY не будет, если в этом режиме работы выход с А/В защелкивать в начале сдвигового регистра. Но это как-то некрасиво, поэтому в вышеизложенную реализацию такой защелкивающий регистр лучше сделать на выходе А/В - при нормальной работе он будет конвейерным, а при торможении просто сохраняющим. Но в любом случае, если блок А/В не конвейерный, то это всё неважно.
Error должен выставляться в случае запрета приёма данных по входу, но в случае их всё же появления. В этом случае будет потеря данных - я запретил их мне передавать, но они пришли. Возможно у меня профдеформация по обработке нештатных ситуаций, которая потом здорово помогает при отладке.
Отличная задачка на подумать. Сначала прикинул с N блоками А/В, потом решил обойтись одним. За 10-15 минут надумалась схема подсчитывающая время выдачи результата из А/В и в зависимости от этого мультиплексирующая выход A/B с его сигналом VDo на один из N сдвиговых 9-битных регистров (в случае 8-битного слова С), имеющих фиксированную нарастающую задержку от 1 до N (первый регистр = 1 такт, второй = 2... последний = N). Выходы регистров тупо мультиплексируются по ИЛИ - старший бит будет выходом VDo блока, остальные - шина результата блока. Схема контроля содержит N счётчиков, которые разрешаются/сбрасываются сигналами VDi/VDo от А/В. На каждые новые данные запускается свой индивидуальный счётчик, после задействования последнего возвращаемся к первому. Конвейерная задержка блока будет равна то ли N, то ли N+1 - выясняется на этапе разработки.
Разнотактовые входы роли никакой особо тут не сыграют. Введение RDY тоже вроде бы особых проблем не должно составить, так как этот сигнал может управлять EN сдвиговых регистров и разрешением приёма по входу. Если в момент падения RDY А/В будет работать, то вроде бы ничего страшного - схема контроля направит результат на вход нужного регистра. Тут нужно будет подумать при наличии этого сигнала защитить логику - вдруг по входу кто-то VDi выставит - это нужно будет игнорировать и, в идеале, Error выставить.
С возрастом всё самое интересное оказывается в содержании пункта 1. Идея и архитектура под неё, рисуемая квадратиками карандашиком на бумажке. Код писать - это уже рутина и работа. Тем более на доске я синтаксис точно завалю))
Если бы да кабы, а по факту почти все браузеры были подвержены утечке истории даже в приватном режиме. И условному Максу технически ничто не запрещает делать это, наплевав на вашу песочницу. Так что однозначное высказывание "нет, конечно" я бы всё же скорректировал)
Всё это ваше выступление никак не отменяет прискорбного факта о том, что смена руководства ухудшила работу сервиса о чём ведает данная статья. Не нравится - не читайте хабр и комменты на нём, пилите свой собственный радужный вестник IT.
А как же быть с атакой через localhost?
И что там?
Непонятно как это должно оправдывать поломку полезного сервиса очередными эффективными менеджерами?
Почему не интересна-то? Интересна! Просто нужно понимать, что обзор схемоты - это довольно узкая выборка из местного контингента. Эта статья теперь будет лежать как вино, постепенно набирая свою ценность)