Здравствуйте, jazzer, Вы писали:
I>>Если это твой ответ, то ты слился, кода нет, только сигнатуры Собственно для сиплюсника это стандартный ответ — показать сигнатуры и рассказать что всё классно.
J>А какой тебе код нужен? Код cont? Так он вот таким будет: "textBox.Text += result"
Приведи аналог моего код.
I>>Мне скажем дописать пару строк и будет совершенно другая вещь, комбинация синхронного и асинхронного. А у тебя что получится ?
I>>
I>>private async void handler(object sender, TaskArgs args)
I>>{
I>> string result = await new Task(() => Download(args.Url, args.Cancellation));
I>> if(SomeCondition(rawResult))
I>> {
I>> result = await new Task(() => Preproces(result, args.Cancellation));
I>> }
I>> textBox.Text += result;
I>>}
I>>
J>И где тут "совершенно другая вещь"? J>Всё то же самое.
Здесь комбинация синхронного и асинхронного кода, в прошлом примере был только асинхронный.
Здравствуйте, jazzer, Вы писали:
J>Здравствуйте, Ikemefula, Вы писали:
I>>Можно зайти с другой стороны — какие известные бизнес приложения были написаны на С++ ? Ну скажем для бухгалтерии, инвентаризации, страхования, учет и тд и тд ?
J>1С, вестимо
Здравствуйте, Ikemefula, Вы писали:
J>>1С, вестимо
I>1С началась в 2005м ? Выдыхай что ли
Практически да. Как тебе хорошо известно, 1С с восьмой версиии была практически полностью переписана, в ней добавлена туева хуча функций и возможностей, это практически новая система по сравнению с последней 1С 7.7. Все части 1С (серверные, клиентская) стали мультиплатформенными (доступны также и под Линуксом).
Теперь ты выдыхай.
Здравствуйте, MTD, Вы писали:
IT>>С каких пор обёртки для указателей стали частью языка? MTD>С тех самых, как их в стандарте описали.
Т.е. больше в стандарте описывать нечего? А я и думаю, почему это последние стандарты языка вызывают у публики такую, мягко говоря, неоднозначную реакцию.
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, gandjustas, Вы писали:
N>>>>>>На планшетах тем более ресурс, никто не хочет жить на зарядке. G>>>>>Память? А причем тут зарядка? EP>>>>Performance bottleneck большинства программ это взаимодействие с иерархией памяти. G>>>Это ты про какие программы? G>>>Среднее дсктопное приложение более 90% времени проводит в ожидании пользователя. Еще 9% в ожидании завершения IO. EP>>Я имел ввиду performance "активной" работы процессора. Плохая работа с памятью -> процессор будет дольше находится в "активном" режиме. G>Угу, то есть ты имеешь ввиду 1% времени работы программы. Ты же понимаешь что изменение даже в несколько раз на этом 1% никто не заметить.
Если активный режим процессора это один из главных потребителей зарядки, то уменьшение такого времени — будет уменьшать потребление
EP>>>>Плохой memory layout структур данных, лишние индерекции, лишние аллокации, плохая работа с кэшем — это всё яд для производительности — этим всем грешат "управляемые среды", поэтому и производительность намного хуже. G>>>Бросай читать книжки 80-х годов. EP>>Поясни EP>>>>Требуется в 10 раз больше памяти? — косвенный признак тормозов. G>>>Спорный вопрос. Если в памяти кешируется результат чтения с диска, то я предпочту в 10 раз больше памяти. EP>>Речь шла об одинаковых алгоритмах и структурах в разных языках. EP>>Сравнивать производительность сред/языков по разным алгоритмам и структурам как-то совсем неправильно.
G>Вот я и говорю бросай книжки читать. Подавляющее большинство десктопных приложений не требует ресурсоемких алгоритмов.
А я где-то утверждал обратное?
Есть много приложений, которые максимум что делают так это считывают три байтика с диска, показывают формочку, и складывают две цифирьки — и да, нужны люди которые будут писать такие приложения, много людей
G>А если требует то важна не сама скорость работы, а perceived performance.
Если вычисление идёт 30 минут, вместо возможных десяти секунд, то ты хоть как украшай progress bar рюшечками — это не поможет.
G>Например ты делаешь приложение, которое делает graph layout — довольно сложные алгоритмы. Как ты думаешь что больше приглянется пользователям: молчаливый расчет всего за 10 сек потом отображение результата, или рисование узлов графа по мере вычисления позиций в течение 15 секунд? G>100% пользователей предпочтут второе, хотя реально оно в 1,5 раз медленнее.
Пользователи предпочтут рисование по мере вычисления за пол-секунды
G>При замедлении алгоритма perceived performance растет. G>В C++ увы такими оптимизациями сложно заниматься, потому что требуется совмещать продолжения
Ты вроде как толком не ответил, что не так с продолжениями в C++
G>и детерминированную финализацию.
Это которая using? И типа в C++ с ней плохо?
EP>>>>Чтобы делать быстрый код в "управляемых средах" — нужно работать против языка, отказываться от многих средств выражения идей, спускаясь на крайне низкий уровень (даже ниже чем C).
[...] G>Ну Java вообще беден как язык, а в C# можно и массив структур сделать.
Структуры в C# далеко не дефолт, и имеют ограничения.
Суть в том, что tight memory layout существенно влияет на производительность, пример с массивом структур это лишь одна часть проблемы, а ведь есть ещё композиция объектов, объекты на стеке.
G>Но это не самое важное.
скажи это разработчикам escape analysis.
G>Самое важное тут: как ты будешь получать этот массив и как обрабатывать. Если у тебя обработка ограниченного количества элементов за раз, то может вообще нет смысла держать в памяти все 32М, а читать с диска, на лету обрабатывать и выводить.
Нет, каждый элемент нужно обрабатывать много раз. Причём такие элементы будут хранится не только в массиве — это общий пример на простой абстракции в виде группировки элементов
EP>>То что ты достиг скорости приемлемой для твоей задачи, вовсе не означает что программа использует ресурсы эффективно (что естественно не является самоцелью), и что её производительность нельзя улучшить на пару порядков. G>А зачем? Цель не оптимизация сама по себе, цель — чтобы программа работала достаточно быстро.
А я и не говорил что оптимизация это самоцель — действительно, если тебе нужно обрабатывать 90 байтиков в секунду, то можешь хоть visual basic взять
Здравствуйте, D. Mon, Вы писали:
MTD>>Много. Только из того, что у меня сейчас открыто: Google Chrome, Skype, Virtual Box, Qt Creator. DM>Google Chrome — обертка над WebKit, который тянется с прошлого века (Initial release November 4, 1998).
Справедливости ради, Хром — это обёртка на WebCore (часть WebKit), и хромой WebCore ныне принял новое имя — Blink. Что бы было понятно, что это — это такая хрень которая в принципе выполняет львиную часть работы, но в тоже самое время абсолютно бесполезна, без тонны другого кода. Среди этой тонны другого кода ярко выделяются, например V8 и Skia, — обоих без зазрения совести можно назвать вполне новыми проектами, написанными на C++.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Задача сделать простейшею абстракцию, которая существует с незапамятных времён и используется повсеместно, в виде группировки разнотипных данных(хотя бы однотипных) в одну сущность(структуру/запись/класс), так чтобы её можно было использовать с разными типами контейнеров, в том числе массивов, без просадки скорости на порядок.
Это не задача, а уже конкретное решение какой то задачи. Разницу чувствуешь ?
I>>>>Это ни о чем. EP>>>Это мнение человека который разрабатывал алгоритмические библиотеки для Scheme, Ada, Java, C++ I>>Это уже устаревший подход.
EP>Допустим эффективные алгоритмы и структуры данных это устаревший подход, тогда какой современный? "Петрович, подвози исчё кластера"
Современный подход это когда учитывается не только процессорное время, но и время IO и тд и тд и это тоже перформанс.
EP>stackful coroutines — реализованы с использованием system-specific вызовов EP>stackless coroutines — реализованы на чистом ISO C++, меньше чем 100 строками кода EP>state machine — бери хоть банальный switch, хоть готовые библиотеки
I>>а лямбды сильно кастрированые что бы их называть таким словом. EP>конкретные аргументы?
Для полноценных замыканий нужен GC, ибо не совсем ясно, где и когда ты будешь память освобождать.
I>>https://code.google.com/p/sphinxsearch/source/browse/ I>>Как думаешь, нужен ли здесь перформанс ?
EP>То что где-то используют C или "C-подобный подход" отнюдь не означает что по другому нельзя. А вот наличие библиотеки с другим подходом которая быстра и резва, как раз и является примером тому что таки можно.
А я разве говорил что так нельзя писать ? Ты про чтото свое, наболевшее рассказываешь. Большинство людей работает именно с некачественным кодом, это очевидно как божий день — чем ниже качество кода, тем больше нужно девелоперов что бы укладываться в сроки, требования и ограничения.
Вот пример — на старом проекте я довольно долго занимался одной частью проекта и старательно все вылизывал, что бы легче было майнтейнить код. В какой то момент оказалось, что только я и понимаю, что там происходит унутре, потому что другим вообще незачем было туда лазить, а если и случалось чего, фиксы занимали минуты. Зато буквально в соседнем модуле, над которым потрудился индус, копались буквально все, потому что каждому надо было чего то фиксить.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>>>Я имел ввиду performance "активной" работы процессора. Плохая работа с памятью -> процессор будет дольше находится в "активном" режиме. G>>Угу, то есть ты имеешь ввиду 1% времени работы программы. Ты же понимаешь что изменение даже в несколько раз на этом 1% никто не заметить.
EP>Если активный режим процессора это один из главных потребителей зарядки, то уменьшение такого времени — будет уменьшать потребление
Правильно и это делается за счет написания корректного кода. Внимание — корректного. Теперь фокус — вкладываешь диск в лоток, закрываешь и пока он не открылся, проверяешь отзывчивость UI. Вопрос — куда делась корректность ? И это типично для C++.
EP>>>Речь шла об одинаковых алгоритмах и структурах в разных языках. EP>>>Сравнивать производительность сред/языков по разным алгоритмам и структурам как-то совсем неправильно.
G>>Вот я и говорю бросай книжки читать. Подавляющее большинство десктопных приложений не требует ресурсоемких алгоритмов.
Наоборот, они ресурсоемкие, только это больше не ограничивается тактами процессора.
G>>Например ты делаешь приложение, которое делает graph layout — довольно сложные алгоритмы. Как ты думаешь что больше приглянется пользователям: молчаливый расчет всего за 10 сек потом отображение результата, или рисование узлов графа по мере вычисления позиций в течение 15 секунд? G>>100% пользователей предпочтут второе, хотя реально оно в 1,5 раз медленнее.
EP>Пользователи предпочтут рисование по мере вычисления за пол-секунды
Если ты на алгоритмах для графа добьешься такой разницы, навроде 15 сек на дотнете и полсекунды на С++, смело требуй нобелевку.
EP>Структуры в C# далеко не дефолт, и имеют ограничения. EP>Суть в том, что tight memory layout существенно влияет на производительность, пример с массивом структур это лишь одна часть проблемы, а ведь есть ещё композиция объектов, объекты на стеке.
Здравствуйте, Nuzhny, Вы писали:
N>Здравствуйте, Ikemefula, Вы писали:
J>>>1С, вестимо
I>>1С началась в 2005м ? Выдыхай что ли
N>Практически да. Как тебе хорошо известно, 1С с восьмой версиии была практически полностью переписана,
Это уже никому не интересно, какой процесс разработки, революционное переписывание или эволюционный реинжиниринг.
Здравствуйте, Mystic, Вы писали:
NC>>Ada — совершенно стандартный язык с унылым паскалеподобным синтаксисом.
M>Паскалеподобный синтаксис делает работу с компилятором куда более дружественной. Если ты допускаешь опечатку в коде, то сообщение об ошибке в 99% случаев говорит о том, какую ты опечатку допустил. Например, пропущена точка с запятой, или еще что. В C++ очень часто опечатка дает возможность построения новой языковой конструкции, компитятор идет дальше, останавливается когда уже дрова полные, и выдает в качестве сообщение нечто несуразное. А если заюзаны шаблоны, то и многоэтаэжное.
Это далеко не всем надо Многие не готовы за платить за красивую понятную диагностику многословностью.
Одним из 33 полных кавалеров ордена "За заслуги перед Отечеством" является Геннадий Хазанов.
IT>>С каких пор обёртки для указателей стали частью языка?
MTD>С тех самых, как их в стандарте описали.
Стандарт описывает сам язык и STL. Думаю имелось в виду первое но даже то что стандарт легализует не отменяет самого факта — подпорки остаются подпорками.
Справедливости ради следует отметить что и в C# и в .NET-е есть своя подпорка в виде IDisposable и using. Ну не вписываются неуправляемые ресурсы в языки с мусоросборщиком. Только все равно программировать на Шарпе проще.
I>>А стоит сказать это в форуме С++, минусов будет на три страницы.
MTD>Откуда такая уверенность?
Нормальные софтвере инженеры в тот форум редко, если вообще когда, заглядывают. Это больше место для школоты до которой не доходит и вряд ли дойдет что большинство фич из плюсов не нужны для нормального кода.
Здравствуйте, Ikemefula, Вы писали:
EP>>Задача сделать простейшею абстракцию, которая существует с незапамятных времён и используется повсеместно, в виде группировки разнотипных данных(хотя бы однотипных) в одну сущность(структуру/запись/класс), так чтобы её можно было использовать с разными типами контейнеров, в том числе массивов, без просадки скорости на порядок. I>Это не задача, а уже конкретное решение какой то задачи. Разницу чувствуешь ?
Это передёргивание — та задача о которой ты говоришь будет решением другой задачи, та в свою очередь и т.п. В итоге выйдем на задачу "прибыльный бизнес".
Группировка разнотипных данных вездесуща в императивных языках — зачем это отрицать что это задача? На определённом уровне это вполне себе задача
I>>>а лямбды сильно кастрированые что бы их называть таким словом. EP>>конкретные аргументы? I>Для полноценных замыканий нужен GC, ибо не совсем ясно, где и когда ты будешь память освобождать.
Зависит от. Где-то будет подсчёт ссылок, где-то копирование, где-то move, а где-то вообще полностью pre-allocated с выделением целого блока на задачу и очистка всего блока по завершению.
I>>>https://code.google.com/p/sphinxsearch/source/browse/ I>>>Как думаешь, нужен ли здесь перформанс ? EP>>То что где-то используют C или "C-подобный подход" отнюдь не означает что по другому нельзя. А вот наличие библиотеки с другим подходом которая быстра и резва, как раз и является примером тому что таки можно. I>А я разве говорил что так нельзя писать ? Ты про чтото свое, наболевшее рассказываешь.
Ты написал:
Почему то самые критичные куски кода пишутся практически на С или подобным образом.
Я привел пример number-crunch проекта где это далеко не так, и при этом он составляет конкуренцию коммерческим решениям.
I>Большинство людей работает именно с некачественным кодом, это очевидно как божий день — чем ниже качество кода, тем больше нужно девелоперов что бы укладываться в сроки, требования и ограничения.
Это ты к чему вообще? Да, плохой код есть, причём на разных языках.
I>Вот пример — на старом проекте я довольно долго занимался одной частью проекта и старательно все вылизывал, что бы легче было майнтейнить код. В какой то момент оказалось, что только я и понимаю, что там происходит унутре, потому что другим вообще незачем было туда лазить, а если и случалось чего, фиксы занимали минуты. Зато буквально в соседнем модуле, над которым потрудился индус, копались буквально все, потому что каждому надо было чего то фиксить.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это передёргивание — та задача о которой ты говоришь будет решением другой задачи, та в свою очередь и т.п. В итоге выйдем на задачу "прибыльный бизнес". EP>Группировка разнотипных данных вездесуща в императивных языках — зачем это отрицать что это задача? На определённом уровне это вполне себе задача
Группировки они разные бывают. Внятно дай задачу в терминах пользователя. Ты пока что привел решение этой задачи непойми в каких терминах.
I>>Для полноценных замыканий нужен GC, ибо не совсем ясно, где и когда ты будешь память освобождать.
EP>Зависит от. Где-то будет подсчёт ссылок, где-то копирование, где-то move, а где-то вообще полностью pre-allocated с выделением целого блока на задачу и очистка всего блока по завершению.
То есть, стратегия использования памяти зависит от того кода,который пишешь. Об чем и речь, это и есть кастрированые замыкания.
EP>Ты написал: EP>
EP>Почему то самые критичные куски кода пишутся практически на С или подобным образом.
EP>Я привел пример number-crunch проекта где это далеко не так, и при этом он составляет конкуренцию коммерческим решениям.
И ты утверждаешь, что именно это и есть типичный с++ код ? Как бы не так. Прямо в этом форуме, в КСВ, в С++ полно людей которые считают использование не то что буста, а темплейтов преступлением.
I>>Большинство людей работает именно с некачественным кодом, это очевидно как божий день — чем ниже качество кода, тем больше нужно девелоперов что бы укладываться в сроки, требования и ограничения. EP>Это ты к чему вообще? Да, плохой код есть, причём на разных языках.
Я к тому, какой типичный код на С++ и какая доля разрабов его майнтейнит.
I>>Вот пример — на старом проекте я довольно долго занимался одной частью проекта и старательно все вылизывал, что бы легче было майнтейнить код. В какой то момент оказалось, что только я и понимаю, что там происходит унутре, потому что другим вообще незачем было туда лазить, а если и случалось чего, фиксы занимали минуты. Зато буквально в соседнем модуле, над которым потрудился индус, копались буквально все, потому что каждому надо было чего то фиксить.
EP>Молодец Чего сказать-то хотел?
Уже все сказано. На одном проекте 40 индусов майнтейнят либу для линейного программирования, а на другом один человек майнтейнит такую же либу да же пачку из других областей. Вопрос — какой код считать типичным для этого примера ?
Здравствуйте, Ikemefula, Вы писали:
I>Правильно и это делается за счет написания корректного кода. Внимание — корректного. Теперь фокус — вкладываешь диск в лоток, закрываешь и пока он не открылся, проверяешь отзывчивость UI. Вопрос — куда делась корректность ? И это типично для C++.
Это ты все эти CD-ejector'ы разрабатывал? С отзывчивым UI и корректностью, ага
А теперь внимание, фокус: вставляешь 5.25 в дисковод, закрываешь, издаётся характерное жужжание, и вдруг КЛАЦ! Казалось бы, при чём здесь Лужков? И это всё типично для C#
EP>>Структуры в C# далеко не дефолт, и имеют ограничения. EP>>Суть в том, что tight memory layout существенно влияет на производительность, пример с массивом структур это лишь одна часть проблемы, а ведь есть ещё композиция объектов, объекты на стеке. I>Для каких приложений это критично ?
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Это ты все эти CD-ejector'ы разрабатывал? С отзывчивым UI и корректностью, ага
Это все писалось на С и С++, потому что люди просто не могут нормально реализовать асинхронщину.
EP>А теперь внимание, фокус: вставляешь 5.25 в дисковод, закрываешь, издаётся характерное жужжание, и вдруг КЛАЦ! Казалось бы, при чём здесь Лужков? И это всё типично для C#
Когда были такие дисководы, шансов на асинхронщину было еще меньше.
EP>>>Структуры в C# далеко не дефолт, и имеют ограничения. EP>>>Суть в том, что tight memory layout существенно влияет на производительность, пример с массивом структур это лишь одна часть проблемы, а ведь есть ещё композиция объектов, объекты на стеке. I>>Для каких приложений это критично ?
EP>Критично там где нужна производительность
Здравствуйте, Ikemefula, Вы писали:
I>>>По моему это есть всяких сортов пляски. Хотя я не уверен, давно пора пляски с памятью и стеком сделать частью языка С++, как это было сделано со смартпоинтерами. Тогда уж точно нельзя будет придраться
FR>>Как будто код с async который ты чуть выше привел не занимается за кулисами тем же самым.
I>Очевидно — нет.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Здравствуйте, gandjustas, Вы писали:
N>>>>>>>На планшетах тем более ресурс, никто не хочет жить на зарядке. G>>>>>>Память? А причем тут зарядка? EP>>>>>Performance bottleneck большинства программ это взаимодействие с иерархией памяти. G>>>>Это ты про какие программы? G>>>>Среднее дсктопное приложение более 90% времени проводит в ожидании пользователя. Еще 9% в ожидании завершения IO. EP>>>Я имел ввиду performance "активной" работы процессора. Плохая работа с памятью -> процессор будет дольше находится в "активном" режиме. G>>Угу, то есть ты имеешь ввиду 1% времени работы программы. Ты же понимаешь что изменение даже в несколько раз на этом 1% никто не заметить.
EP>Если активный режим процессора это один из главных потребителей зарядки, то уменьшение такого времени — будет уменьшать потребление
неверно. Смысл какой уменьшать этот один процент до 0.5%? Ну станет зарядка держать на 2-3 минуты дольше. А если ты эффективнее IO сделаешь в 2 раза, то сохранишь 4,5% зарядки, что будет уже 10-15 минут.
EP>Есть много приложений, которые максимум что делают так это считывают три байтика с диска, показывают формочку, и складывают две цифирьки — и да, нужны люди которые будут писать такие приложения, много людей
Угу, и зачем им C++?
G>>А если требует то важна не сама скорость работы, а perceived performance. EP>Если вычисление идёт 30 минут, вместо возможных десяти секунд, то ты хоть как украшай progress bar рюшечками — это не поможет.
30 минут надо считать на сервере, клиент может столько и не прожить.
G>>Например ты делаешь приложение, которое делает graph layout — довольно сложные алгоритмы. Как ты думаешь что больше приглянется пользователям: молчаливый расчет всего за 10 сек потом отображение результата, или рисование узлов графа по мере вычисления позиций в течение 15 секунд? G>>100% пользователей предпочтут второе, хотя реально оно в 1,5 раз медленнее.
EP>Пользователи предпочтут рисование по мере вычисления за пол-секунды
Увы, 10 сек это максимум что можно выжать, даже при экстремальной оптимизации.
G>>При замедлении алгоритма perceived performance растет. G>>В C++ увы такими оптимизациями сложно заниматься, потому что требуется совмещать продолжения
EP>Ты вроде как толком не ответил, что не так с продолжениями в C++
то что их просто нет, а если сделать, то бестолку. Ибо комбинировать продолжения с передачей данных будет сложно, придется париться с освобождением памяти. Да и тупо может продолжение не прийти.
G>>и детерминированную финализацию. EP>Это которая using? И типа в C++ с ней плохо?
Еще раз: продолжения+детерминированная финализация. Вместе, а не по-отдельности. В общем случае нельзя придумать способ гарантированной очистки памяти. Продолжение может просто не вызваться и будет держать ссылку на замыкание.
В некоторых условиях можно, но условия будут постоянно меняться от структуры кода. замучаешься следить.
G>>Самое важное тут: как ты будешь получать этот массив и как обрабатывать. Если у тебя обработка ограниченного количества элементов за раз, то может вообще нет смысла держать в памяти все 32М, а читать с диска, на лету обрабатывать и выводить.
EP>Нет, каждый элемент нужно обрабатывать много раз. Причём такие элементы будут хранится не только в массиве — это общий пример на простой абстракции в виде группировки элементов
Ниче не понял, приведи пример.
EP>>>То что ты достиг скорости приемлемой для твоей задачи, вовсе не означает что программа использует ресурсы эффективно (что естественно не является самоцелью), и что её производительность нельзя улучшить на пару порядков. G>>А зачем? Цель не оптимизация сама по себе, цель — чтобы программа работала достаточно быстро.
EP>А я и не говорил что оптимизация это самоцель — действительно, если тебе нужно обрабатывать 90 байтиков в секунду, то можешь хоть visual basic взять
Среднее десктопное приложение обрабатывает и того меньше.
Ты сам доказываешь что C++ не нужен и это совсем не мейнстрим.
Здравствуйте, gandjustas, Вы писали:
G>А что ты показал? Передача указателя на функцию? Даже без замыканий.
Я показал работу с ресурсами в коде с замыканиями. И по значению, и по ссылке с деаллокацией в конце.
Именно то, о чем ты меня просил.
Именно то, что, по твоему мнению, в С++ требует "аццких плясок".
Так что не надо тут рассказывать, что ты хотел на самом деле IO и/или многопоточность. Речь шла об управлении ресурсами. Тебя ответ устроил? Или что-то осталось непонятым?
Собственно для сиплюсника это стандартный ответ — показать сигнатуры и рассказать что всё классно.
Если нам не помогут, то мы тоже никого не пощадим.
Чего сказать-то хотел?
