Building on windows

[Nuxar1]

Building on windows is a real pain...

I got it working in the end using cmake, however i needed to add this code in order to replace <sys/time.h> and include it instead

#include < time.h >
#include <windows.h>
#include <sysinfoapi.h>

#if defined(_MSC_VER) || defined(_MSC_EXTENSIONS)
#define DELTA_EPOCH_IN_MICROSECS  11644473600000000Ui64
#else
#define DELTA_EPOCH_IN_MICROSECS  11644473600000000ULL
#endif

struct timezone
{
    int  tz_minuteswest; /* minutes W of Greenwich */
    int  tz_dsttime;     /* type of dst correction */
};

inline int gettimeofday(timeval* tv, struct timezone* tz)
{
    FILETIME ft;
    unsigned __int64 tmpres = 0;
    static int tzflag;

    if (NULL != tv)
    {
        GetSystemTimeAsFileTime(&ft);

        tmpres |= ft.dwHighDateTime;
        tmpres <<= 32;
        tmpres |= ft.dwLowDateTime;

        /*converting file time to unix epoch*/
        tmpres /= 10;  /*convert into microseconds*/
        tmpres -= DELTA_EPOCH_IN_MICROSECS;
        tv->tv_sec = (long)(tmpres / 1000000UL);
        tv->tv_usec = (long)(tmpres % 1000000UL);
    }

    if (NULL != tz)
    {
        if (!tzflag)
        {
            _tzset();
            tzflag++;
        }
        tz->tz_minuteswest = _timezone / 60;
        tz->tz_dsttime = _daylight;
    }

    return 0;
}

Additionally, i had to remove the library m.lib from the linker settings of finufft. For some reason it's in there twice (for Debug configuration).

[Nuxar1]

Additionally the install step doesn't work. The lib files aren't moved to the target directory even though they were built.

[ahbarnett]

Dear Nuxar1, Sorry about that. We are transitioning to cmake, and don't have many windows users, so your efforts will help there. Are you non-MINGW ? Please see: https://github.com/flatironinstitute/finufft/pull/251

I hope Libin and Marco can now tweak CMakeLists.txt to include some of what you did. Best, Alex

On Wed, Mar 8, 2023 at 10:31 AM Nuxar1 @.***> wrote:

Additionally the install step doesn't work. The lib files aren't moved to the target directory even though they were built.

— Reply to this email directly, view it on GitHub https://github.com/flatironinstitute/finufft/issues/252#issuecomment-1460338022, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNZRSUQBBIQZ6FUA4GK643W3CQ3ZANCNFSM6AAAAAAVT4XKKQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

-- *-------------------------------------------------------------------~^`^~._.~' |\ Alex Barnett Center for Computational Mathematics, Flatiron Institute | \ http://users.flatironinstitute.org/~ahb 646-876-5942

[Nuxar1]

I used the default cmake configuration for visual studio 2022

[lu1and10]

I used the default cmake configuration for visual studio 2022

I think in @DiamonDinoia 's PR 251, the timing interface should be resolved with std::chrono or with your solution, while to build tests on visual studio may still need tweaks.

[DiamonDinoia]

Depending on how crucial is to control the timing exactly there are two solutions.

1. std::chrono is usually good enough, the only issue is that the clock resolution is not part of the standard and different platform might have different resolutions. Although, steady_clock is guaranteed monotonic so is good enough in most cases. https://stackoverflow.com/questions/43276695/stdchronosystem-clock-vs-stdchronohigh-resolution-clock-behavior
2. gettimeofday also suffers from many issues as it is not monotonic: https://stackoverflow.com/questions/88/is-gettimeofday-guaranteed-to-be-of-microsecond-resolution
3. Use performance counters on windows, basically you need to change the code above to use QueryPerformanceCounter: https://learn.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter complete instructions here: https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
4. On linux the most accurate is clock_gettime CLOCK_MONOTONIC: https://stackoverflow.com/questions/12643535/whats-the-best-timing-resolution-can-i-get-on-linux

I believe that chrono steady_clock is the best solution in this case. fftw uses solution 3&4 but they do some benchmarks during init to find the fastest algorithm on the platform so it makes sense for them.

[ahbarnett]

Thanks Marco & Libin, For FINUFFT timings usually around 1ms accuracy is enough. Most problems are large or are looped, so that they take 1 sec or more. So I propose we test Marco's PR #251 on linux & mac, then bring in. Best, Alex

On Fri, Mar 10, 2023 at 4:23 AM Marco Barbone @.***> wrote:

Depending on how crucial is to control the timing exactly there are two solutions. `

1. ``std::chrono``` is usually good enough, the only issue is that the clock resolution is not part of the standard and different platform might have different resolutions. Although, steady_clock is guaranteed monotonic so is good enough in most cases. https://stackoverflow.com/questions/43276695/stdchronosystem-clock-vs-stdchronohigh-resolution-clock-behavior
2. gettimeofday also suffers from many issues as it is not monotonic: https://stackoverflow.com/questions/88/is-gettimeofday-guaranteed-to-be-of-microsecond-resolution
3. Use performance counters on windows, basically you need to change the code above to use QueryPerformanceCounter: https://learn.microsoft.com/en-us/windows/win32/api/profileapi/nf-profileapi-queryperformancecounter complete instructions here: https://learn.microsoft.com/en-us/windows/win32/sysinfo/acquiring-high-resolution-time-stamps
4. On linux the most accurate is clock_gettime CLOCK_MONOTONIC: https://stackoverflow.com/questions/12643535/whats-the-best-timing-resolution-can-i-get-on-linux

I believe that chrono steady_clock is the best solution in this case. fftw uses solution 3&4 but they do some benchmarks during init to find the fastest algorithm on the platform so it makes sense for them.

— Reply to this email directly, view it on GitHub https://github.com/flatironinstitute/finufft/issues/252#issuecomment-1463512053, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACNZRSXPSX37YGUWM6UVHJTW3LXHVANCNFSM6AAAAAAVT4XKKQ . You are receiving this because you commented.Message ID: @.***>

-- *-------------------------------------------------------------------~^`^~._.~' |\ Alex Barnett Center for Computational Mathematics, Flatiron Institute | \ http://users.flatironinstitute.org/~ahb 646-876-5942

[ahbarnett]

I brought in PR #251, so let us know if any problems for you now. Best, Alex