Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

It is slow in Microsoft #7

Closed
AlbertoCasasOrtiz opened this issue Oct 16, 2020 · 3 comments
Closed

It is slow in Microsoft #7

AlbertoCasasOrtiz opened this issue Oct 16, 2020 · 3 comments
Assignees
Labels
bug Something isn't working

Comments

@AlbertoCasasOrtiz
Copy link
Member

It could be because of the used compiler: Visual Studio 2019.

@AlbertoCasasOrtiz AlbertoCasasOrtiz added the bug Something isn't working label Oct 16, 2020
@AlbertoCasasOrtiz AlbertoCasasOrtiz self-assigned this Oct 16, 2020
@AlbertoCasasOrtiz AlbertoCasasOrtiz removed their assignment Oct 16, 2020
@AlbertoCasasOrtiz AlbertoCasasOrtiz added this to the Release Version milestone Oct 21, 2020
@AlbertoCasasOrtiz AlbertoCasasOrtiz self-assigned this Jan 4, 2021
@AlbertoCasasOrtiz
Copy link
Member Author

News: Previously I though that the problem was the use of Eigen, whose inline functions can cause incompatibilities with msvc compiler. After checking the code again, looks like Eigen is not the problem.

Measuring times in the code I've found that most of the time is spent in the function AppendChunk (When creating the sparse matrix). Looks like the problem is the Microsoft implementation of malloc and realloc.

Link 1: Explanation of why realloc function could be slower in microsoft that in Linux/Mac.
Link 2: Microsoft developer explaining why malloc can be slower in microsoft.
Link 3: Another explanation in stackoverflow, more detailed.

@AlbertoCasasOrtiz
Copy link
Member Author

After searching for alternatives, looks like the problem is the compiler implementation of those functions. We have to wait till another compiler is supported like MinGW.

Refer to issue #60.

@jasondk
Copy link
Member

jasondk commented Jan 4, 2021

This doesn't sound like a satisfactory explanation to me. I'll take a look at AppendChunk(), but it seems to me we could pre-allocate larger chunks of memory to use and release the unused portion at the end (or re-allocate additional memory, if needed, a small number of times by allocating with a large chunk size). I assume the only reason we are iteratively allocating memory is because the sparsity pattern is unknown until we compute the matrix. I suspect an algorithmic improvement here could be useful...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants