Stefan Behnel wrote: > Meaning, we'd find a new type during type analysis > or inference, split off a new version of the function and then analyse > it. I'm not sure that this degree of smartness would really be a good idea. I'd worry that if I made a type error somewhere, the compiler would go off and spend a few hours generating umpteen zillion versions of the code instead of stopping and telling me something was wrong. -- -- Greg
On 30 April 2011 09:51, Dag Sverre Seljebotn <d.s.seljebotn <at> astro.uio.no> wrote: > On 04/30/2011 08:39 AM, Robert Bradshaw wrote: >> >> On Fri, Apr 29, 2011 at 3:53 AM, mark florisson >> <markflorisson88 <at> gmail.com> wrote: >>> >>> On 29 April 2011 12:28, Pauli Virtanen<pav <at> iki.fi> wrote: >>>> >>>> No, just that real_t is specialized to float whenever struct_t is >>>> specialized >>>> to A and to double when B. Or a more realistic example, >>>> >>>> ctypedef cython.fused_type(float, double) real_t >>>> ctypedef cython.fused_type(float complex, double complex) >>>> complex_t >>>> >>>> cdef real_plus_one(complex_t a): >>>> real_t b = a.real >>>> return b + 1 >>>> >>>> which I suppose would not be a very unusual thing in numerical codes. >>>> This would also allow writing the case you had earlier as >>>> >>>> cdef cython.fused_type(string_t, int, paired=struct_t) attr_t >>>> >>>> cdef func(struct_t mystruct, int i): >>>> cdef attr_t var >>>> >>>> if typeof(mystruct) is typeof(int): >>>> var = mystruct.attrib + i(Continue reading)
Den 01.05.2011 02:24, skrev Greg Ewing: > Stefan Behnel wrote: >> Meaning, we'd find a new type during type analysis or inference, >> split off a new version of the function and then analyse it. > > I'm not sure that this degree of smartness would really > be a good idea. I'd worry that if I made a type error > somewhere, the compiler would go off and spend a few > hours generating umpteen zillion versions of the code > instead of stopping and telling me something was wrong. > I think so too. Cython has a square-bracket syntax for C++ templates. Why not defer the whole problem to the C++ compiler? Just emit the proper C++. Sturla
Sturla Molden, 01.05.2011 15:29: > Den 01.05.2011 02:24, skrev Greg Ewing: >> Stefan Behnel wrote: >>> Meaning, we'd find a new type during type analysis or inference, split >>> off a new version of the function and then analyse it. >> >> I'm not sure that this degree of smartness would really >> be a good idea. I'd worry that if I made a type error >> somewhere, the compiler would go off and spend a few >> hours generating umpteen zillion versions of the code >> instead of stopping and telling me something was wrong. > > I think so too. > > Cython has a square-bracket syntax for C++ templates. Why not defer the > whole problem to the C++ compiler? Just emit the proper C++. Not everyone uses C++. And the C++ compiler cannot adapt the code to specific Python object types. Stefan
Den 01.05.2011 16:36, skrev Stefan Behnel: > > Not everyone uses C++. And the C++ compiler cannot adapt the code to > specific Python object types. Ok, that makes sence. Second question: Why not stay with the current square-bracket syntax? Does Cython need a fused-type in addition? I'd also think duck types could be specialised from run-time information? (Cf. profile-guided optimisation.) Sturla
Sturla Molden, 01.05.2011 18:25: > I'd also think duck types could be specialised from run-time information? > (Cf. profile-guided optimisation.) Interesting. That could even be much simpler than WPA. Basically, the profiler would dump the argument types it sees, and then generate a .pxd file with fused types. Stefan
Robert Bradshaw, 30.04.2011 08:16: > On Fri, Apr 29, 2011 at 8:04 AM, mark florisson >> With the type matching it matches on exactly 'if src_type is >> dst_type:' so you can't use 'and' and such... perhaps I should turn >> these expression into a node with the constant value first and then >> see if the result of the entire expression is known at compile time? > > Yes, that's exactly what I was thinking you should do. For now, you could simply (try to) re-run the ConstantFolding transform after the type splitting. It will evaluate constant expressions and also drop unreachable branches from conditionals. Stefan
On 05/01/2011 06:25 PM, Sturla Molden wrote: > Den 01.05.2011 16:36, skrev Stefan Behnel: >> >> Not everyone uses C++. And the C++ compiler cannot adapt the code to >> specific Python object types. > > Ok, that makes sence. > > Second question: Why not stay with the current square-bracket syntax? > Does Cython > need a fused-type in addition? There is no current feature for templates in Cython currently, only interfacing with C++ templates, which is rather different. I.e., your question is very vague. You're welcome to draft your own proposal for full-blown templates in Cython, if that is what you mean. When we came up with this idea, we felt that bringing the full power of C++ templates (including pattern matching etc.) into Cython would be a bit too much; I think Cython devs are above average sceptical to C++ and the mixed blessings of templates. E.g., one reason for not wanting to do it the C++ way is the need to stick largs parts of your program in header files. With fused types, the valid instantiations are determined up front. DS
On 2 May 2011 11:08, Stefan Behnel <stefan_ml@...> wrote: > Robert Bradshaw, 30.04.2011 08:16: >> >> On Fri, Apr 29, 2011 at 8:04 AM, mark florisson >>> >>> With the type matching it matches on exactly 'if src_type is >>> dst_type:' so you can't use 'and' and such... perhaps I should turn >>> these expression into a node with the constant value first and then >>> see if the result of the entire expression is known at compile time? >> >> Yes, that's exactly what I was thinking you should do. > > For now, you could simply (try to) re-run the ConstantFolding transform > after the type splitting. It will evaluate constant expressions and also > drop unreachable branches from conditionals. Right thanks! I actually ran it on the condition only, as I overlooked its branch pruning capability (sometimes I see 'if (1)' generated code, so that's probably because that happens after ConstantFolding). So wouldn't it be a good idea to just insert another ConstantFolding transform at the end of the pipeline also, and have it recalculate constants in case it was previously determined not_a_constant? > Stefan > _______________________________________________ > cython-devel mailing list > cython-devel@... > http://mail.python.org/mailman/listinfo/cython-devel >(Continue reading)
mark florisson, 02.05.2011 11:22: > On 2 May 2011 11:08, Stefan Behnel wrote: >> Robert Bradshaw, 30.04.2011 08:16: >>> >>> On Fri, Apr 29, 2011 at 8:04 AM, mark florisson >>>> >>>> With the type matching it matches on exactly 'if src_type is >>>> dst_type:' so you can't use 'and' and such... perhaps I should turn >>>> these expression into a node with the constant value first and then >>>> see if the result of the entire expression is known at compile time? >>> >>> Yes, that's exactly what I was thinking you should do. >> >> For now, you could simply (try to) re-run the ConstantFolding transform >> after the type splitting. It will evaluate constant expressions and also >> drop unreachable branches from conditionals. > > Right thanks! I actually ran it on the condition only, as I overlooked > its branch pruning capability (sometimes I see 'if (1)' generated > code, so that's probably because that happens after ConstantFolding). ... or because something generates that explicitly (e.g. to simplify some specific code generation), but I couldn't find this with a quick grep right now. I once put a C for-loop into straight sequential argument unpacking code, so that I could "break" out of it at any point, rather than using gotos and labels for that. But that was only half-way hackish because that particular code mimics an unrolled loop anyway. In the future, Vitja's dead code removal branch will handle branch pruning anyway. I just put it into the ConstantFolding transform at the time as it(Continue reading)
RSS Feed37 | |
|---|---|
129 | |
87 | |
75 | |
31 | |
30 | |
33 | |
45 | |
56 | |
154 | |
128 | |
124 | |
279 | |
235 | |
158 | |
146 | |
125 | |
20 | |
43 | |
196 | |
116 | |
184 | |
245 | |
72 | |
220 | |
294 | |
217 | |
105 | |
200 | |
237 | |
377 | |
62 | |
124 | |
232 | |
288 | |
88 | |
135 | |
230 | |
222 | |
181 | |
111 | |
253 | |
245 | |
607 | |
360 | |
219 | |
206 | |
357 | |
639 | |
527 | |
678 | |
406 | |
181 | |
274 | |
291 | |
418 | |
256 | |
320 | |
215 | |
284 | |
705 | |
398 | |
223 | |
65 | |
133 | |
137 | |
82 | |
49 | |
151 | |
32 |
