Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Mar 07 17:29
    @directhex banned @CharlieIsHere
  • Oct 11 2018 17:23
    @directhex banned @deleteaccount1234567890
Phil Jaenke
@rootwyrm
I'm going to create a issue for the TZ stuff so it's a bit more clear, I think.
Phil Jaenke
@rootwyrm
Opened mono/mono#16415 for the timezone stuff.
Phil Jaenke
@rootwyrm
@NattyNarwhal I'm gonna break all your stuff 'kay? ;)
Calvin Buckley
@NattyNarwhal
oh no
Phil Jaenke
@rootwyrm
Actually, I kinda hope it won't break anything since 7.1 + uses IANA but it's in a weird location.
Calvin Buckley
@NattyNarwhal
the CI box runs 6.1
it has IANA from BOS though
Phil Jaenke
@rootwyrm
Oh yeah... I keep forgetting about that because I keep actively suppressing my memories of 6.1.
D.S. Qiu
@srxqds
how can I debug using vs with embeded mono, is three any detail introduction?
who can give some advice or some details?
Mikkel Kruse Johnsen
@mikkeljohnsen
@rootwyrm I just compiled the nightly with the patch: #16298 but it has no effect on Process.Start.
This is really a problem that Mono is broken and I'm forced to go back to Mono 4.8, to get it to work.....
Phil Jaenke
@rootwyrm
@akoeplinger there's a lot of pretty ugly hard-coding in TimeZoneInfoTest.cs ... I think this just turned into a 'really fix the test.'
Alexander Köplinger
@akoeplinger
hmm I thought it's just a few cases of deprecated identifiers?
Phil Jaenke
@rootwyrm
On the surface, yes. The problem is there's a lot of hard-coded time zones further down the list.
Alexander Köplinger
@akoeplinger
can you give an example?
Phil Jaenke
@rootwyrm
Yep, was just grabbing a good one. :)
There's a couple just like this...
            public void BrusselsSupportsDST ()
            {
                TimeZoneInfo brussels = TimeZoneInfo.FindSystemTimeZoneById (MapTimeZoneId ("Europe/Brussels"));
                Assert.IsTrue (brussels.SupportsDaylightSavingTime);
            }
So if the Olson database deprecates it in the future, the tests will break again. Because time zones are hell.
Alexander Köplinger
@akoeplinger
sure, but we can fix it once that happens
let's just fix what is broken right now
Phil Jaenke
@rootwyrm
Sounds like a plan.. I do see a sensible way to fix it 'right' but given my lack of C# experience, probably inadvisable in the short term.
Filip Navara
@filipnavara
@EgorBo btw, there is BDN PR for fixing the in-process iterations which were crashing some of the benchmarks. It will likely take few days to propagate it all the way through git, Nugets, etc. before it gets picked up by dotnet/performance..
Egor Bogatov
@EgorBo
great news anyway :smile:
I currently use the default (non inprocess) mode with --llvm jit
Filip Navara
@filipnavara
I gave up on that, it was too slow (but somehow it looks like it improved now)
Egor Bogatov
@EgorBo
the latest results are quite promising
Zoltan Varga
@vargaz
so do we have any benchmark results comparing master to like 2 weeks ago ?
Egor Bogatov
@EgorBo
I'll run some old revision after the current iteration with the same parameters (Release, MONO_THREADS_SUSPEND=preemptive mode, etc)
Filip Navara
@filipnavara
I do have logs on my pipelines but I only tried the
LLVM builds recently so nothing for comparison except regular Mono
(still didn't get to produce nice charts :/)
Filip Navara
@filipnavara
I can run the pipelines on historical Mono builds though, if needed
Zoltan Varga
@vargaz
just want to know whenever the stuff we are doing made any real difference.
Egor Bogatov
@EgorBo
we need jit diff tools :smile: you change something (e.g. add a new pass) then run some projects with mono --llvm --compile-all -v -v -v -v (before and after the change) and get a diff (how many and which methods were modified). The CoreCLR folks use such tools for all jit related PRs
Filip Navara
@filipnavara
anecdotal evidence says that the recent optimizations helped (based on aggreagate numbers from the pipeline runs) but I didn't wire up ResultsComparer yet to see how big the difference is and where it helped.
It is very high on my todo list to produce that.
Egor Bogatov
@EgorBo
Also I guess it's important to measure time LLVM JIT spends
that's why I didn't just copy the -O2 set of opt for LLVM JIT
coypoop
@coypoop
Is it expected that Mono requires WX memory mappings, or is that a platform specific issue?
Alexander Köplinger
@akoeplinger
it's needed for the JIT
coypoop
@coypoop
thanks!
Alexander Köplinger
@akoeplinger
there's an issue that I'm just about to file when you compile with XCode 11 beta6 on macOS Catalina though
Filip Navara
@filipnavara
The back of the napkin math shows that last Mono+LLVM failed only after 7 minutes while the previous run failed after 50 minutes. I wonder whether the benchmark order is somehow randomized but I don't think so.
Egor Bogatov
@EgorBo
@vargaz I think Vector128<T>.Count and Vector256<T>.Count can also be made intrinsics (despite the fact we don't support them yet)
Vector128<T>.Count = 128 / (sizeof(T) * :sunglasses:
Zoltan Varga
@vargaz
code which uses it is inside an if (SSe.Supported) so it gets dead-code eliminated.
Callum
@CallumDev
Latest mono on arch (6.0) is throwing /usr/lib/mono/msbuild/15.0/bin/Microsoft.CSharp.CurrentVersion.targets(331,5): error MSB4019: The imported project "/usr/lib/mono/msbuild/15.0/bin/Roslyn/Microsoft.CSharp.Core.targets" was not found. on all projects
since Microsoft.CSharp.Core.targets is not there