Я бы наклеил.

Вот сегодня пойду пробовать эти 4 штуки напечатать и нарезать х) По результатам отпишу.

И фото!

Смотрите, потихоньку документации на фичи F#4.1 пишут. https://docs.microsoft.com/en-us/dotnet/fsharp/language-reference/fixed

Логотип красивый, готов проспонсировать некоторую партию в пару сотен штук

Вот сегодня пойду пробовать эти 4 штуки напечатать и нарезать х) По результатам отпишу.

А где такие делают? :)

По идее любая профессиональная типографская мастерская, у которой есть плоттер, принтер и самоклейка. Правда с поштучной печатью там довольно туго, сегодня будем пробовать договориться

По мотивам обсуждения <>null / isNull написал бенч: https://gist.github.com/ForNeVeR/492dad2bf2c0cda22e79422ab9c35c6a

По мотивам обсуждения <>null / isNull написал бенч: https://gist.github.com/ForNeVeR/492dad2bf2c0cda22e79422ab9c35c6a

и результаты?)

Результаты там же, по ссылке.

Результаты там же, по ссылке.

о, спасибо!

Почему notNull такой слоу?

И что будет если сделать not (isNull o)? Или код одинаковый получится?

И что будет если сделать not (isNull o)? Или код одинаковый получится?

А ты проверь. :)

https://sharplab.io/#v2:DYLgZgzgNAJiDUAfALgTwA4FMAEAhTAdgMYAWAtgIYBOA1gBQCU2AvALABQ2X2wmy2AexaCARgCtGHbtjKYyIzFWwB9ZQDoAlhAByAV2DBGLKdO5a9BwRxNdZ8xSvVEBZdNUxG2nU1yHNsBPrA1t62cgpKqmoEAsgWhkxePlx0MfwAPOnY5kFMAiHSdhGOarrELm5UHok2pkLpAHwBQUA===

@fvnever Результаты мне кажутся странными.

Почему uncompare быстрее compare? %)

Ладно. Суть не в этом. :)

О, а так ещё прикольней и контраст и белое есть вокруг

Почему uncompare быстрее compare? %)

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

@fvnever Я смотрю JIT ASM.

О, даже так можно? %)

Почему uncompare быстрее compare? %)

Возможно, на моей машине JIT по-другому отработал.

Да, это возможно.

Либо CPU здесь очень хитро угадал результаты после выполнения not

Видишь, compare напрямую возвращает результат какой-то функции, которая возвращает данные в eax. А uncompare к этому результату применяет not-преобразование (последние три инструкции перед return).

А ты проверь. :)

notNull | 24.908 ns | 0.4687 ns | 0.4385 ns | notNull2 | 1.525 ns | 0.0662 ns | 0.0619 ns |

Второй это not (is Null o)

@Dolfik А первый?

(not << isNull) o

@Dolfik Ты что-то делаешь не так.

Что я не так делаю?)

@Dolfik Просто (not << isNull) o и not (is Null o) компилируются в один и тот же код.

@Dolfik Просто (not << isNull) o и not (is Null o) компилируются в один и тот же код.

Нет

public bool notNull() { object obj = this.o; return obj == null ? 1 : 0 == 0; } public bool notNull2() { return this.o == null ? 1 : 0 == 0; }

Нахера, я не знаю)

public bool notNull() { object obj = this.o; return obj == null ? 1 : 0 == 0; } public bool notNull2() { return this.o == null ? 1 : 0 == 0; }

Это IL?

@Worldbeater Это C#.

Это IL?

Это C# ~_~

@Dolfik https://sharplab.io/#v2:DYLgZgzgPg9gDgUwHYAIDKBPCAXBBbAWAChjgFsUkZsA5AV2GBRhQF5LqUAKASwnsbMAlKXIdaDYGmAwA7szbcqFADwqUfAcCHNioijABGAK0VIE8gPImEAY2xcRRMhQBOCCGepbmJ/SncIaTkvCUZg+SNjYiA==

https://sharplab.io/#v2:DYLgZgzgNAJiDUAfALgTwA4FMAEAhTAdgMYAWAtgIYBOA1gBQCU2AvALABQ2X2wmy2AexaCARgCtGHbtjKYyIzFWwB9ZQDoAlhAByAV2DBGLKdO5a9BwRxNdZ8xSvVEBZdNUxG2nU1yHNsBPrA1t62cgpKqmoEAsgWhkxePlx0MfwAPOnY5kFMAjamBXYRjtGx8QBMngXSadh0OZYCDCHSxQ5RusQublQeiTXcQukAfAFBQA

Я так

@Worldbeater, лол, ты верно подметил. Видимо, это артефакт декомпиляции. Такое в C# не компилируется.

@Worldbeater, лол, ты верно подметил. Видимо, это артефакт декомпиляции. Такое в C# не компилируется.

Не-не

Не компилируется!

Там порядок действий другой

@Dolfik @fvnever И JIT разный. .__.

Что за ерунда в этих методах творится?

Слева булево значение получается.

Так что 1 это инт.

Что за ерунда в этих методах творится?

Чего с чем ты сравниваешь?

Так что 1 это инт.

Да нет же, я проверил — не компилируется такое. Ты сразу всё правильно сказал.

(not « isNull) o и not (is Null o)

@Dolfik Какие-то странности и оптимизации в методах.

(not « isNull) o и not (is Null o)

Почему один из них "slow"? Одинаково должны работать

@fvnever Посмотри выше, пожалуйста. Там @Dolfik какой-то бенчмарк запилил странный.

notNull | 24.908 ns | 0.4687 ns | 0.4385 ns | notNull2 | 1.525 ns | 0.0662 ns | 0.0619 ns |

Покажи весь код своего бенча.

type Benchmark() = let o = obj() [<Benchmark>] member __.isNull() = isNull o [<Benchmark>] member __.compare() = o = null [<Benchmark>] member __.notNull() = (not << isNull) o [<Benchmark>] member __.notNull2() = not (isNull o) [<Benchmark>] member __.uncompare() = o <> null

Я уже встречал такие эффекты, и у меня есть для них правдоподобное объяснение, но я хочу видеть весь кот

Да нет же, я проверил — не компилируется такое. Ты сразу всё правильно сказал.

Если поставить скобки в нужном месте, то норм будет. Мб в этой штуке порядок действий иной

type Benchmark() = let o = obj() [<Benchmark>] member __.isNull() = isNull o [<Benchmark>] member __.compare() = o = null [<Benchmark>] member __.notNull() = (not << isNull) o [<Benchmark>] member __.notNull2() = not (isNull o) [<Benchmark>] member __.uncompare() = o <> null

А ты в релизе тестируешь?

Нет :)

Никогда не запускай бенчмарки в дебаге, это бессмысленно. BDN даже ругается на такое :)

Если поставить скобки в нужном месте, то норм будет. Мб в этой штуке порядок действий иной

Нет, никак не будет. В C# числовые литералы не кастуются неявно к bool. Этот код такой странный потому, что декомпилятор не ожидал такое увидеть вообще.

Ну то это точно ошибка декомпилятора.

Я пойду репортить.

Method | Mean | Error | StdDev | --------- |----------:|----------:|----------:| notNull | 0.6647 ns | 0.0419 ns | 0.0411 ns | notNull2 | 0.6138 ns | 0.0454 ns | 0.0425 ns |

Ура!

Я тут занят немного, и забыл в релиз переключить ?

Как всегда, овердохрена работы, и нужно всё срочно сделать

Нет, никак не будет. В C# числовые литералы не кастуются неявно к bool. Этот код такой странный потому, что декомпилятор не ожидал такое увидеть вообще.

bool a = (obj == null ? 1 : 0) == 0; ну Фридрих, ну ты что

bool a = (obj == null ? 1 : 0) == 0; ну Фридрих, ну ты что

В оригинале нет скобок!

вполне ж

ну да

Декомпилятор генерирует невалидный код, это баг.

+

Зарепортил: https://github.com/ashmind/SharpLab/issues/119

Моя гипотеза такова: декомпилятор, само собой, затачивался на декомпиляцию C# или VB.NET-кода, и может быть настроен именно на такие паттерны, которые используются компиляторами этих языков. Например, C# использует CIL-инструкцию cgt.un для сравнения с null, а F# использует (более логичный, на мой взгляд) ceq.

Декомпилятор его не понимает и думает, что мы пытаемся вернуть число.

@fvnever А там разве не ilspy внутре?

@fvnever А там разве не ilspy внутре?

Я не знаю.

Низкоуровневые чудеса.

@fvnever А там разве не ilspy внутре?

Думаешь, придётся репортить в ilspy и чинить там? :)

Как знать.

https://github.com/ashmind/SharpLab/tree/master/source/%23libraries > ICSharpCode.Decompiler.dll Вроде да, это ilspy.

Кстати, господа.

Наc уже 150. \o/

Выпьем же! =)

оффтопом: Никто завтра на devops митап не идет случайно на целый день?

мск

Выпьем же! =)

Соберемся только

Есть кто с Минска ещё ? =)

Как знать.

Ага, автор просил перепостить в ILSpy: https://github.com/icsharpcode/ILSpy/issues/811

Есть кто с Минска ещё ? =)

Хочешь организовать встречу?

@VagifAbilov вы использовали akkling?

Pavel угу