• Мириады запущенных задач на C#
    0
    P.P.S. The funny part is: I actually spent some time to find out why missing tail / prologue Task.Yield() triggers recursion in this example. And my original plan for that post was to share stack traces to show where exactly it happens, why it happens, and why this optimization in TPL actually makes a lot of sense. But I ended up explaining only the side effect of that and cut the rest — solely because of a lack of time. And now I see why it looks like I didn’t dig deeply enough into why it happens, esp. taking into account the title. So maybe it’s a good lesson for my future posts :)
  • Мириады запущенных задач на C#
    0
    Hi, the author of two original posts is here. I speak Russian, but unfortunately, I don't type well in Russian, so:

    Hi, thanks for looking into this! First, let me comment on a few points you’ve mentioned:
    — “The example uses a kind of anti-pattern for async usage in C#” — that’s true, and I’ve mentioned it’s an unfair benchmark for C#. I intentionally took a well-known benchmark for goroutines knowing it’s highly disadvantageous for C# to demonstrate that async/await should be comparable even in this case in terms of performance.
    — This explains why I didn’t try to use other schedulers — frankly, I should, but that’s not what you normally do by default.
    — This also explains why I had to use Task.Yield(). It was clear to me that you can get rid of it w/ your own scheduler, and moreover, it will also improve the speed a lot.
    — I am also 90% sure that getting rid of “await Task.Yield()” is the main driver of performance improvement in your version.
    — As for GC.Collect() after warmup, true, it’s really not that important, all you might expect is a bit better + more consistent timings if your working set is fully fitting into CPU caches. Unfortunately, I’ve forgot to do the same in Go test — clearly, it has to be done the same way at least.

    As a side note, I never used StaTaskScheduler before — this is also why I was hesitant to invest into researching on what can be achieved with other schedulers. But thanks to you, I’ll take this into account next time, though I still lean to implementing a “perfectly slim” scheduler + probably, tasks as well. Based on your research, this should demonstrate that in this case C# should be light-years ahead, which is actually what I’d love to show: the asynchronous computation model there is way more extendable than in Go, so if it’s also better in terms of performance — even though you need some special tuning — this basically undermines the core promise Go makes.

    Finally, performance isn’t the only focus point in this article. I mostly wanted to show how these languages differ in terms of their approach to asynchronous computation, and obviously, you can’t do this w/o such benchmarks.

    No matter what, thanks a lot for quite useful feedback!

    P.S. If you don’t mind, I’d love to reference your post if I’ll decide to publish another post on async/await vs Go here. I plan to do this closer to .NET Core 2.1 release — likely, with more benchmarks in general. Based on what’s known so far, we should expect pretty dramatic improvements in speed for C# with this release.
  • Обработка больших объемов данных в памяти на C#
    0
    Лучше исп. Merge Sort — в этом случае паттерн доступа к памяти практически идеальный с т.з. кешей, в отличае от QuickSort.
  • 9facts: разбор полетов
    0
    И вам спасибо ;)
  • 9facts: разбор полетов
    0
    Отличная аналогия про ДНК и среду обитания. В общем, вы правы в том, что говорить об оценке идей в отрыве от всего остального просто бессмысленно. Фраза «идея не стоит ничего» этого в полной мере не передает, потому лучше её не использовать. А если использовать, то расшифровывать, что на самом деле имеется ввиду, т.к. в ином случае большинство людей поймут эту фразу совершенно прямолинейным образом.
  • 9facts: разбор полетов
    0
    Ничего не стоит в деньгах, конечно же.
  • 9facts: разбор полетов
    0
    Вопрос о том, что более важно\первично, здесь никто не ставил. Но если его поставить, + считать меру качества идеи мультипликатором — вы будете правы (вопрос не будет иметь смысла).
  • 9facts: разбор полетов
    0
    Я вложил в эту фразу стандартный для стартапов смысл. В оригинале идея 9facts казалось достаточно хорошей, и в результате я добился относительно высокой pre-money valuation во время инвестирования. И тем не менее, все это оказалось неважным, т.к. проект был закрыт.
  • 9facts: разбор полетов
    0
    Рынка идей нет и быть не может, это точно. Погуглите «ideas are worth nothing».
  • 9facts: разбор полетов
    0
    К сожалению (или к счастью), любая идея.
  • 9facts: разбор полетов
    0
    Все же на этой стадии цифры обсуждать интереснее, все остальное играет очень небольшую роль.
  • 9facts: разбор полетов
    0
    Через 3-4 года сказать о том, какие из проектов успешены, будет очень просто — они либо закроются, либо нет. Интереснее же получить какую-то информацию о них уже сейчас :)
  • 9facts: разбор полетов
    0
    Понятно — буду думать, как вопроизвести.
  • 9facts: разбор полетов
    0
    Я слегка поанализировал один из упомянутых проектов — TagBrand. Раз уж зашла речь, хочется понять, как идут дела у наиболее известных проектов (TagBrand — один из победителей TechCrunch Startup Battle).

    Его текущую аудиторию можно оценить, поиграв с tagbrand.com/users?page=1 (пользователи там отсорт. по числу бренд-инов)
    — всего зарег. пользователей — около 15К (видимо, те, что скачали и запустили приложение)
    — пользователей с 1+ бренд-ином: ~ 1500 (реально воспользовались iPhone-риложением)
    — пользователей с 3+ бренд-инами: ~ 950 (те, кто пользовались им неск. раз)
    — есть пользователи, которые сделали почти 300 бренд-инов — т.е. есть фанаты.

    На меня самого все это производит двоякое впечатление:
    — Если они не рекламировались, все это выглядит очень хорошо. Мне кажется, для веб-приложения это было бы 100% неплохим результатом.
    — С другой стороны, AppStore при первом размещении дает отличный толчек, если с приложением все хорошо. Но т.к. сам я там ничего не размещал, судить могу только по тому, что пишут другие.

    Если здесь есть эксперты по продвижению на AppStore — отпишитесь, пожалуйста.
  • Оптимизация и Generics в CLR
    0
    Для параметризации классами все медленнее потому, что для них работает type erasure с заменой на __Canon, и в результате соотв. код часто использует словари.
  • 9facts: разбор полетов
    0
    Ну, это не наш случай. Я понимаю, что оригинальная концепция явно не так хороша, как мне казалось, но не представляю пока, как её изменить таким образом, чтоб новая концепция мне нравилась.
  • 9facts: разбор полетов
    0
    Нет — когда мы делали поддержку Stack Exchange, у них еще не было authentication. Потому мы валидируем там аккаунт несколько иначе.

    И про обновления: а данные соотетвствуют действительности? Автообновляемые факты у нас не «всплывают» в лентах вверх (так же вроде-бы нет смысла, хотя и спорно).

    Если нет — попробуй пройти авторизацию заново, или включить\выключить факт профейдер. Если не поможет — напиши мне, пожалуйста. Крит. ошибки я буду исправлять.
  • 9facts: разбор полетов
    0
    Гм, ответил, но похоже, в топике ниже.
  • 9facts: разбор полетов
    0
    Привет, я получал это письмо. Извиняюсь, т.к. видимо, забыл ответить.

    Факты на сервисе обновляются автоматически (примерно раз в сутки), и так было с самого начала. Уведомления об этом не высылаются (мы этого не сдалили, т.к. большинство из таких обновлений не очень важны, а потому спорно, стоит ли писать об этом вам), но это происходит.

    Я думаю, если бы мы могли извлекать все больше и больше новых и интересных фактов о вас, это смогло бы сработать. Но на однотипных фактах — нет.
  • 9facts: разбор полетов
    0
    Все верно, решение это в конечном счете было моим. Я еще подумаю, и напишу, почему я решил прекратить тратить на это время, но в целом так: если pivot подразумевает полную смену концепции, это совсем другой проект. Такой pivot допустим в рамках стартапа, когда:

    a) Основатели считают его наиболее перспективным вариантом и готовы работать над ним
    б) Инвесторы готовы тратить на это какие-то деньги.

    В нашем случае такого варианта не нашлось.

    И о вере в проект: думаю, сводить все к этому смысла нет.

    Проекты закрываются, когда становится понятно, что дальнейшие инвестиции времени и денег в них ни к чему хорошему не приведут (т.е. вероятность этого заметно ниже приемлемой для основателей и инвесторов). Если действовать исходя исключительно из веры, все это превратится в игру в рулетку.

    Я согласен с тем, что вера в проект — то, без чего вообще нельзя начинать. Более того, известно, что есть проекты, которые взлетели исключительно благодаря огромной вере в проект и идею их основателей. Но слепая вера — совсем другое дело: хорошо известно, как среднестатистически заканчивается игра в рулетку: проигрывают почти все. Да, очень небольшой % игроков таки оказывается в плюсе, но их успех в этом случае совершенно непредсказуем (и это не противоречит гауссову распределению).
  • 9facts: разбор полетов
    0
    Отлично написано. Кстати, об Аркадии Морейнисе: если ли какая-то статистика по его проектам (просто интересно)?
  • 9facts: разбор полетов
    0
    Спасибо — только что разместил ссылку.

    Про наработки — пока ничего не понятно, как только будет понятно — я напишу.
  • 9facts: разбор полетов
    0
    Потому, что:
    а) Было не ясно, в какую сторону выполнять pivot. Кроме того, к моменту закрытия мы уже пробовали менять концепцию, но новые варианты не прошли даже самую простую валидацию (просто списывался \ созванивался с теми, кого эти варианты потенциально могли заинтересовать).
    a) На момент закрытия проекта мы потратили 80-85% имеющихся средств. Продолжать тратить и дальше было можно, но т.к. было не ясно, в какую сторону выполнять pivot, я сам был за то, чтоб заморозить все максимально быстро.
  • 9facts: разбор полетов
    0
    Просто в стартапах год за два идет :)
  • 9facts: разбор полетов
    0
    > следил все эти два года за 9facts
    Здесь явно что-то не то (см. на даты) :)

    1 — Да, так оно и было. И с сентября по ноябрь я действительно как-то не очень понимал, что это — самая серьезная из наших проблем.

    2 — Тоже верно — какое-то время я не считал это важным. Почему-то у меня (да и не только у меня) в голове сидела такая мысль: «Главное — сделать сервис привлекательным для первого-второго-третьего посещения, а уж дальше будет думать о том, что дальше». На самом это огромный минус, если сервис с первого взгляда производит впечатление одноразового, т.к. даже регистрироваться на нам желания не возникает (ну и + англ.).

    В общем, к декабрю я все это и сам понял, но так и не придумал, как решить эту проблему.

    > Это круто, что наконец вы и сами это поняли, но можно было услышать это от людей ещё полтора года назад!
    Полтора года назад этого никак нельзя было услышать :)

    3 — Думаю, Леонид был несколько более скептично настроен, нежели я, но я не помню, чтоб в части п.2 у нас сильно расходились оценки.
  • 9facts: разбор полетов
    +1
    IMO, за хорошую юзабельность стоит бороться с самого начала только в одном случае: если это будет существенным конкурентным преимуществом. А это значит, что:
    — уже есть конкуренты, с которыми надо бороться
    — идея уже провалидирована ими.

    Потому это не совсем наш случай.
  • 9facts: разбор полетов
    0
    Я был бы рад, но т.к. с осенью все сложно, не знаю, получится ли. Детали в ЛС.
  • 9facts: разбор полетов
    0
    > Александр, я дальнейшее пишу без наездов, вы не обижайтесь, если что )
    Какие тут могут быть обиды :)

    > Пишу, во-первых, потому, что такой паттерн узнаю у 90% адекватных проектов, с которыми приходится иметь дело
    Полностью согласен, + про все дальнейшее. Грабли стандартные.

    > Кстати, как вы теперь считаете — насколько вы похожи с Klout?
    Сходство только в том, что оба проекта дают подборку метрик, позволяющих оценить вашу значимость в соцсетях. Только в нашем случае это просто несколько из возможных метрик, Klout же полностью «заточен» под анализ вашей популярности. Собственно, это еще +100 в пользу того, что специализированный продукт лучше универсального.
  • 9facts: разбор полетов
    0
    Я выше написал, чем именно это лучше. Если для разработки прототипа нужно продать квартиру — это не прототип.

    Я имел ввиду следующее: если вы, условно, разабатываете 100К, и при этом пустите ваши выходные в течение полугода на разработку прототипа, он обойдется вам ~ в 40K x 6 = 240K. Если вас будет двое — в 500К. Относительно небольшая сумма, в общем.
  • 9facts: разбор полетов
    0
    Гм, фотке пара лет всего :)
  • 9facts: разбор полетов
    0
    Это верно.
  • 9facts: разбор полетов
    0
    1) Решаемая проблема есть у следующих категорий пользователей

    Думаю, это нас и смутило. Проблема действительно есть: практически вся информация о людях, которая есть сейчас в соцсетях — неструктурирована, потому масса задач, которые можно было бы решать, сейчас не решаются. Нам казалось, что продукт, который позволит сохранять структурированную информацию о людях, гарантированно будет успешным. С этим соглашались и те, кого я опрашивал (понятно, что речь шла о конкретных сценариях использования).

    На самом же деле все не так просто:
    1) Тех, кому такой продукт был бы интересен, хотят иметь возможность получать / искать нужную им информацию с его помощью (прямым образом, или косвенно — например, проводя маркетинговые акции с его помощью). Не ввводить. Т.е. для того, чтоб эта категория пользователей захотела воспользоваться продуктом (и соответственно, захотела платить за это), нужно, чтоб пользователи там уже были.
    2) Вводить же информацию о себе и друзьях не настолько интересно, чтоб это вас там удерживало. В этой части мы сделали многое, но сделать это настолько удобным, чтоб пользователи действительно полюбили это, нам не удалось.

    Сейчас ясно, что все опросы, связанные с потенциальными сценариями использования продукта, надо было проводить, ориентируясь исключительно на 2), а про 1) вообще забыть. Но мне почему-то думалось, что проблема воода и сбора фактов — решаемая, т.к. все социальные сети так или иначе делают это.

    На самом же деле все не так, конечно — пользователи соцсетей оставляют там факты о себе неявно. Факты о людях в соцсетях — это побочный эффект того, что люди решают там другие важные для них проблемы (общение, знакомства и т.п.). Похоже, целенаправленно оставлять факты о себе и других никто не стал бы — по крайне мере, я не знаю, как этого добиться. Кроме того, в случае с фактами о себе играют роль такие сдерживающие факторы, как нежелание писать о том, что уже не актуально (хотя и значимо), нежеление выглядеть хвастуном и т.п.
  • 9facts: разбор полетов
    0
    > Достаточно сказать, что в июле-сентябре над проектом одновременно работало до 8 человек

    Команда из 8 человек «проедает» миллион за, условно, 2.5 месяца.
  • 9facts: разбор полетов
    0
    Да, не слышал, хотя Кавасаки тоже читал. Сейчас помсмотрю, спасибо.
  • 9facts: разбор полетов
    0
    Цели прототипирования у инженеров с многотысячелетним стажем — несколько иные (минимизации технических / технологических рисков).
  • 9facts: разбор полетов
    +2
    Никакого обмена с обеих сторон не было. Кроме того, я — не вчерашний студент. Я действительно чувствую себя виноватым, но думаю, это абсолютно справедливо, т.к. все зависело на много % от меня лично.
  • 9facts: разбор полетов
    0
    Общая сумма инвестиций была порядка 3 млн., ~ половина из них была вложена нами. Про то, как убеждать инвесторов, я ничего не могу сказать, и кроме того, не советую делать это без прототипа и 1000 пользователей — это неимоверно увеличивает вероятность того, что время и деньги будут потрачену впустую. Впрочем, я об этом сказал выше :)
  • 9facts: разбор полетов
    +1
    Никак не «разменивается». Просто лично я немного устал от этого — все же почти 8 лет им занимался.
  • 9facts: разбор полетов
    0
    Мы думаем над этим.
  • 9facts: разбор полетов
    0
    Да, так оно. Идея с шаблонами фактов была хорошей только на бумаге.