Well I mean yeah there's a there's a BQN page about performance that

I think Rich is right that I should refer to that for for anybody who wants real information and for anyone who really wants real information you should just go to Bintre and see the graphs of how fast each primitive is that tries to explain you know what

performance you'll see. Bintre, wait a second what is Bintre? I know we haven't brought this up there's benchmarksgame.com or something which is the website that like compares all the different languages based on a few programs. Is this clear or not what is Bintre?

Is that a BQN thing? Yeah pretty much so Bintre is my effort to to benchmark stuff and BQN mostly so that we have guidance when we're developing it but I've also tried to present um there's a page that it links to where I try to present these benchmarks along with some information about you know what you can expect from the primitives so it shows you know like if you're sorting a two byte array here's how the performance here's what the the number of nanoseconds per element it takes on my particular CPU that I benchmarked on and it explains you know here's what we do and so here's why you see this little bump here or whatever and so that's if you really want to get into BQN performance seriously I mean of course you should always write your own benchmarks time your own program it's like you know the majority it's hard to say how much but a huge amount of the time you'll find that the thing that you thought was slow and try to optimize if you didn't benchmark in advance it's not actually the bottleneck and it doesn't matter at all and there's some other part of your program that you need to be uh focusing on so I mean the number one rule of performance is benchmark everything measure you know as much as you can um but if you want to learn like general rules about BQN performance you can look at this and see you know how the how fast the primitives perform and then have an idea of you know which primitive you want to use more and which you don't want to use as much unfortunately your two minutes is up and we uh we didn't answer the question at all I'm just gonna go ahead yeah so that's if you want you know to to stop being uh to get away from the drama and actually figure out how to make your program fast but for the drama um yes I do think BQN has some advantages in the even in the language design itself over APL&J there are also some design decisions in APL&J that I think are holding them back in performance somewhat um one in APL that's kind of interesting is actually that all the bits in a packed bit array regardless of the system you're on your they're stored a big indian which is the opposite of the way that um Intel processors and most um that you know x86 and ARM and other processors these days do it um at the time it was kind of a mix of both and they chose to go with big indian um but this means that some things have to be flipped around and it slows them down um one of the big things I see with J that uh that's really hurting performance is that um it doesn't optimize as much in terms of the types it uses to represent things so I said a big advantage of um APL is that you can sort things in bits or 1 byte integers or 2 byte integers um J pretty much just stores its integers as 64 bit integers which is very large um and of course the floats are 64 bit floats you can't really do much about that because um you can't you can't lose precision um so there's no smaller format that works but with the integers um that's a significant problem for the kind of code that I work with because you know I'd be seeing 1 and 2 byte integers like a lot of stuff like compiling bq in a lot of programs that I write are bq in related and so yeah for the problems I see you know bq in is going to get that eight times speed up from storing it in one byte or four times from storing it in two bytes um that's not necessarily always the case because um other people work with floats a lot and then for them J is great because they get you know a double precision at the speed that the CPU can do it um and I think this is a lot of this uh must be a lot of J's user base because they're very um I know they're very concerned with optimizing their floating point performance like their matrix multiplies are better than any other array language I believe they've done a lot of work on that um good stuff uh and things like that so actually for for some scientific applications J is probably really good um so it depends on what you measure a bit um but also I think bq in has some has some good stuff that it does and we have worked a lot on our algorithms of course so I was not terribly surprised to see your your measurement that apl or that bq in is faster than apl and J here because like I've also used bench array um there's a mode you can use that I don't publish because I don't want to keep track of you know what changes are in apl and J right now but I can compare against uh J and apl timings and for the stuff that we measure on bench array bq in is is quite often a lot faster um twice as

fast as dialogue and you know a few times faster than J it depends on the type of lot.