User talk:Petelomax: Difference between revisions
→Use of Factorization Wheels in Sieves
GordonBGood (talk | contribs) (→Use of Factorization Wheels in Sieves: reply, recommend Web Assembly output...) |
|||
Line 56:
::: There are in fact some attempts to use shifts for divide/multiply, if that can be determined at compile-time, will see if I can do more. I totally agree there are some performance issues in bit-fiddling (just like subscripts), and the language would no doubt benefit from a new set of builtins that do such things much faster on blocks of pre-allocated memory, then again my personal definition of "performance" is kinda much more biased towards a fast edit/run cycle. Translation to JavaScript is in fact pretty much number 1 on my wish list for the lanugage, btw. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 15:33, 17 December 2018 (UTC)
:::: I seems that builtins are function calls and are not inlined. Thus, although adding `set_bit`, `clear_bit`, `test_bit` `shl_bits`, `shr_bits`, and `shrzf_bits` would make "bit-twiddling" easier to do, it would still take two function calls per cull to implement bit-packed culling, which would be about 120 machine cycles and too slow. You need to be able to specify simple builtins as "inline" to be fast enough. Even having the compiler recognize when multiply/divide factors are powers of two (actually quite easy, as then `and_bits(x, x-1) == 0` after passing the not zero checks when literal constants), the bitwise operations using function calls are too slow unless inlined.
::::: Agreed. Many/most builtins are indeed just lazily implemented as hll code, whereas some I try to inline, like and_bits(), remainder(), compare(), length(), etc. Oh yeah, there's another crafty trick I missed.
:::: As an aside, `without type_check` doesn't seem to work or I don't understand what it is supposed to do, it still detects `integer i = 1/2 as an error without the check; also, how to you turn off integer overflow checking? I can't seem to enter `-#3FFFFFFF - 1` as an integer, or rather it is accepted as an integer but prints as a float and not exact at that as I understood to be possible from the documentation, and, due to integer overflow checking subtracting another one from it triggers the type check error. Flaky... And overflow checks (as well as type checks) take machine cycles.
::::: Ah, `without type_check` only disables user-defined type routines, not internal checking - will clarify that in the manual. I wasn't able to reproduce any issue with -#3FFFFFFF - 1. I'm a fail-fast guy at heart, so I don't really understand/agree with the word Flaky, and there is no option, or plan for one, to make your program harder to maintain just so it can go a little faster (sorry).
:::: I can understand that compilation speed is a concern and in fact is already slow on my low end machine - about 30 seconds for a `-c` pass of a basic test program, where my machine is over twice as slow as yours given the speed to run the extensible generator as a benchmark. But some improvements such as making designated builtin functions inline and (possibly) adding the slightly more sophisticated power of two multiply/divide shouldn't take much time.
:::: "performance issues on subscripting" I suppose means indexing of sequences? Not inlined? bounds checking is slow? Bounds checking can't be optionally turned off?
::::: Inlined and disabled when known to be in bounds, but no option to forcibly turn it off.
:::: As to generating JavaScript output, if it were me at the stage I understand you to be, I wouldn't bother with JavaScript and would skip directly to Web Assembly output as you don't much require anything that Web Assembly doesn't already deliver since you already use reference counting memory allocation, including multi-threading (or at least coming very soon, and already available on Chrome). Performance is not particularly fast (no faster than JavaScript for many cases) and somewhat inconsistent performance across browsers (although, so too is JavaScript), but that will surely get fixed by the time you have completed this.
::::: I ran away screaming (sounds familiar, tee hee) from Web Assembly last time, maybe I'll give it another look.
:::: In short, Phix seems to me to be too much of a "work in progress" and as it currently exists not worth my while in pursuing further adaptation of my algorithms to it. However, as before, good luck to you, and I may look at it again if some of these issues are fixed.--[[User:GordonBGood|GordonBGood]] ([[User talk:GordonBGood|talk]]) 05:18, 18 December 2018 (UTC)
::::: No worries. There never was and probably never will be a programming language with no downsides, some we can live with, some we cannot. Many thanks for the input, will try to bear it all in mind as I move onward. --[[User:Petelomax|Pete Lomax]] ([[User talk:Petelomax|talk]]) 00:53, 20 December 2018 (UTC)
| |||