Здравствуйте, smeeld, Вы писали:
S>А вот эта наркомания на мой взгляд-уродство.
В чём именно наркомания?
S>Зачем так скакать? Неужели нельзя писать компактнее.
Можно компактнее, например так:
но не такой пц как у тебя.
S>new только на локалхосте разраба всегда возвращает успех.
На С++ говоришь пишешь?
Не дюд, ты пишешь в лучшем случае на С с классами.
S>const auto current_chunk = node_descp->get_current_storage_chunk();
S>
S>использование сохранённого ранее значения в reinit_if_necessary(descp, current_chunk) вместо получаемого с get_current_storage_chunk, приведёт к сегфолту в течении 1-5 секунд. Там везде вызывается get по той причине, что другие могут вызвать и вызывают set. Использование непоследовательного значения в set, полученного не через вызов get при вызове set, а через вызов get с сохранением этого значения где-то и применением его через некоторое время в set, приведёт к нарушению механизма синхронизации. Там lockfree.
Во-первых, вы не умеете читать. Ибо сказано было вам:
> отрефакторили бы ваш код хотя бы вот так (при условии, что значение get_current_storage_chunk можно кэшировать):
Во-вторых, вы так ни разу и не ответили на задаваемые вам вопросы о наличии побочных эффектов и идемпотентности операций set/get_current_storage_chunk. Поэтому приходилось действовать исходя из того, что вы говорили ранее.
> Оно и закешируется, оно не просто закешируется, эта функция в коде будет везде заменена компилятором на значение поля, которое данная функция возвращает, это inline функция.
И речь шла именно об get_current_storage_chunk. А про то, что это поле у вас volatile, вы нигде не говорили. Если же оно у вас не volatile, то...
В чем вы здесь видите проблему и как предложили бы исправить?
S>А вот эта наркомания на мой взгляд-уродство. S>Зачем так скакать? Неужели нельзя писать компактнее.
Это вариация на тему GNU C code style. Хороша тем, что препятствует организации большого уровня вложенности в функциях/методах. Плюс к тому у нас не принято без надобности выходить за границу 80 символов по ширине, поэтому код растет "в высоту". Ограничение такое связано с рядом причин, одна из самых актуальных на данный момент -- удобство вставки фрагментов кода в документацию или в электронную переписку (например, при обсуждении багов или новых фич).
S>new только на локалхосте разраба всегда возвращает успех.
В C++ обычный new уже давно в случае неудачи бросает исключение. Так что где вы здесь проблему с new увидели?
S>В коде серверов за new по рукам бьют.
За new не бьют по рукам даже в системах жетского реального времени. Если new использован на этапе инициализации системы.
А мы даже и не декларируем поддержку РТ (хоть какую-нибудь).
Если кому-то нужна версия нашего инструмента, в которой бы использовались кастомные средства управления памятью, а работа с динамической памятью в run-time была бы сведена к минимуму (или вообще исключена), то мы с удовольствием сделаем такую версию. Но за деньги клиента. Поскольку делать такой специфический функционал за свои, а потом раздавать результат под BSD-лицензией (как это и происходит сейчас) -- это тупо вылететь в трубу.
Здравствуйте, Lexey, Вы писали:
L>Здравствуйте, a7d3, Вы писали:
A>>Компании разрабатывающие собственные продукты тяготеют к кабинетному принципу, когда в одной комнате размещается одна команда в пять-шесть человек, в отдельных случаях до девяти человек.
L>Объем статистической выборки можно озвучить и размеры компаний? Ибо у меня из 2-х продуктовых компаний в собственном бэкграунде к кабинетному принципу не тяготела ни одна. И, наоборот, в Яндексе большая часть моей и соседней команды сидит в "кабинете" человек на 10, хотя опенспейсов вокруг тоже хватает. В Сбертехе, кстати, тоже довольно долго сидели в комнатке на 8 человек.
Три десятка компаний. Размерами от нескольких сотен до четырёх тысяч сотрудников. Филиалы у них тоже разных размеров, но сейчас редко бывают более ста пятидесяти человек. Лет десять назад встречались филиалы и на две-три сотни с сохранением кабинетного принципа, т.е. без опен спейсов.
Комнаткой назвать помещение на 8 человек сложно, метраж у него должен быть от 48-50 квадратных метров. Видимо, в Сбертехе проблемы с культурой общения (акулизм) растут именно из-за высокой скученности персонала. И оно ни разу не продуктовая компания, а внутренняя автоматизация банка, что ощутимо хуже чем аутсорц и финтех. Т.е. по шкале находится в самом низу, на одном уровне с производственными компаниями, где занимаются всякими программно-аппаратными комплексами для предприятий и медицины, банкоматами-терминалами и т.п.
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, smeeld, Вы писали:
S>>new только на локалхосте разраба всегда возвращает успех. CC>На С++ говоришь пишешь? CC>Не дюд, ты пишешь в лучшем случае на С с классами.
Мда уж. Не перевелись ещё эти гаврики, что С++ путают с Си-шечкой и классами.
Самое забавное, что свой уродский почерк они полагают символом и признаком некоего элитизма.
Хотя в реальности, не освоили даже такой мелочи как ООП и транзакционность с exception safety. Не говоря уже о практиках написания самодокументируемого кода.
Здравствуйте, reversecode, Вы писали:
R>ring.com
R>в чем разница что делать ? R>делая гаджеты софт не нужно разрабатывать ? R>работают же не на аутсорс
Это именно что подобие, эдакий частный случай аутсорца. Отдел разработки софтваре в таких технологических компаниях подобен мелкой аутсорц-шарашке долгое время работающей на одного заказчика. Не существенно, является ли компания при этом fabless или же имеет свои производственные мощности.
Работа софтваре девелопером или же инженером-программистом в производственных компаниях это очень поганая работа. Хуже чем писать внутренний софт и сервисы в различных банках (отделы автоматизации). Хуже чем работа над проектами в полноценных аутсорцах, вроде епамов/люксофтов/дигдезов/рексофтов(или как они теперь зовутся).
Хуже по условиям труда, отношению к персоналу и организации процессов софваре инженерии.
Связано с тем, что производственные компании заняты в первую очередь тем, что у моторолы звалось «шесть сигма». Именно в таких вещах данный тип компаний видит основную генерацию value. А всякие там программисты со своими проектами воспринимаются как средство снижения себестоимости железа и создания «упаковки» продаваемого товара.
Потому что firmware всегда является именно что способом удешевить и упростить работу над железом гаджетов. Всё тоже самое можно было бы изначально отливать в кристалле, но обходится дорого в целом из-за технологических циклов разработки и доведения до ума. Проще и дешевле делать кристалл выполняющий firmware, в котором уже учитывать нюансы и ошибки в реализации кристаллов (нормальное явление у всех непростых «железок»).
А софтваре сервисы для покупателей гаджетов пишутся именно в режиме мелкой аутсорцевой компании с одним крупным и постоянным клиентом.
весь софт обслуживающий ихний сервис те компании пишут сами
и фирмваре
и андроид апликухи
и сервисы по раздаче видео
исключения составила только убикути
которая приобрела права на поставку в свое железо evostream.com
ну и мне интересно как вы туже ос переложите в железо
на аутсорс они ничего не отдают
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Ну и правда, должен же быть студент чем то хуже. Иначе как то неуютно выходит.
Комплексуешь? Понимаю, ведь даже студенты знают, что "то" пишется через дефис.
R>весь софт обслуживающий ихний сервис те компании пишут сами R>и фирмваре R>и андроид апликухи R>и сервисы по раздаче видео R>исключения составила только убикути R>которая приобрела права на поставку в свое железо evostream.com
R>ну и мне интересно как вы туже ос переложите в железо R>на аутсорс они ничего не отдают
их отдел/департамент пишущий весь этот софт работает в режиме аналогичном мелкой аутсорц компании (взаимодействующей с одним постоянным заказчиком). они не делают софтового продукта, они делают заказное решение под нужды, цели и требования одного отдельно взятого заказчики.
когда ОС становится нужна в железе на замену firmware — это отдельная и большая тема.
Здравствуйте, smeeld, Вы писали:
S>использование сохранённого ранее значения в reinit_if_necessary(descp, current_chunk) вместо получаемого с get_current_storage_chunk, приведёт к сегфолту в течении 1-5 секунд. Там везде вызывается get по той причине, что другие могут вызвать и вызывают set. Использование непоследовательного значения в set, полученного не через вызов get при вызове set, а через вызов get с сохранением этого значения где-то и применением его через некоторое время в set, приведёт к нарушению механизма синхронизации. Там lockfree.
Кстати говоря, вот это все выглядит просто феерично. У вас в многопоточном коде есть что-то вроде:
data->set_v(data->get_v());
и вы пытаетесь вещать, что это никак нельзя переписать вот так:
auto v = data->get_v();
data->set_v(v);
Поскольку тогда в v может оказаться "непоследовательное" значение, т.к. где-то на другой нити кто-то навызывает set/get_v.
Вот это уже точно смахивает на детский сад, поскольку даже вот в этом виде:
data->set_v(data->get_v());
у вас нет никаких гарантий того, что в set_v попадет "последовательное" значение из только что вызванного get_v. Ибо между вызовом get_v и передачей значения в set_v может вклиниться кто угодно и навызывать set/get_v сколько угодно раз.
Но, предположу, что сейчас последуют какие-то очередные открытия, что у вас там некий очень продвинутый lockfree и вообще непрерываемость последовательности вызовов гарантируется мега-хитрыми механизмами синхроннизации, оставшимися "за кадром".
Тем не менее, пояснение вида "Там везде вызывается get по той причине, что другие могут вызвать и вызывают set. Использование непоследовательного значения в set, полученного не через вызов get при вызове set, а через вызов get с сохранением этого значения где-то и применением его через некоторое время в set, приведёт к нарушению механизма синхронизации." феерично само по себе.
то как вы смотрите на это я понял
я не понял чем софт пишущийся под свои нужды для своего железа и обслуживания инфраструктуры для массового использования
отличается от софта который пишут исключительно продуктовые софтваре компании
да ну, про фирмваре все еще проще
ну даже епл не встроила всю ос в железо
ну даже радиомодули андроидфонов работают на фирмваре в которой крутиться своя мини ос
такой вот современный мир где в железо стали перекладывать очень мало
исключительная из этого тема это аи, где ос ну никак не нужна и все можно переложить в логику железа
Здравствуйте, bzig, Вы писали:
B>Личности, которые вместо того, чтобы встать и сказать "мне не нравится ваше собеседование, поэтому я ухожу", начинают паясничать, не нужны ни в каких компаниях.
Можно посмотреть с другой стороны: время уже потрачено (скорее всего целый день), поэтому хорошо бы максимизировать пользу: ппробовать пройти как можно дальше чисто из спортивного интереса, прокачать социальные навыки и т.д. Другой стороне это тоже может быть полезно, если не быть чудаком на букву "М".
Здравствуйте, so5team, Вы писали:
S>Но, предположу, что сейчас последуют какие-то очередные открытия, что у вас там некий очень продвинутый lockfree
С таким кодом писать lock free алгоритмы? Шутишь?
Хотя, попался мне как то в наследство проект, в котором ребятки, ничтоже сумнящеся, решили написать свою очередь. Зачем — неясно, ибо в качестве стораджа они использовали монгу, а в монге очередь есть искаропки. Но поразила самоуверенность при полном отсутствии опыта в подобных вещах. Я бы вот лично без сильнейшей нужды не взялся бы, хотя даже книжку на тему написал в свое время.
И вот что самое удивительное — если нагрузка была очень маленкой, это работало. Жрало, правда, 90% CPU на 5 многоядерных машинах, но работало.
Самое веселье настало, когда пару самых вопиющих багов пофиксили. Результатом стало то, что очередь наконец заработала, заработала куча кода которая не работала потому что очередь была нерабочей, и из этого кода баги полились лавиной.
Да, забыл упомянуть — это все было в продакшене
Это я к чему — сдается мне, обсуждаемое из той же оперы, когда куча костылей работает, потому что путем установки новых костылей закрывалось кривое поведение старых. И любая попытка исправить приводит к тому что карточный домик рушится, и нужен особый сорт умельцев, способных что то поменять не развалив сооружение. Человек сторонний, разумеется, не справится.
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Это разве я тут воюю с собеседованиями в Яндексе?
Кто тебя знает с чем ты воюешь
Я вот честно говорю, что матан после 3-го курса не применял и без подготовки мало что внятного скажу. Нормализацию БД знаю на практике, а теорию плохо помню (сколько там нормальных форм и в чем их особенности?), но вот на своем первом собеседовании это было практически единственным, что я ответил идеально. Это жизнь. И да, для сложных алгоритмов и матана у нас есть полноценные PhD. Специализация и способность к кооперации решает.
S>> Понимаю, ведь даже студенты знают, что "то" пишется через дефис. НС>Правила форума? Не, не слышал.
Ну чего не сделаешь для товарища по форуму, приходится идти на жертву.
Надеюсь, что ты наконец запомнишь это правило и мой бан будет не напрасным.
З.Ы. Если я где-то делаю систематические орфографические ошибки — прошу мне указывать.
Здравствуйте, reversecode, Вы писали:
R>то как вы смотрите на это я понял R>я не понял чем софт пишущийся под свои нужды для своего железа и обслуживания инфраструктуры для массового использования R>отличается от софта который пишут исключительно продуктовые софтваре компании
R>да ну, про фирмваре все еще проще R>ну даже епл не встроила всю ос в железо R>ну даже радиомодули андроидфонов работают на фирмваре в которой крутиться своя мини ос R>такой вот современный мир где в железо стали перекладывать очень мало R>исключительная из этого тема это аи, где ос ну никак не нужна и все можно переложить в логику железа
логика рассуждений понятно, но в ней есть хорошо известная проблема
Группе статистических исследований дали задачу просчитать оптимальную схему брони для бомбардировщиков. Потери союзной авиации от немецкого зенитного огня оказались выше, чем рассчитывало начальство. Военные пытались решить вопрос самостоятельно — фотографировали все повреждения вернувшихся самолётов, составляли красивые схемы и отсылали на завод, требуя дополнительно укрепить самые «дырявые места».
Вес бронеплит рос, бомбардировщики становились тяжелее, а процент не вернувшихся с задания самолётов так и застыл на неприлично высокой цифре.
Кто-то из военных вспомнил о том, что на Манхэттене сидят «яйцеголовые», способные посчитать что угодно. И через пару дней от группы статистических исследований потребовали изучить все фотографии и чертежи и создать схему оптимального бронирования самолётов. Ответственным назначили чёрного мага старшего специалиста Абрахама Вальда. И почти сразу он указал военным на их ошибку:
«Это не полная выборка, и тут нет самого важного. Меня интересуют те самолёты, что сбил противник. С теми, что вернулись на базу, всё в порядке, их запаса прочности хватило. Но мне не хватает информации, чтобы понять: как именно повредили сбитые бомбардировщики».
Содержимое baseband в современном мобильнике можно назвать ОС лишь с большой натяжкой. Да, формально это RTOS, однако, чем она там занимается и насколько большая? Это даже не микро, а нано-ядро, используемое для выделения ресурсов малюсенького локального ЦПУ и ОЗУ для взаимодействия посредством AT-команд с основным ЦПУ мобильника/коммуникатора. Впоследствии, в более новых SoC эти самые AT-команды заменили на полноценный IPC.
Это нано-ядро RTOS появилось внутри baseband'ов по причине нежелания писать свои велосипеды по реалтайм шетдулингу и кооперативной многозадачности внутри firmware. А само по себе использование firmware вместо отливания в кремнии явилось следствием желания удешевить начинку модема (baseband) и сократить циклы производства.
В случае же с GPS-модулями пошли другим путём и не прогадали. Там никаких firmware, а всё сразу в кремнии. Это позволило существенно выиграть в габаритах и энергопотреблении.
Т.е. использование модулей с firmware не панацея, не неизбежность, а выбор лишь одной из стратегий.
