Add Pythran support to build, convert two functions

[serge-sans-paille]

Description

Use Pythran instead of cython to compile several kernels, while keeping
somewhat high level and pythonic code.

Checklist

[It's fine to submit PRs which are a work in progress! But before they are merged, all PRs should provide:]

• Clean style in the spirit of PEP8
• Docstrings for all functions
• Gallery example in ./doc/examples (new features only)
• Benchmark in ./benchmarks, if your changes aren't covered by an
  existing benchmark
• Unit tests

[For detailed information on these and other aspects see scikit-image contribution guidelines]

References

#2956

For reviewers

(Don't remove the checklist below.)

• Check that the PR title is short, concise, and will make sense 1 year
  later.
• Check that new functions are imported in corresponding __init__.py.
• Check that new features, API changes, and deprecations are mentioned in
  doc/release/release_dev.rst.
• Consider backporting the PR with @meeseeksdev backport to v0.14.x

[serge-sans-paille]

@jni / @stefanv : short status update. I updated kernel code to be pep8 compilant (wasn't the case for original cython code). Due to a mvsc update, some kernels no longer compile under windows but that's fixed in pythran master version.

Until then, I'd like some guidance on integration of pythran kernel into asv-powered benchmarks!

[serge-sans-paille]

For the record: I just opened serge-sans-paille/pythran#955 to make sure all scikit-image kernels are and remain correctly compiled by pythran. I'll feed the kernels with default values to make sure the behavior is unchanged, this is probably related to the bencmakrs task (I need guidance for valid / reasonable input)

[serge-sans-paille]

For the record, serge-sans-paille/pythran#955 now validates ok on windows.

[serge-sans-paille]

@jni / @stefanv : all scikit-image kernels have been added to the pythran validation suite and compile OK on linux and windows! It's all in master branch, so next step on my side would be to make a Pythran release compatible with scikit-image, but I'd like to be sure there is no other blocker before.

[jni]

@serge-sans-paille so cool! On this end we would need benchmarks to all the bits that we're touching. Now on master we have a benchmark framework using airspeed velocity.

But I don't want to push this work on you — this is something we will get to eventually.

On the logistics of actually getting this merged, we tend to be quite conservative, so there's a good chance that what we actually need to do is to use Cython's Pure Python mode to have these things compilable with either Pythran or Cython. (Or alternatively keep the existing Cython around and use some kind of setup.py flag to determine compilation with one lib or the other.) This is a major project but one that I'm excited to see completed. It would also open the door to using Numba optionally.

[serge-sans-paille]

Or alternatively keep the existing Cython around and use some kind of setup.py flag to determine compilation with one lib or the other.

That looks better than Pure Python mode, performance wise. I can handle that task.

[serge-sans-paille]

@jni just pushed a tentative cython fallback, but as stated in the commit message, I'm not sure that's the way we should take. But a Python fallback would be extreemly slow too...

[jni]

@serge-sans-paille it's a very clean extension, thank you!

I absolutely sympathise with not wanting to maintain two separate code bases, believe me. =) But the reality is that we are quite risk averse at scikit-image, with good reason. So switching all-out to Pythran, which is a much younger project than Cython with a smaller community, is probably not feasible in the short term. But a hybrid approach might be feasible, and might be a good way for the core team to get practice working with Pythran, get confident in using it, and eventually decide to take the leap. The alternative is to leave this PR open for a long time, which is its own maintenance burden.

There's again another possibility, which is to wait until we go 3.6+, and then we can use this for Cython:

https://github.com/AlanCristhian/statically

I also presume something like this would be possible with Pythran, too? Actually a decorator is much more Pythonic than a comment.

@stefanv @soupault @emmanuelle do you guys have any input here? To summarise:

• Pythran offers similar performance to Cython while retaining pure Python syntax (using type inference for any internal code)
• It compiles to C++, so it doesn't have the distribution problems that Numba has
• @serge-sans-paille has made heroic efforts and converted I think all (?) of our Cython codebase to Pythran
• what now?

[serge-sans-paille]

with good reason. So switching all-out to Pythran, which is a much younger project than Cython with a smaller community, is probably not feasible in the short term. But a hybrid approach might be feasible, and might be a good way for the core team to get practice working with Pythran,

OK, this totally makes sense. If I understand correctly, I won't need to play with the benchmarks, so my part of the job is almost done :-)

Concerning the hybrid path, It's probably better to give an option to the user to control which back-end to use, a flag to setup.py is feasible, or maybe an environment variable (easier to setup :-))?

I'll probably do a pythran release in august, that would include all the patches required for the scikit-image integration.

[serge-sans-paille]

@jni up! Any step missing on my side?

[jni]

@serge-sans-paille very cool. =) What do you think about the idea of implementing Pythran as a decorator instead of a comment + external command?

[serge-sans-paille]

@jni. I'm not a big fan of this idea, because pythran is an ahead of time compiler: compile speed has never been a real focus, and it's not rare to have a compile step that takes 5 to 10 seconds. Even if cached, this is not acceptable for a decorator.

Moreover, Pythran only handles full modules. Being able to extract the relevant subpart of the module is an interesting subject and we may want to support that at some point, but it's definitly not possible now.

[jni]

@serge-sans-paille very good points!

How about the middle ground: use Python 3.5+ type annotations, if available, instead of comments. But build still happens ahead of time.

[serge-sans-paille]

@jni. Yeah, that's in the plan, once Python2.7 support is dropped.

[serge-sans-paille]

Is that a blocking feature for that PR?

[jni]

Not quite blocking, just some extra friction. The major friction of course is the multiple parallel implementations.

[serge-sans-paille]

hi @jni. Just updated the integration step, with an optional env variable to disable pythran to lower the friction.

[serge-sans-paille]

(rebased on master)

[hmaarrfk]

I don't understand what is up with github. It seems that this is redoing a few typo PRs that were done this last week.

[hmaarrfk]

I'm not sure conda is running Visual Studio 2017. Can you confirm that we would be able to ship this package with conda?

[hmaarrfk]

This doesn't really belong in this PR and seems to have been done in #3478 whats up with github?

[hmaarrfk]

Haven't these been merged already? Whats up with github? #3480

[serge-sans-paille]

I messed up my rebase. Not a github thing ^^!

[hmaarrfk]

nevermind, this is a different thing.

[hmaarrfk]

So I am listening to your talk from 2013 (I guess that is what I found on Youtube) and it seems pretty awesome!!!

1. I don't think PyPi or conda (defaults or conda-forge) compiles with AVX instructions just yet, these are probably the two most popular ways to distribute scikit-image. Any thoughts on how that might affect the benchmarks?

The ability to use AVX instructions from native python is awesome!

2. I know some memory alignment is sometimes necessary to use AVX, does this impose a different minimum numpy version to take advantage of this.

[serge-sans-paille]

@jni I've been able to reproduce the issue locally, and it seems to be codna specific. At least using virtualenv as asv backend works locally. To my great shame, I cannot find how to update the label, if you could retrigger it?

[grlee77]

To my great shame, I cannot find how to update the label, if you could retrigger it?

you just use the labels menu to the right and remove the "run-benchmark" label and then add it again to restart. I went ahead and did it just now, but something is odd because it completed almost instantly without doing anything: https://github.com/scikit-image/scikit-image/actions/runs/1454438133.

+ asv continuous --split --show-stderr --factor 1.5 487a3668f9d83686c5081d609c5f8fdc279fa2aa ff397dfa4f7df1438d16f36d1d72b1958048c850
ram [7118772]: Baseline:  487a3668f9d83686c5081d609c5f8fdc279fa2aa (scikit-image:main)
Contender: ff397dfa4f7df1438d16f36d1d72b1958048c850 (serge-sans-paille:feature/test-pythran-support)
+ tee benchmarks.log
+ sed '/Traceback \|failed$\|PERFORMANCE DECREASED/ s/^/::error::/'
· No executable found for python 3.7
+ grep 'Traceback \|failed\|PERFORMANCE DECREASED' benchmarks.log
· No environments selected

it looks like after the commit switching from conda->virtualenv it was unable to find Python

[grlee77]

I pushed a couple of commits that installs Python 3.7 and virtualenv in the benchmarks workflow. It is now running at: https://github.com/scikit-image/scikit-image/runs/4194731156?check_suite_focus=true

[serge-sans-paille]

@grlee77 ok, seems I don't have the rights to change the labels, thanks for doing it. Do you know if there's any advantage in using mamba/conda env vs. virtualenv as asv backend? Access to more binary packages like compilers etc?

[grlee77]

ok, seems I don't have the rights to change the labels

Did you get an invite to join the triage team? (I think @jni said he added you to it). I would have thought accepting that would have given you permission to add/remove labels.

Do you know if there's any advantage in using mamba/conda env vs. virtualenv as asv backend? Access to more binary packages like compilers etc?

I don't think it should matter too much in our case. The dependencies we need should be available from pypi as well, so virtualenv is fine with me.

[serge-sans-paille]

@grlee77 indeed, the invite went right to my spam folders :'(. I can now update labels.

All lights are green, do you want me to rebase and cleanup the history?

[jni]

@serge-sans-paille no need! The changes are actually compact enough that I think squashing is appropriate. Congrats! It's only taken three years to get this in!!! 😂 🎉 🚀

Now that I am less worried about all of our infrastructure, I am looking more slowly at the actual implementation details and damn it's awesome. 😃 Thank you @serge-sans-paille!

[serge-sans-paille]

\o/ I won't submit more kernel until next skimage release, so that we have some feedbacks about how wheels are built etc.

[grlee77]

@serge-sans-paille
We have been updating our wheel building scripts in #6021 to prepare for a new release. After merging in this Pythran support I am seeing a new Windows failure related to unresolved symbols: https://github.com/grlee77/scikit-image/runs/4230656524?check_suite_focus=true#step:6:1399

If you have an idea of what might be the cause, please let us know!

The failure was on a win32 wheels case (causing the other Windows builds to be aborted). I may split off the 64-bit builds to a separate entry to see if things work okay there.

       Creating library build\temp.win32-3.7\Release\skimage/feature\brief_cy.cp37-win32.lib and object build\temp.win32-3.7\Release\skimage/feature\brief_cy.cp37-win32.exp
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyImport_ImportModule
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyObject_GetAttrString
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyCapsule_Type
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyExc_RuntimeError
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyErr_SetString
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyExc_AttributeError
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyCapsule_GetPointer
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyErr_Format
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyErr_Print
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyExc_ImportError
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyModule_Create2
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_Py_BuildValue
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyModule_AddObject
    brief_pythran.obj : error LNK2001: unresolved external symbol __security_cookie
    brief_pythran.obj : error LNK2001: unresolved external symbol __security_check_cookie
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyArg_ParseTupleAndKeywords
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp__Py_NoneStruct
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyErr_Clear
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyType_IsSubtype
    brief_pythran.obj : error LNK2001: unresolved external symbol __CxxFrameHandler3
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyExc_ValueError
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyExc_MemoryError
    brief_pythran.obj : error LNK2001: unresolved external symbol memcpy
    brief_pythran.obj : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned __int64)" (??2@YAPEAX_K@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "struct std::nothrow_t const std::nothrow" (?nothrow@std@@3Unothrow_t@1@B)
    brief_pythran.obj : error LNK2001: unresolved external symbol "void * __cdecl operator new(unsigned __int64,struct std::nothrow_t const &)" (??2@YAPEAX_KAEBUnothrow_t@std@@@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "void __cdecl operator delete(void *,unsigned __int64)" (??3@YAXPEAX_K@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::~basic_streambuf<char,struct std::char_traits<char> >(void)" (__imp_??1?$basic_streambuf@DU?$char_traits@D@std@@@std@@UEAA@XZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: virtual __cdecl std::ios_base::~ios_base(void)" (__imp_??1ios_base@std@@UEAA@XZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp__invalid_parameter_noinfo_noreturn
    brief_pythran.obj : error LNK2001: unresolved external symbol "void __cdecl operator delete(void *)" (??3@YAXPEAX@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol __std_terminate
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyDict_Size
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyDict_Next
    brief_pythran.obj : error LNK2001: unresolved external symbol memmove
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyExc_TypeError
    brief_pythran.obj : error LNK2001: unresolved external symbol memchr
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyEval_SaveThread
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyEval_RestoreThread
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_free
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __cdecl std::ios_base::ios_base(void)" (__imp_??0ios_base@std@@IEAA@XZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: void __cdecl std::basic_ios<char,struct std::char_traits<char> >::init(class std::basic_streambuf<char,struct std::char_traits<char> > *,bool)" (__imp_?init@?$basic_ios@DU?$char_traits@D@std@@@std@@IEAAXPEAV?$basic_streambuf@DU?$char_traits@D@std@@@2@_N@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) protected: __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::basic_streambuf<char,struct std::char_traits<char> >(void)" (__imp_??0?$basic_streambuf@DU?$char_traits@D@std@@@std@@IEAA@XZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: int __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::sputc(char)" (__imp_?sputc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@QEAAHD@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __cdecl std::basic_ios<char,struct std::char_traits<char> >::clear(int,bool)" (__imp_?clear@?$basic_ios@DU?$char_traits@D@std@@@std@@QEAAXH_N@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "bool __cdecl std::uncaught_exception(void)" (?uncaught_exception@std@@YA_NXZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: void __cdecl std::basic_ostream<char,struct std::char_traits<char> >::_Osfx(void)" (__imp_?_Osfx@?$basic_ostream@DU?$char_traits@D@std@@@std@@QEAAXXZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol strlen
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PySet_Type
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyObject_GetIter
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyIter_Next
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyObject_Not
    brief_pythran.obj : error LNK2001: unresolved external symbol __imp_PyCapsule_GetName
    brief_pythran.obj : error LNK2001: unresolved external symbol __std_exception_destroy
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: bool __cdecl std::ios_base::good(void)const " (__imp_?good@ios_base@std@@QEBA_NXZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl std::basic_ostream<char,struct std::char_traits<char> >::flush(void)" (__imp_?flush@?$basic_ostream@DU?$char_traits@D@std@@@std@@QEAAAEAV12@XZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "void __cdecl std::_Xlength_error(char const *)" (?_Xlength_error@std@@YAXPEBD@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "const type_info::`vftable'" (??_7type_info@@6B@)
    brief_pythran.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::_Lock(void)" (?_Lock@?$basic_streambuf@DU?$char_traits@D@std@@@std@@UEAAXXZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "public: virtual void __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::_Unlock(void)" (?_Unlock@?$basic_streambuf@DU?$char_traits@D@std@@@std@@UEAAXXZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "protected: virtual __int64 __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::showmanyc(void)" (?showmanyc@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAA_JXZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "protected: virtual int __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::uflow(void)" (?uflow@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAAHXZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "protected: virtual __int64 __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::xsgetn(char *,__int64)" (?xsgetn@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAA_JPEAD_J@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "protected: virtual __int64 __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::xsputn(char const *,__int64)" (?xsputn@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAA_JPEBD_J@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "protected: virtual class std::basic_streambuf<char,struct std::char_traits<char> > * __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::setbuf(char *,__int64)" (?setbuf@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAAPEAV12@PEAD_J@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol "protected: virtual int __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::sync(void)" (?sync@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAAHXZ)
    brief_pythran.obj : error LNK2001: unresolved external symbol "protected: virtual void __cdecl std::basic_streambuf<char,struct std::char_traits<char> >::imbue(class std::locale const &)" (?imbue@?$basic_streambuf@DU?$char_traits@D@std@@@std@@MEAAXAEBVlocale@2@@Z)
    brief_pythran.obj : error LNK2001: unresolved external symbol _fltused
    LINK : error LNK2001: unresolved external symbol _DllMainCRTStartup
    build\lib.win32-3.7\skimage\feature\brief_cy.cp37-win32.pyd : fatal error LNK1120: 69 unresolved externals
    Partial import of skimage during the build process.
    error: Command "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:C:\cibw\python\pythonx86.3.7.9\tools\libs /LIBPATH:C:\cibw\python\pythonx86.3.7.9\tools\PCbuild\win32 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\ATLMFC\lib\x86 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Tools\MSVC\14.29.30133\lib\x86 /LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x86 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.22000.0\ucrt\x86 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.22000.0\um\x86 /EXPORT:PyInit_brief_cy build\temp.win32-3.7\Release\skimage/feature/brief_pythran.obj /OUT:build\lib.win32-3.7\skimage\feature\brief_cy.cp37-win32.pyd /IMPLIB:build\temp.win32-3.7\Release\skimage/feature\brief_cy.cp37-win32.lib" failed with exit status 1120
    Building wheel for scikit-image (PEP 517): finished with status 'error'
    ERROR: Failed building wheel for scikit-image
  ERROR: Failed to build one or more wheels
  Failed to build scikit-image
  Exception information:
  Traceback (most recent call last):
    File "C:\cibw\python\pythonx86.3.7.9\tools\lib\site-packages\pip\_internal\cli\base_command.py", line 173, in _main
      status = self.run(options, args)
    File "C:\cibw\python\pythonx86.3.7.9\tools\lib\site-packages\pip\_internal\cli\req_command.py", line 203, in wrapper
      return func(self, options, args)
    File "C:\cibw\python\pythonx86.3.7.9\tools\lib\site-packages\pip\_internal\commands\wheel.py", line 173, in run
      "Failed to build one or more wheels"
  pip._internal.exceptions.CommandError: Failed to build one or more wheels
  Removed build tracker: 'C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\pip-req-tracker-qbd3p826'
Error: Command ['python', '-m', 'pip', 'wheel', 'D:\\a\\scikit-image\\scikit-image', '--wheel-dir=C:\\Users\\RUNNER~1\\AppData\\Local\\Temp\\cibuildwheelna3k2hgh\\built_wheel', '--no-deps', '-vv'] failed with code 1. None

<\details>

[rgommers]

Just a guess: clang-cl is not installed in the wheel build actions, so the build uses MSVC and that doesn't work. See how clang-cl is installed in this PR.

[grlee77]

Just a guess: clang-cl is not installed in the wheel build actions, so the build uses MSVC and that doesn't work. See how clang-cl is installed in this PR.

Thanks, I will try this! In the meantime, I did confirm that AMD64 cases work okay and it is just x86 that is failing

[grlee77]

The changes in commit a0e0f7a fixed the x86 windows builds. I had to add --force to the line installing LLVM with choco because otherwise it did nothing because it said LLVM was already present.

For consistency I also force installed LLVM in the AMD64 case, but this was not strictly necessary (CI was already passing without the explicit LLVM install steps for AMD64). Let me know if this doesn't seem like the right choice. The force install doesn't take long, but does result in a >200MB download.