Обновить
1
Mikhail Belokoskov@Sterpa

CEO, основатель, евангелист STERPA.SPACE

68
Подписчики
Отправить сообщение
Конкретно у меня LastBootedVolume значение не работает, сейчас оно как раз и стоит. У меня есть подозрение, что с этим значением какой-то лаг в Клевере, когда SSD подключается через переходник PCI-E >> M.2 да еще в режиме PCIe1x.
За Web-конфигуратор спасибо, я его видел краем глаза, но для моей матери прессета не нашел. Поэтому не рискнул.
А так конечно выглядит для специалиста многообещающе. Добавляю в статью и тег и ссылку.

У нас сыро, но лапкам тепло)) Пост же не про тонкую настройку Клевера. Для этого есть и документация и пламенный энтузиазм.
Отлично! Респект за подсказку, попробую, отпишусь. А где точно узнать id диска? Я помню, что что-то прописывал, но видать не то, или не в том формате.
У меня, к сожалению, sata дисков не осталось, все снес, чтобы не жужжали. Что за нюансы с загрузочной областью, можно вкратце?
Все верно. Но я тут просто свой клинический случай рассматриваю, старый BIOS, мать без слота M.2, PCI-E 1x, AMD, Мастдай и Eclipce (собственно, ради скорости которого все это и было провернуто через самые фибры души). Конечно, если клинический букет был бы меньше, то и жисть была бы светлее))
ИМХО, несколько мудреный способ и не для всех BIOS & OS.
Вот тут с Клевером (Clover) можно добиться совсем универсального решения.
Недавно увидел сравнительный анализ решения СЛАУ на платформенном решателе ERP2. По сравнению со старым интерпритатором 1С прирост производительность в 60 раз.
Можно полюбопытствовать, каким методом решаете СЛАУ, прямым или итерационным? Если итерационным, то какова точность, т.е. подходит ли результат гарантированно для строгой банковской отчетности?
У нас в школе, к сожалению, не используется LEGO Education. Можно ли такой набор купить в розницу для своего ребенка?
Если рассматривать микропроцессоры как еще одну платформу, а это по истине гигантский рынок, то там все-таки преобладает GCC и перемен в строну CLang не ожидается. А вот переход на более изящный синтаксис C++ имеется, чипы растут в производительности и там, где раньше приходилось виртуозить на Си, периодически переходя на Асм, можно уже безболезненно использовать стандартные контейнеры из std.
Т.е. в плане унификации, сейчас GCC все же более удобен.
СLang — будем посмотреть))
В 2018 году использование НЕ Юникода? это преступление против человечности… абсурд просто.
Вот тут ответ ваш не понятен, очень хотелось бы поподробнее.
В чем именно неполноценность генерации pdb в GCC? Если может помните на вскидку, вот прямо пример, что такого вам не выгрузил в pdb GCC 7?

Насколько я помню, время проприетарного PDB от Microsoft и форматов STABS или DWARF-2 от GNU tools прошло году эдак в 2010.
Сейчас GCC выдает стандартный PDB, а для любых сред, кроме Win, по сути дела всегда применяется отладчик GDB.

Для VisualStudio, пожалуйста, используйте WinGDB, уже стало классикой, по-моему.
У JetBrains свой встроенный GUI для GDB.

Из таблицы хорошо видно, что если закрыть глаза на CLang (тут я, увы, не специалист), то вы могли вообще для всех сред использовать одну единственную среду разработки с одним компилятором и отладчиком. Да вы просто могли поднять уровень разработки на уровень БОГ! в плане унификации))
image
И если в очередном C++, например, меняется реализация std::map, и единственный компилятор GCC начинает с ключом оптимизации __attribute__((optimize(«O3»))) аллоцировать память, а без ключа — нет, то это поведение становится ПРЕДСКАЗУЕМО для всех платформ, под которые вы работаете.
Это неверное утверждение, особенно в отношении контейнеров, для чего-то другого — возможно.
Как раз сейчас в С++ контейнеры особенно модернизируются. Например, для того, чтобы эффективно работала в С++17 вот какая изящная конструкция множественной итерации.
for (auto [x,y,z] : zip( xs, ys, zs )) {
    // ...
}

Сейчас вы вынужденны применять для этой задачи все тот же сторонний Boost (реализация которого иногда тяжеловата, т.к. он опирается на существующие контейнеры, создавая над ними обертки)
for(auto&& t : zip_range(contA, contB)) {
    t.get<0>(items) = t.get<1>(items);
}

И, кстати, для окончательного отказа от указателей, в пользу новых интеллектуальных указателей или модернизированных ссылок (С++17) также придется оптимизировать/переписать реализацию всего, где происходят итерации по массивам.
1. Возможно… здесь вам точно виднее.
2. Я, разумеется, снимаю шляпу перед вашим профессионализмом, и вашего главного специалиста по С++, которого вы упомянули вначале статьи, но, по-моему, тут имеет место заблуждение…

В IDE Visual Studio (как инфраструктуре для продуктивной и комфортной работы) вы можете использовать любой компилятор, и CLang и GCC и MSVC.
Но начиная с C++11 GCC "превосходит любую доступную версию MSVC по качеству сгенерированного кода", это очевидная аксиома… Плюс именно своевременная и грамотная поддержка новых стандартов C++ и является главной вишенкой на GCC, как не парадоксально это бы ни звучало (мол как сам Microsoft может запаздывать со своим же компилятором!? Вот так и может и завидно регулярно.).

Но тут, разумеется, вопрос не в убеждениях. Надо компилировать и сравнивать производительность. Просто несколько огорчает, что в 2018 году вот так на веру берется MSVC, да еще для такого мега-кроссплатформенного национального проекта… как-то это не современно, на мой взгляд.
И еще один момент, многие наработки из Boost для работы с контейнерами перекочевывают в C++17. Вам имеет смысл потом снова проверить аллокацию памяти для std::map|set, возможно проблема будет пофиксина (как минимум в GCC) и удастся снова вернуться к стандартным контейнерам.
Две вещи выглядят не логично:
1. Почему вы не использовали везде максимальный размер wchar_t из существующих систем = 4 байта? Эффективность расширения стандарта на порядок выше, чем при его урезании.
2. Если вы уже пришли к использованию компилятора GCC для Linux, то как же вас угораздило продолжить компилировать в VS2005 под Win?? Вы же могли компилировать под обе платформы используя одну версию GCC. Сколько головной боли ушло бы с упразднением третьего компилятора, 2 против 3.
Расскажите пожалуйста, PeterG, чуть подробнее про решение НЕ в пользу
Chromium(Blink)

Первый и единственный не WebKit-подобный движок, который рассматривался как кандидат для решения задачи. Был отвергнут из-за больших различий в логике работы компонент для отрисовки HTML по сравнению с WebKitGTK+ и другой библиотеки для работы с JavaScript (V8).

Вроде бы считается, что движок V8 является одним из самых производительных для Javascript, а связка V8 + libuv позволяет реализовывать полноценный обмен с вешним миром, NODE.JS тому пример.
Что имеется в виду под «различиями в отрисовки HTML», которые оказались критичны для 1С, но с другой стороны создают конкурентное преимущество для Хрома?

И почему вы его называете не WebKit-подобным, хотя он основан на WebCore из WebKit?
Вместо того, чтобы после первой, не совсем удачной части, задуматься, почему же так много обоснованной критики и ностальгии исходит от читателей, включая самих участников повествования, автор решил окончательно удариться в политическую «сатиру», насрать на другие точки зрения очевидцев и превратить повесть в стёб…

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

А у вас будет версия текста в рулоне?
Хабр, слава богу, опять един.
Хабы делят аудиторию на клубы по интересам, т.ч. у ИТ-специалистов есть свой клуб. А еще у них есть автомобили) Пишите обязательно, ваши мысли найдут своих читателей.
Напишите, обязательно.
Возможно, именно с этих статей начнется восхождение какого-нибудь еще молодого паренька, который привнесет в отечественный бизнес что-то новое, на фоне хорошо забытого старого.
Что-то я вас не пойму, друзья. Всю статью вы заполнили хейтом, что минерализировать воду не нужно, достаточно пить витаминки. Теперь, когда вас ткнули в формулировку самого производителя, вы что, собственно, имеете мне сказать? Что производитель гонит чушь, и минерализатор лучше выкинуть?
Ну, хорошо. Я допускаю ваше мнение, пусть будет. Тоже какой-никакой итог…
Давайте таки подытожим наконец, вот тут сам производитель (по видимому решивший наконец быть честным с покупателем до конца) пишет, зачем входит в комплект к фильтру минерализатор. Пруф.
Во-первых — минерализатор все-таки входит в комплект.
А во-вторых «для долголетия и здоровья» а не для придания вкусовых качеств.

Информация

В рейтинге
Не участвует
Откуда
Москва, Москва и Московская обл., Россия
Зарегистрирован
Активность