Мы тоже не слышали подобных комментариев по поводу нашей системы от клиентов:)
Но это не багтреккер и не управление проектом. Это система групповой работы для любой компании, а не только программерской.
Кстати, вопрос «сложности использования софта» у нас очень серьезно обсуждался. Мы тоже считаем, что излишняя сложность — это серьезная помеха. Поэтому мы попытались максимально упростить систему и сделать ее юзабельной. Кроме того, даже установка TeamWox максимально упрощена и с ней может справиться штатный сисадмин компании.
250 000 — это единовременный платеж, в который входит годовая подписка. Она подразумевает техническую поддержку и бесплатные обновления всей системы в течение года.
По истечение этого срока вы вольны не платить за дополнительную подписку (150к/год), но сможете пользоваться системой без каких-либо ограничений по функционалу.
Ну а что лучше выбрать для своей компании, решать, конечно же, вам.
Конечно, можем. «Аналогов» действительно много — по нашим подсчетам только отечественных CRM-систем свыше 30. Кроме этого, есть и известные мировые пакеты. Казалось бы, аналогов более чем достаточно.
Однако, между нашим продуктом и CRM есть различие: во всех CRM-системах основной упор делается на работе с клиентом. Клиентские базы, воронки продаж, сценарии работы с клиентом, рекламные кампании и так далее. То есть CRM-системы в основном направлены на автоматизацию работы отделов маркетинга и продаж. При этом работа остальных отделов оказывается за бортом.
В нашей системе все как раз наоборот: нас интересует в первую очередь эффективное взаимодействие внутри компании, а не автоматизация продаж. Да, TeamWox уступает CRM-системам в области продаж, но она серьезно выигрывает в управлении всей компанией.
Приведу пример: допустим, в компании имеется несколько отделов разработки, отдел тестирования, документации, технической поддержки, бухгалтерии, маркетинга и продаж. Так вот средняя CRM-система сможет автоматизировать работу только двух последних, а TeamWox — всех отделов компании. Кроме автоматизации, наша система поставляет отчеты о работе сотрудников, их успеваемости, динамике фонда ЗП и многое другое.
Слово аналоги в начале сообщения не зря было написано в кавычках — СРМ системы не могут конкурировать с TeamWox в области управления компанией. Равно как и TeamWox пока не может конкурировать с СРМ системами в области организации продаж. Фактически, при всей внешней схожести это принципиально разные типы продуктов.
Мы не хотим «четкого поведения», а хотим задать хитрую задачку и посмотреть на ответы.
Пример ведь специально создан ради того, чтобы программисты могли докопаться до реального разбора механизмов исполнения операций _без_защитной_синхронизации_ (критических секций или мутексов).
БИНГО! Абсолютно правильный ответ, очень подробно и развернуто!
От себя немного добавим:
Текущие современные процессоры (P4,Core Duo) поддерживают out-of-order execution (memory-ordering model), в большей части пользовательского адресного пространства действует именно этот режим, режимы контролируются дополнительными флагами кеширования памяти.
В данном случае мы видим именно эту ситуацию, процессору позволено выполнять чтение для след. инструкции, до завершения текущей с записью (для данных с разными адресами), соответственно чтение aa[tt] происходит до записи bb[tt].
Упрощенно, процессор иногда выполняет инструкции вот так:
int temp=aa[tt];
bb[tt]=1;
test_aa[tt]=temp;
но в коде того нет, там четко написано:
bb[tt]=1;
test_aa[tt]=aa[tt];
Такой механизм оптимизации без проблемно работает для одного процессора, но в очень редких случаях на многопроцессорной машине это приводит вот к таким артефактам:
См. Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1, 7.2.3.4 «Loads May Be Reordered with Earlier Stores to Different Locations».
Спасибо, всем кто обратил свое внимание на данную задачку и искал решение.
А так как мы написали множество многопоточных серверов разнообразных уровней, где одновременно обслуживаются тысячи подключенных клиентов, то для нас это близко.
Важно, чтобы программисты знали не только основные условия синхронизации, но и имели детальное представление об особенностях низкоуровневых операций на многоядерных процессорах.
Уважаемый, Adelf!
В процессе рассмотрения кандидатов по открытым вакансиям в Компании сложилась определенная этапность:
1. Рассмотрение резюме и примеров кода на С++;
2. Небольшое тестовое задание, которое кандидат спокойно выполняет в удобное ему время дома;
3. Собеседование (продолжительность 1-1,5ч.);
4. Тестовый испытательный срок 1 месяц (оплачиваемый);
5. Трудоустройство.
Но задача ведь ставится как «не компилируя этот код (очень важно решить ее в голове)». Если в уме не получится, то остается обвешивать инклудами и в отладчик…
Но это не багтреккер и не управление проектом. Это система групповой работы для любой компании, а не только программерской.
Кстати, вопрос «сложности использования софта» у нас очень серьезно обсуждался. Мы тоже считаем, что излишняя сложность — это серьезная помеха. Поэтому мы попытались максимально упростить систему и сделать ее юзабельной. Кроме того, даже установка TeamWox максимально упрощена и с ней может справиться штатный сисадмин компании.
По истечение этого срока вы вольны не платить за дополнительную подписку (150к/год), но сможете пользоваться системой без каких-либо ограничений по функционалу.
Ну а что лучше выбрать для своей компании, решать, конечно же, вам.
Однако, между нашим продуктом и CRM есть различие: во всех CRM-системах основной упор делается на работе с клиентом. Клиентские базы, воронки продаж, сценарии работы с клиентом, рекламные кампании и так далее. То есть CRM-системы в основном направлены на автоматизацию работы отделов маркетинга и продаж. При этом работа остальных отделов оказывается за бортом.
В нашей системе все как раз наоборот: нас интересует в первую очередь эффективное взаимодействие внутри компании, а не автоматизация продаж. Да, TeamWox уступает CRM-системам в области продаж, но она серьезно выигрывает в управлении всей компанией.
Приведу пример: допустим, в компании имеется несколько отделов разработки, отдел тестирования, документации, технической поддержки, бухгалтерии, маркетинга и продаж. Так вот средняя CRM-система сможет автоматизировать работу только двух последних, а TeamWox — всех отделов компании. Кроме автоматизации, наша система поставляет отчеты о работе сотрудников, их успеваемости, динамике фонда ЗП и многое другое.
Слово аналоги в начале сообщения не зря было написано в кавычках — СРМ системы не могут конкурировать с TeamWox в области управления компанией. Равно как и TeamWox пока не может конкурировать с СРМ системами в области организации продаж. Фактически, при всей внешней схожести это принципиально разные типы продуктов.
Пример ведь специально создан ради того, чтобы программисты могли докопаться до реального разбора механизмов исполнения операций _без_защитной_синхронизации_ (критических секций или мутексов).
От себя немного добавим:
Текущие современные процессоры (P4,Core Duo) поддерживают out-of-order execution (memory-ordering model), в большей части пользовательского адресного пространства действует именно этот режим, режимы контролируются дополнительными флагами кеширования памяти.
В данном случае мы видим именно эту ситуацию, процессору позволено выполнять чтение для след. инструкции, до завершения текущей с записью (для данных с разными адресами), соответственно чтение aa[tt] происходит до записи bb[tt].
Упрощенно, процессор иногда выполняет инструкции вот так:
int temp=aa[tt];
bb[tt]=1;
test_aa[tt]=temp;
но в коде того нет, там четко написано:
bb[tt]=1;
test_aa[tt]=aa[tt];
Такой механизм оптимизации без проблемно работает для одного процессора, но в очень редких случаях на многопроцессорной машине это приводит вот к таким артефактам:
См. Intel® 64 and IA-32 Architectures Software Developer’s Manual Volume 3A: System Programming Guide, Part 1, 7.2.3.4 «Loads May Be Reordered with Earlier Stores to Different Locations».
Спасибо, всем кто обратил свое внимание на данную задачку и искал решение.
Код специально написан для того, чтобы программист был вынужден докопаться до сути проблемы.
А так как мы написали множество многопоточных серверов разнообразных уровней, где одновременно обслуживаются тысячи подключенных клиентов, то для нас это близко.
Важно, чтобы программисты знали не только основные условия синхронизации, но и имели детальное представление об особенностях низкоуровневых операций на многоядерных процессорах.
Как раз для ломки мозга.
В процессе рассмотрения кандидатов по открытым вакансиям в Компании сложилась определенная этапность:
1. Рассмотрение резюме и примеров кода на С++;
2. Небольшое тестовое задание, которое кандидат спокойно выполняет в удобное ему время дома;
3. Собеседование (продолжительность 1-1,5ч.);
4. Тестовый испытательный срок 1 месяц (оплачиваемый);
5. Трудоустройство.