User talk:Petelomax: Difference between revisions
→Use of Factorization Wheels in Sieves: reply, recommend Web Assembly output...
GordonBGood (talk | contribs) (→Use of Factorization Wheels in Sieves: reply, recommend Web Assembly output...) |
|||
Line 55:
::: 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.
:::: 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.
:::: 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?
:::: 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.
:::: 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)
| |||