libera/#sicl - IRC Chatlog
Search
3:46:10
hayley
@moon-child: Well, the video I was thinking of was about concurrency. And all the RAII weenies appeared in the comments, because they'd have destructors run immediately and sequentially.
3:53:29
hayley
To an extent I've wondered what could happen if we could use running out of external resources to pace concurrent GC, like we have with running out of memory.
3:55:07
moon-child
(and how many of those external resources are actually cleaned up with gc finalisers rather than, say, with with-macros?)
3:55:38
hayley
I run out of GPU memory often enough, as eazy-opencl insists GPU memory should be managed with finalisers, and I hardly cons on the CPU, so I rarely GC.
3:56:01
hayley
Reminds me that my backlog includes writing a manually-managed fork of eazy-opencl. Call it hard-opencl or something.
5:07:17
adlai|alphanum
mfiano: I'm sorry that social issues have pushed you away from CL... please consider that they might only be indicative of a group of people, rather than the language itself?
5:08:00
adlai|alphanum
CL does give you more power to work alone than most languages, so naturally, less collaborative folks end up disproportionately represented.
5:08:40
adlai|alphanum
meanwhile I have a question about the GC conversations - what is the distinction between 'parallel' and 'concurrent' ?
5:09:35
mfiano
I would rather not discuss the social issues, as I don't want to offend a group of people, but I will say that some of the social issues are integrated tightly into the language, such as for instance, the reliance on a central repository (Quicklisp) and the refusal of most authors to version their software, or the tools necessary to have developers themselves manage versioned dependencies.
5:09:35
adlai|alphanum
I'd treated these two words as pretty much synonymous, although it seems from rereading conversations here that there is a significant distinction that I've missed.
5:12:32
mfiano
No, in short, languages are tools, and no tool is good at everything, despite being general-purpose; their exists more specialized tools for a particular problem domain, and the problem domains I'm interested in have recently took a sharp turn.
5:12:48
adlai|alphanum
ACTION has also taken quite a hiatus from CL (and programming in general) in recent years, mainly due to having accumulated an unmanageable hairball of code from years when his personal goal was simply to have no day without git commits... without any metric for progress towards stability of the product.
5:13:14
adlai|alphanum
however, I still keep reading, and do plan on resuming work in CL once I have a better idea of how to aim my work.
5:14:34
beach
adlai|alphanum: I think "concurrent" means that it works while the mutator is running, and "parallel" means that more than one thread is doing the GC.
5:24:37
moon-child
adlai|alphanum: I agree with beach's definitions here. In a more general sense, I think 'concurrent' means 'at the same time', while 'parallel' means 'independent'. While the terminology is somewhat loose, you can see a tenuous connection here: a concurrent gc works concurrently with an application; works at the same time as it, but is not independent, and usually fine-grained communication between
5:24:39
moon-child
the two is required in order to maintain correctness. While parallel gc attempts to find aspects of the garbage collection process which are independent of one another (and then tries to profit by executing these in different concurrency domains)
5:36:10
mfiano
Concurrency is about competetition with external factors. Parallelism is about cooperation. This is how I like to think of it, as described by Steele.
5:38:05
mfiano
I can link to the talk that you have probably seen before, if you'd like. IIRC it is quite long.
5:38:47
moon-child
I know 'how (not) to talk about parallelism', but I don't remember his talking about concurrency there
5:39:55
moon-child
in any case, this is why I say the terminology is somewhat loose. In broad terms, I think everyone agrees concurrency is 'the dangerous one', though (though it is also interesting that joe calls it 'the one you actually want'--because one concurrency domain can fail while another survives)
5:41:28
moon-child
(which being said I also think of eg reentrancy issues as concurrency issues, which do not have those desirable attributes)
5:47:01
hayley
Joe also claimed that concurrency is a natural part of modelling, as many actions in the real world have concurrency.
8:55:44
beach
I looked into how functions such as the trigonometric ones are computed, which is something that prov worked (still works?) on.
8:55:54
beach
So, take SIN for instance. It appears the first quadrant is split into small intervals and for each interval, there is an appropriate polynomial approximation to evaluate.
8:56:01
beach
So then there are considerations such as how many intervals to use, and the degree of the polynomial approximation. These considerations lead to an interesting optimization problem.
8:56:09
beach
For one thing, it might be good to have a non-uniform interval size. For small values of the argument, the interval can likely be greater for some fixed degree of polynomial.
8:56:21
beach
Then comes the way that the right interval is determined. One could use a tree of comparisons much like we do for generic dispatch, but comparing floats is not fast. So perhaps translate the float into a fixed-point value between 0 and π/2 and do integer comparisons instead. So the number of such comparisons also influences the performance.
8:57:45
beach
I guess the desired precision is fixed to be the precision of the floating-point number. But I wonder if that full precision is possible to maintain when the final value is the result of several, more elementary, floating-point operations.
8:58:38
moon-child
'the desired precision is fixed to be the precision of the floating-point number. But I wonder if...' most math libraries provide some bounded error. Eg 1.5 ulp, 5ulp, whatever
8:59:46
beach
I see. So you are saying that some error is tolerated, as long as the library specifies an upper bound?
9:00:12
moon-child
there are also correctly rounded math libraries, but those tend to be appreciably more expensive. There was some recent work on making a high-performance one, but it is still more expensive than ones with a small error bound
9:00:44
moon-child
ieee 754 specifies that some operations--like basic arithmetic and sqrt--must be correctly rounded, but that others--in particular transcendentals--do not have to be
9:00:52
beach
I can imagine, yes. For the reason I mentioned. One would have to use higher precision to do the calculation and then round.
9:01:38
moon-child
from what I understand, it is frequently possible to obtain correctly rounded results without using higher precision, using fma to implement newton-raphson iteration or similar. But I may be wrong about that
9:02:00
moon-child
I think the most important thing is to provide consistent results across (hardware) platforms. This is not guaranteed, but I think it is a very valuable thing to provide
9:03:35
moon-child
reading more ... comparing floats is rather fast. But branches are not so nice in dense math code, especially if there is the potential for vectorisation (and I think it would be good to provide vectorisation, a la sleef)
9:04:18
beach
Float comparison must be like a subtraction, and I understand that takes a few cycles.
9:07:48
moon-child
an interesting result I stumbled upon recently is that lexicographic comparison is cheaper than subtraction. Not that it matters, at these bit widths. But anyway: you are half-right; I forgot that vector ops have higher latency than int ops (but generally as good or better throughput), and all float ops are vector ops. The difference is less pronounced on intel, but it is still a couple of cycles
9:09:33
beach
So you are saying, prefer fewer intervals to have fewer comparisons, and instead use higher-degree polynomials because they can be evaluated using vector instructions?
9:14:54
moon-child
my understanding was that, at least for sin, they only had a polynomial approximation over one interval, and then mirrored over the rest
9:15:40
moon-child
a quick skim of sleef appears to weakly confirm this, as it only has one exit point; it has a couple of branches, but they seem to do only preprocessing
9:20:19
moon-child
https://github.com/shibatch/sleef/blob/master/src/libm/sleefdp.c#L789 is sleef's sin
9:22:20
beach
I don't understand much of it. I would need to understand the general technique first.
9:23:12
beach
Anyway, it is time for a lunch break. Feel free to say more. I'll read up when I get back.
9:23:48
moon-child
I understand. I think there is a paper somewhere about sleef, but it does not go into details. glibc's math library might have more links; I think the gnu people are usually pretty good about citing their sources