Pull to refresh
0
0

C# Developer

Send message
Столкнулся с этой проблемой в Crossout.
Купил 1080б а оно тормозит. Процессор проставивает, GPU простаивает — а оно тормозит.
Решил проблему тем, что в настройках игры выставил принудительную частоту кадров 60, а в драйвере включил FastSync.
Сразу стало плавно и никаких рассинхронизаций.
Движок не дурак — если не успевает рендерить 60fps, то сам «пропускает кадры».
А кто ж теперь поймет?
Единственное, что можно сказать точно — вырос, потому что стали больше покупать их акции.
В частности потому, что andreyverbin купил их акции, т.к. решил, что они вырастут на OpenSource ;)
Нифига. Монетка может всегда падать одной стороной. А если всегда поворачивать в одну сторону — будете ездить по кругу :)
ответ был для nsklizard
У Бойера-Мура конечно более изящное решение — не меняет входные данные и сложность стабильно O(N)
Про яркость — там же не зря написан черный и белый текст. Если бы фон был одинаковый по яркости, то текст читался бы одинаково.
Про красный — яркость это не белизна. Яркость — это как бы количество испускаемых фотонов в единицу времени. Например если взять красный светодиод и повышать его яркость — он никогда не начнет светить белым или розовым, как на картинке.
yield можно использовать в любом коде, главное учитывать его оверхед.
Если вычислительная сложность задачи между yield'ами высокая, то влияние самого yield'а будет ничтожным.
.Net Core вполне себе кросс-платформенный.
И есть даже возможность компиляции нативных бинарников (например CoreRT).
Mono разве что в Unitiy, и то со временем думаю перейдут на Core.
Честно говоря не очень ясно, кому сегодня нужен чистый Mono, когда есть .Net Core. Учитывая что MS купили Xamarin вместе с Mono и частично используют его в Core.
Сделал условие циклов по s1.Length и s2.Length
Убрал преобразование строки в массив байт.
Эта версия работает 0.63 сек
using System;
using System.Diagnostics;
using System.Linq;

public class Program
{
    public static Int32 LevDist(string s1, string s2)
    {
        var m = s1.Length;
        var n = s2.Length;

        // Edge cases.
        if (m == 0)
        {
            return n;
        }
        if (n == 0)
        {
            return m;
        }

        var v0 = Enumerable.Range(0, n + 1).ToArray();
        var v1 = new int[n + 1];
        v0.CopyTo(v1, 0);

        for (var i = 0; i < s1.Length; ++i)
        {
            v1[0] = i + 1;

            for (var j = 0; j < s2.Length; ++j)
            {
                var substCost = (s1[i] == s2[j]) ? v0[j] : (v0[j] + 1);
                var delCost = v0[j + 1] + 1;
                var insCost = v1[j] + 1;

                v1[j + 1] = Math.Min(substCost, delCost);
                if (insCost < v1[j + 1])
                {
                    v1[j + 1] = insCost;
                }
            }

            var temp = v0;
            v0 = v1;
            v1 = temp;
        }

        return v0[n];
    }

    public static void Main()
    {
        var s1 = new String('a', 15000);
        var s2 = new String('a', 15000);
        var s3 = new String('b', 15000);

        for (var i = 0; i < 5; i++)
        {
            Stopwatch execTimer = new Stopwatch();
            execTimer.Start();

            Console.WriteLine(LevDist(s1, s2));
            Console.WriteLine(LevDist(s1, s3));

            execTimer.Stop();
            var execTime = execTimer.ElapsedMilliseconds / 1000.0;

            Console.WriteLine($"Finished in {execTime:0.000}s");
        }
    }
}


Unsafe версию не выкладываю — она работает примерно так же. Видимо из-за необходимости пинить указатель, или ещё какие-то накладные расходы вылазят.

пс. кстати у вас в описании теста указан размер строки 20000, а в бенчах везде 15000. Это так задумано?
Реально работает.
В моём случае оригинальная версия работает 0,84с, версия с a.Length работает 0,68с, а unsafe версия работает 0.63с.
Я и не думал об этом, хотя всегда использую именно a.Length, но не для скорости, а чтоб не накосячить.
Включение галки Optimize Code в Net Core 3.1 ускоряет выполнение в 4 раза на моём i7-4790 (0,9с против 3.6с)
Кроме того C# используют безопасное обращение к массиву.
Автор просто в колонку «наихудшее» поместил ожидаемое значение, а не наихудшее.
Худший случай в данном случае и есть «бесконечное много бросков», т.к. вероятность попасть за N бросков стремится к 1, при N->∞
wiki говорит что от такого обозначения ушли из-за путаницы.
Сейчас Gbit или Gibit, в российском ГОСТе Гбит.
Меня запутало Gb. Обычно биты обозначают Gbits
Основной профит оптана — на порядок более низкие задержки при чтении.
В основном это даёт существенный выигрыш на операциях с мелкими блоками в 1 поток.
При куче потоков или линейных операциях разницы конечно не заметить.
По моим представлениям — это типичная нагрузка в играх, при подгрузке ресурсов.
Другой вопрос — будет ли заметный эффект, т.к. современный SSD + RAM Cache итак неплохо справляются.
Не зря оптан позиционирют в первую очередь для корпоративного сегмента — различные бигдаты просто тащутся от оптана.
Почему в графе «Память» для всех накопителей указано «128Gb 20nm Intel 3D XPoint»?
Это же не значит, что во всех оптанах стоит один и тот же 128 гиговый чип, программно ограниченный?
интересно, что быстрее деградирует — сам излучатель или люминофор?
Много делаю UI в WPF и могу сказать, что подобное (как в этой статье) приходится делать сплошь и рядом. А всё потому, что весь базовый набор контролов в WPF — это огромный склад костылей. И далеко не всегда есть возможность модифицировать поведение стандартных контролов.
Я наверное чего-то не догоняю…
Что ж, десяти миллионов у меня не было, а PGM захотелось

Финальный прибор стоит 10 млн рублей

Скорее квантовый алгоритм с какой-то вероятностью вернёт правильный результат (в данном случае порядок функции).
Если результат будет неправильным, то просто надо провести вычисление повторно. В итоге рано или поздно нам повезет и мы получим правильный ответ :)

Information

Rating
Does not participate
Registered
Activity