Столкнулся с этой проблемой в Crossout.
Купил 1080б а оно тормозит. Процессор проставивает, GPU простаивает — а оно тормозит.
Решил проблему тем, что в настройках игры выставил принудительную частоту кадров 60, а в драйвере включил FastSync.
Сразу стало плавно и никаких рассинхронизаций.
Движок не дурак — если не успевает рендерить 60fps, то сам «пропускает кадры».
А кто ж теперь поймет?
Единственное, что можно сказать точно — вырос, потому что стали больше покупать их акции.
В частности потому, что andreyverbin купил их акции, т.к. решил, что они вырастут на OpenSource ;)
Про яркость — там же не зря написан черный и белый текст. Если бы фон был одинаковый по яркости, то текст читался бы одинаково.
Про красный — яркость это не белизна. Яркость — это как бы количество испускаемых фотонов в единицу времени. Например если взять красный светодиод и повышать его яркость — он никогда не начнет светить белым или розовым, как на картинке.
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->∞
Основной профит оптана — на порядок более низкие задержки при чтении.
В основном это даёт существенный выигрыш на операциях с мелкими блоками в 1 поток.
При куче потоков или линейных операциях разницы конечно не заметить.
По моим представлениям — это типичная нагрузка в играх, при подгрузке ресурсов.
Другой вопрос — будет ли заметный эффект, т.к. современный SSD + RAM Cache итак неплохо справляются.
Не зря оптан позиционирют в первую очередь для корпоративного сегмента — различные бигдаты просто тащутся от оптана.
Почему в графе «Память» для всех накопителей указано «128Gb 20nm Intel 3D XPoint»?
Это же не значит, что во всех оптанах стоит один и тот же 128 гиговый чип, программно ограниченный?
Много делаю UI в WPF и могу сказать, что подобное (как в этой статье) приходится делать сплошь и рядом. А всё потому, что весь базовый набор контролов в WPF — это огромный склад костылей. И далеко не всегда есть возможность модифицировать поведение стандартных контролов.
Скорее квантовый алгоритм с какой-то вероятностью вернёт правильный результат (в данном случае порядок функции).
Если результат будет неправильным, то просто надо провести вычисление повторно. В итоге рано или поздно нам повезет и мы получим правильный ответ :)
Купил 1080б а оно тормозит. Процессор проставивает, GPU простаивает — а оно тормозит.
Решил проблему тем, что в настройках игры выставил принудительную частоту кадров 60, а в драйвере включил FastSync.
Сразу стало плавно и никаких рассинхронизаций.
Движок не дурак — если не успевает рендерить 60fps, то сам «пропускает кадры».
Единственное, что можно сказать точно — вырос, потому что стали больше покупать их акции.
В частности потому, что andreyverbin купил их акции, т.к. решил, что они вырастут на OpenSource ;)
ответ был для nsklizard
Про красный — яркость это не белизна. Яркость — это как бы количество испускаемых фотонов в единицу времени. Например если взять красный светодиод и повышать его яркость — он никогда не начнет светить белым или розовым, как на картинке.
Если вычислительная сложность задачи между yield'ами высокая, то влияние самого yield'а будет ничтожным.
И есть даже возможность компиляции нативных бинарников (например CoreRT).
Mono разве что в Unitiy, и то со временем думаю перейдут на Core.
Убрал преобразование строки в массив байт.
Unsafe версию не выкладываю — она работает примерно так же. Видимо из-за необходимости пинить указатель, или ещё какие-то накладные расходы вылазят.
пс. кстати у вас в описании теста указан размер строки 20000, а в бенчах везде 15000. Это так задумано?
В моём случае оригинальная версия работает 0,84с, версия с a.Length работает 0,68с, а unsafe версия работает 0.63с.
Я и не думал об этом, хотя всегда использую именно a.Length, но не для скорости, а чтоб не накосячить.
Кроме того C# используют безопасное обращение к массиву.
Худший случай в данном случае и есть «бесконечное много бросков», т.к. вероятность попасть за N бросков стремится к 1, при N->∞
Сейчас Gbit или Gibit, в российском ГОСТе Гбит.
В основном это даёт существенный выигрыш на операциях с мелкими блоками в 1 поток.
При куче потоков или линейных операциях разницы конечно не заметить.
По моим представлениям — это типичная нагрузка в играх, при подгрузке ресурсов.
Другой вопрос — будет ли заметный эффект, т.к. современный SSD + RAM Cache итак неплохо справляются.
Не зря оптан позиционирют в первую очередь для корпоративного сегмента — различные бигдаты просто тащутся от оптана.
Это же не значит, что во всех оптанах стоит один и тот же 128 гиговый чип, программно ограниченный?
Если результат будет неправильным, то просто надо провести вычисление повторно. В итоге рано или поздно нам повезет и мы получим правильный ответ :)