On 12 May 2016 at 18:32, Brian Gladman <b...@gladman.plus.com> wrote:

> On 12/05/2016 17:03, 'Bill Hart' via mpir-devel wrote:
> > For anyone that would like to help with porting to Windows, here are the
> > notes so far:
> >
> > * The asm jit we use mentions MSVC support on its website, though it
> > only explicitly mentions MSVC 2003. I don't see any VS solution files,
> > so I don't know how the build is managed (they use CMake).
>
> Hi Bill,
>
> If it is this one, it seems to have support via Cmake for VS 2015.
>
>   https://github.com/kobalicek/asmjit
>
>
That's the one.


> > * Bear in mind that supporting anything other than the assembly formats
> > currently supported is a massive task. Alex has spent months adapting it
> > to work with our assembly code, though it does read quite a bit of our
> > yasm code and a lot of gas format assembly. It currently outputs gas
> > format. It can output Intel syntax (we are not sure what variety), but
> > that part contains some bugs (incorrect output).
> >
> > * The superoptimiser itself is written in C++11, and Alex says he
> > doesn't use many longs in his code.
> >
> > * Currently there is code that is Linux specific for fixing the CPU
> > affinity. That would need porting.
>
> I do this regularly so it should not be an issue.
>
> > * Until today we were having a lot of problems on Intel CPUs on any OS.
> > AMD is more stable though still not perfect.
> >
> > * We have not tested again on a fully loaded system. We are trying that
> > now, after the most recent changes. We previously had problems on loaded
> > systems.
> >
> > * As mentioned, we do not believe timings will be consistent enough on
> > Windows to be able to superoptimise, but people are welcome to try and
> > figure out how to make it work there. At the least it is going to
> > require someone with a lot of Windows experience to solve that, if it is
> > actually possible.
>
> Well, I am finding things better than they used to be so it may be worth
> trying it.
>

Probably if you get a brand new Windows machine and turn off system backup,
virus scanning, all resident programs, make sure it is up-to-date with
patches and disconnect it from the internet, etc., etc., you might get it
to quiet down enough to give it a go. I remember Jason Moxham spent days
trying to get a Windows machine to quieten down enough. I don't think he
was ever successful.

I am very doubtful it will work. Bear in mind it is not a case of whether
it will give a speedup or not, it is whether you can superoptimise at all.
You need cycle accurate timing, which so far has eluded us on all but the
most quiet Linux boxes.

It doesn't help that Intel and AMD changed the way their cycle counter
works so that gamers would stop complaining. It now doesn't measure cycles,
but constantly scales the times. All the Intel timings we are getting have
a resolution of 3 cycles now too on the machine we have access to, and
that's before any effects due to machine load.

If you do get it going, you have to superoptimise an asm file, take the
output and superoptimise it again. If the superoptimiser is working it
should return the same output and same cycle timings. If not, the timings
on the machine are not stable enough.

It's a very, very difficult problem, though we have it working on Linux
boxes with zero load now, to within about 3 cycles (at least it does output
the same code if you try to optimise the output on those machines).

We are still working on the problem of getting it to work on heavily loaded.


> > * The total amount of code asm jit + optimiser is about 32,000 lines of
> > code, but currently the code is in a state of flux, day-to-day
>
> > * Alex does not have experience developing on Windows and does not have
> > access to a Windows machine and he is on contract to the OpenDreamKit
> > project, so he is not available to assist in the development of a
> > Windows port, other than to answer occasional questions by email.
> >
> > * Alex is currently happy to give people access to the repository on
> > request (if you have a GitHub account), but please understand that the
> > project is not in a stable state just yet.
>
> I'll reflect on whether I have time to do this and get back to you guys.
>
> But I'm inclined to give it a shot.
>

Alex, can you give Brian access to the repository?

BIll.


>
>    Brian
>
> --
> You received this message because you are subscribed to the Google Groups
> "mpir-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mpir-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to mpir-devel@googlegroups.com.
> Visit this group at https://groups.google.com/group/mpir-devel.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"mpir-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to mpir-devel+unsubscr...@googlegroups.com.
To post to this group, send email to mpir-devel@googlegroups.com.
Visit this group at https://groups.google.com/group/mpir-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to