Limitation of std::variant

The Partridge Family were neither partridges nor a family. Discuss.
Post Reply
albinopapa
Posts: 3758
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Limitation of std::variant

Post by albinopapa » April 14th, 2019, 5:59 pm

Yeah, I'm still messing with std::variant for some reason, but I did find a possible limitation albeit probably implementation defined.

While messing around I wanted to add some templates to a variant list, but in order for this to work afaik, you can only add instantiated objects to the variant list. In other words, you couldn't just add std::vector to the list, you'd have to add std::vector<int>. So the templates that I wanted to add had a non-type parameter, an integer instead of a type like int or float. This should be fine because my templates have a set number of possible instantiations, 256 to be exact. While that is a lot to add to the list: std::variant< temp<0>, temp<1>, ..., temp<255> >; I was able to use some copy/paste and multi-line edits to make short work of it.

Well, no issues in the declaration, my variant now had over 300 items in the list. The problem came when I tried to use std::visit. It kept saying there was no overload for the visitor and variant combination I was using. I thought this was strange, so I made a smaller test of 80 items, didn't work. I decided to take away items until it did work, and it started working once I only had 64 items in the variant list.

I'm wondering it this is a VS limitation or a standards limitation. Also, would the limitation be due to recursive depth limitations, which I think the standards only gives a minimum recursive depth limitation. Of course now that I say that, I can't find the table I've come across in the past.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

albinopapa
Posts: 3758
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Limitation of std::variant

Post by albinopapa » April 15th, 2019, 4:12 am

It appears there might be something else going on as I look through the <variant> header, it seems it should be possible to have more than even 256 possible parameters.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

BobsCrabShack
Posts: 5
Joined: April 19th, 2019, 7:52 pm

Re: Limitation of std::variant

Post by BobsCrabShack » April 19th, 2019, 8:02 pm

From what I understand std::visit works by creating a function pointer table at compile time to all the possible functions (with the correct parameter type). Then calls variant::get and uses the correct function call. Can't possibly think as to why there would be a limit. If you ran out of heap space (compile time) or stack space (runtime) I could possibly see. But since it compiles dont think that would be the case. It is probably something in the VS implementation. Im curious does it work using /std17 or /stdlatest? Also, you could try changing the compiler to something other than msbuild.

albinopapa
Posts: 3758
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Limitation of std::variant

Post by albinopapa » April 20th, 2019, 10:12 am

Perhaps I should have dug a little deeper. I mindlessly assumed that intellisense saying there were no overloads for std::visit ( unless I had only 64 or less elements in the variant list ), that it wouldn't compile either. I just created a test of 100 elements in the list and intellisense gives me the error: No instance of function template (std::visit) matches the argument list. I forget sometimes that intellisense is basically an interpreter and probably does have limits on recursive depth. Long story short, the test case does compile and works as expected.

Now, I just need to wrap my head around ASTs. I was thinking of using std::variant to create a SIMD shader language. Not interpreted per se, but a compiled list of SIMD and stack operations similar to HLSL or GLSL.

The compiler seems to really well at optimizing the crap out of all the extra function calls when in release mode. There's probably 10-15 extra x86-64 instructions between the SIMD calls, which I'm kind of hoping can be run in parallel or at the very least pipelined so there isn't much in the way of a stall between SIMD instructions.

I've made a go at this before using enums and a switch/case block and it was about 20 times slower than native SSE. I think it's slowly sinking in, maybe another couple of weeks and I'll get something to compile lol. My previous attempt with the enums and switch/case used a different approach in that I would run through an array per operation, so if there was an add, I'd do all the adds first, then move on to the next operation. I think that was probably the biggest limiting factor, but I could be wrong.

Btw, std::variant doesn't have a .get() function, but instead they overloaded std::get<> to work with std::variant. The msft implementation uses a constexpr array for storage of those function pointers and indexes through by recursively wittling away at the index of the type in the list ( if the type you are requesting to visit is the 100th element in the list, it uses a constexpr function with a switch/case block, if the index is > than 64, it divides the number by two and increments an offset then calls the function again until it finds the index in the 0-63 range then adds the offset ).

I messed around a while back and was able to grab the index of a type from the list by using some recursion that didn't require the switch/case, but perhaps using the switch/case block helps with compile times.
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

BobsCrabShack
Posts: 5
Joined: April 19th, 2019, 7:52 pm

Re: Limitation of std::variant

Post by BobsCrabShack » April 20th, 2019, 5:57 pm

Yes, you are right of course about std::get (its been months since ive fooled around with it and seems ive forgotten :lol: ).

I had similar issues with intelisense crapping its pants with large type_lists 6 or so months back.

I understand the basics of a syntax tree but probably cant put it into practice lol. Might be able to help you after I write a compiler within the next year or so :lol:

Am curious to see if anything comes out of it.

albinopapa
Posts: 3758
Joined: February 28th, 2013, 3:23 am
Location: Oklahoma, United States

Re: Limitation of std::variant

Post by albinopapa » April 21st, 2019, 4:30 am

Am curious to see if anything comes out of it.
#Metoo
If you think paging some data from disk into RAM is slow, try paging it into a simian cerebrum over a pair of optical nerves. - gameprogrammingpatterns.com

Post Reply