Menu
▾
▴
pure-lang-users — Discussion of the Pure programming language.
You can subscribe to this list here.
| 2008 |
Jan
|
Feb
|
Mar
|
Apr
(31) |
May
(422) |
Jun
(241) |
Jul
(268) |
Aug
(281) |
Sep
(109) |
Oct
(1) |
Nov
|
Dec
|
|---|
|
From: Albert G. <Dr....@t-...> - 2008-07-07 22:10:50
|
Hi Rooslan, welcome to the list! Rooslan S. Khayrov wrote: > Here is a patch (created by mostly mechanical substitution) to compile > Pure with LLVM trunk. I guess it should work with 2.3 as well. It passes > all tests on my Linux x86 box. Thanks a bunch, that's heaven-sent! :) Will try it immediately. > I've never tried Pure with 2.2, so can't > really compare these performance wise. Compiling any of supplied library > modules or sources in examples/ folder takes less than 1 sec on a not so > modern hardware (single core AMD 3200+). Did you run these with -i? Otherwise the interpreter is not really compiling anything (it's all done lazily). To actually force the Pure interpreter to generate the IR for a module when you run it in batch mode and you're not actually computing anything, you can use a command like the following: pure -i set.pure </dev/null This will force it to think it's in interactive mode, in which case it compiles all pending definitions before it enters the read-eval-print loop. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-07-07 21:51:52
|
Jiri Spitz wrote: > Would it be possible to add a random number function to the math module? Yes sure. > There are many different variants in the C library and I don't know > which one to choose. Hmm, many algorithms in C libraries are crappier than what you'd come up with in a minute. How about the Mersenne twister? It's not crytographically secure, but otherwise it's very good. I still have an implementation of that in the Q codebase, shouldn't take longer than five minutes to add it to the library. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-07-07 21:41:26
|
Albert Graef wrote: >>> In return I promise to investigate why the dict and set modules take >>> so long to compile. :) >> It would be nice, it is really slow. > > Ok, I did some profiling now, and it seems that the lion's share (over > 70%) of the time is spent within LLVM, only a small fraction (not > exceeding 15%) goes to the parser and all my own semantic routines. I think I pinned that one down now. Noticing that only set.pure and dict.pure are affected, but not the other container data structures whose code is in principle quite similar, I took a closer look at the generated pattern matching code of these modules. Lo and behold, there are in fact some functions in those two modules which have a lot of overlapping rules producing automata with some 260-300 states. So I removed some the special case rules in those definitions, and that alone made the modules load thrice as fast. Mind you, 260-300 states isn't big at all, my construction algorithm can easily deal with much bigger automata, but of course the automaton then also yields a routine in LLVM IR which includes a decision tree (nested switch statements) with a total of 260-300 target labels. My guess is that the LLVM IR builder gets really slow when dealing with "big" assembler routines like this (maybe some badly coded algorithms with quadratic complexity in there, I haven't looked at the code). So now I have to get Pure to compile with LLVM 2.3 to see whether they fixed those horrible inefficiencies with the new builder class. If not then as an intermediate measure some refactoring of those overlapping rules in dict.pure and set.pure will help. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Rooslan S. K. <kh...@gm...> - 2008-07-07 21:37:46
|
Albert Graef wrote: > I guess I'll have to try LLVM 2.3 and see whether it's any faster. > There's still hope since they do have a new IR Builder class in 2.3... Here is a patch (created by mostly mechanical substitution) to compile Pure with LLVM trunk. I guess it should work with 2.3 as well. It passes all tests on my Linux x86 box. I've never tried Pure with 2.2, so can't really compare these performance wise. Compiling any of supplied library modules or sources in examples/ folder takes less than 1 sec on a not so modern hardware (single core AMD 3200+). -- Best regards, Rooslan |
|
From: Eddie R. <er...@bm...> - 2008-07-07 21:20:28
|
> > // mod of a double > > x::double mod y::int = (x - intx) + (intx mod y) when intx = (int x) end; > > If memory serves me, Common Lisp has this, but not any Algol-like > language I know. I can add it to math.pure if there's enough demand. I've had to deal with this once in Pascal somewhere before but I cant recall. In that occasion I found that mod(double, double) may be defined in two ways in order to stay consistent with something else ... Dang I can't find it on google. I don't know if you should add "double mod double" to the list or not but I sure would hate to have to look it up again. If memory servers me (probably doesn't) C's definition of fmod really should be called frem instead because there is a difference between real mod and real remainder. I guess I better shut up now before I stick my foot in my mouth. e.r. |
|
From: Jiri S. <jir...@bl...> - 2008-07-07 21:02:36
|
Hi Albert, Would it be possible to add a random number function to the math module? There are many different variants in the C library and I don't know which one to choose. Jiri |
|
From: Albert G. <Dr....@t-...> - 2008-07-07 20:42:41
|
Hi Jiri, >> In return I promise to investigate why the dict and set modules take >> so long to compile. :) > > It would be nice, it is really slow. Ok, I did some profiling now, and it seems that the lion's share (over 70%) of the time is spent within LLVM, only a small fraction (not exceeding 15%) goes to the parser and all my own semantic routines. There goes my theory that it might be related to my own environment code... (Actually I would have preferred that, if it's my own code then I can fix it. But I checked specifically those routines and they don't even make a blip on the radar.) I still have to analyze the profiles more thoroughly, there might be some hidden inefficiencies in my semantic routines which make it spend a lot of time in STL routines (which make up for the remaining 15%). But in any case it looks like LLVM is to blame, which is a major bummer. :( I would have suspected that it's the optimization passes, but disabling these doesn't speed it up much either, so it seems that most of those 70% of the compilation time the darn thing just generates LLVM IR. I guess I'll have to try LLVM 2.3 and see whether it's any faster. There's still hope since they do have a new IR Builder class in 2.3... Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-07-07 17:48:27
|
Libor Spacek wrote: > A better solution would be to instroduce a generic ::number, justified by the general importance of numbers :) > > somefun ....... numarg::number = ......; // now writes and reads much easier That opens a can of worms. I've really given this some thought, and even coughed up a syntax to define "derived" type tags like this, but it's just not feasible. It would seem rather odd if derived tags could only be used once on the lhs of an equation, but otherwise just a little sloppy coding makes your code size explode combinatorically. There's already the Lispy way to deal with this kind of ad hoc polymorphism, namely just forget about the type tags; if necessary, add a call to numberp or some such predicate to the guard. In most cases this will be fast enough. In some cases it certainly makes sense to optimize the definitions, but then you'll just have to use multiple lhs. Which also keeps you painfully aware that you're actually defining multiple rules, but that's intended. ;-) > // mod of a double > x::double mod y::int = (x - intx) + (intx mod y) when intx = (int x) end; If memory serves me, Common Lisp has this, but not any Algol-like language I know. I can add it to math.pure if there's enough demand. > I also realise that the exclusion of doubles from the pure mod is probably trying to be consistent > with the C usage (mod versus modf). No, it's trying to be consistent with 'div' which doesn't take a double as its first operand either. Same as in Algol 60 and its successors, not C. Cheers, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Eddie R. <er...@bm...> - 2008-07-07 17:44:06
|
Ok. e.r. On Mon, 2008-07-07 at 17:45 +0200, Albert Graef wrote: > Eddie Rucker wrote: > > Just noticed that > > > 3%4+2%3; > > 17L%12L > > > > It would look much better if the answer was 17%12 since both 17 and 12 > > are machine ints. > > The whole point of the rational type is that it represents exact > rationals, you certainly don't want numerator and denominator to wrap > around in rational arithmetic like machine ints do. That's why rational > numbers necessarily use bigints and thus int operands of % must be > promoted to bigint. > > Albert > |
|
From: Albert G. <Dr....@t-...> - 2008-07-07 16:04:15
|
Eddie Rucker wrote: > Just noticed that > > 3%4+2%3; > 17L%12L > > It would look much better if the answer was 17%12 since both 17 and 12 > are machine ints. The whole point of the rational type is that it represents exact rationals, you certainly don't want numerator and denominator to wrap around in rational arithmetic like machine ints do. That's why rational numbers necessarily use bigints and thus int operands of % must be promoted to bigint. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Libor S. <li...@gm...> - 2008-07-07 14:52:57
|
Forgive me for raising this topic again, I seem to recall that is was touched upon, and rejected, when we were discussing the introduction of "|". However, attempting to reach some kind of polymorphism while maximising the efficiency benefits of "::", I find myself repeatedly writing code of the form: somefun ...... numarg::int | somefun ...... numarg::bigint | soomefun ..... numarg::double = .....; Firstly, when it is only the last argument's type changing, it should be possible to write: somefun ....... numarg::int::bigint::double = .......; without introducing an exponential explosion. However, I understand that this could be considered quirky and so it is not my main point. A better solution would be to instroduce a generic ::number, justified by the general importance of numbers :) somefun ....... numarg::number = ......; // now writes and reads much easier On a related topic, I had to write my own mod definition that also works on doubles and this somewhat eased the above problem: // mod of a double x::double mod y::int = (x - intx) + (intx mod y) when intx = (int x) end; I understand that if I use math.pure, I can do anything I want, as in C but this is more a matter of having a convenient basic facility in the default pure, leading to ease of polymorphic coding. I also realise that the exclusion of doubles from the pure mod is probably trying to be consistent with the C usage (mod versus modf). However, C does not have the polymorphism. So, is there an overriding reason for NOT including my modification in the pure's default mod? Plus carrying out modifications in the same spirit to other similar functions? In general, in such cases, I don't think it is particularly dangerous or surprising for users to get a double out when they supply a double as input. I find it more unsettling and bothersome "down the line" when it currently just fails to evaluate. Regards, Libor |
|
From: Eddie R. <er...@bm...> - 2008-07-07 14:47:26
|
Just noticed that > 3%4+2%3; 17L%12L It would look much better if the answer was 17%12 since both 17 and 12 are machine ints. e.r. |
|
From: Eddie R. <er...@bm...> - 2008-07-06 23:12:34
|
On Sun 06/07/08 10:06 AM , Albert Graef Dr....@t-... sent: > Pure's macros will be hygienic, unlike C's. In fact they will just be > ordinary functions, except that they take their arguments as literals > (unevaluated) and are executed at compile time (thanks to the LLVM > JIT). Great! I'm assuming the whole Pure programming language can be used for macros as in Lisp. I can see the same advantages for Pure as in Scheme. I think the biggest win is that you can keep the Pure Interpreter lean and mean and build the rest of the language using pure Pure. I'm looking forward to macros :-) e.r. |
|
From: Albert G. <Dr....@t-...> - 2008-07-06 22:56:51
|
Jiri Spitz wrote: > The test #15 covering dict, hdict, set, bag, array and heap is now ready > to commit. Should I send it to examples for now? No, if the containers pass the tests and you think they're ready, then just move everything over to lib now, and update test015 in 'test', please. Thanks, Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-07-06 22:50:55
|
Jiri Spitz wrote: > > infix 0 => ; > > [1=>1, 2=>2, 3=>3]; > <stdin>:2.8-9: syntax error, unexpected infix 0 operator > > [(1=>1), (2=>2), (3=>3)]; > [1=>1,2=>2,3=>3] > > Ok, this should be fixed now (r403). -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Jiri S. <jir...@bl...> - 2008-07-06 21:27:39
|
Hi Albert, The test #15 covering dict, hdict, set, bag, array and heap is now ready to commit. Should I send it to examples for now? Jiri |
|
From: Jiri S. <jir...@bl...> - 2008-07-06 17:42:51
|
Albert Graef wrote: > > so you can remove those special equality rules in dict.pure. Done. Jiri |
|
From: Libor S. <li...@gm...> - 2008-07-06 15:55:57
|
Thanks, yes, all is fine now. I don't normally reconfigure on every update. Please try to include the word "configure" as a warning in the svn message for the updates that require reconfiguring, otherwise you will keep getting these silly messages from me ;) Libor On Sun, 06 Jul 2008 15:41:47 +0100, Albert Graef <Dr....@t-...> wrote: > Libor Spacek wrote: >> "gettimeofday" does not return any digits after the decimal point, so it has no better resolution than time. > > Then you probably forgot to rerun configure. The time functions are > platform-dependent, so they must be detected at build time. If nothing > else is found, Pure's gettimeofday and nanosleep will fall back to > time() and sleep(), respectively, that's why you see this behaviour. > Rerun configure and all should be fine. > > Albert > |
|
From: Albert G. <Dr....@t-...> - 2008-07-06 15:06:14
|
Eddie Rucker wrote: > I've been waiting for the special forms like in Q or macros like in C or Scheme to pop up any day now! I like the latter too > because that is what most people coming from C are already use to. Pure's macros will be hygienic, unlike C's. In fact they will just be ordinary functions, except that they take their arguments as literals (unevaluated) and are executed at compile time (thanks to the LLVM JIT). I've been tossing around this idea ever since I implemented the constant definitions (which already execute ordinary Pure expressions at compile time). It will be an easy extension of that, much easier to implement than Q's runtime special forms. Q's special forms are nice because they unify macros and lazy data structures, but they also incur significant runtime overhead. Pure macros will give us the former without any runtime penalty, and the latter can also be implemented using other techniques. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-07-06 14:41:52
|
Libor Spacek wrote: > "gettimeofday" does not return any digits after the decimal point, so it has no better resolution than time. Then you probably forgot to rerun configure. The time functions are platform-dependent, so they must be detected at build time. If nothing else is found, Pure's gettimeofday and nanosleep will fall back to time() and sleep(), respectively, that's why you see this behaviour. Rerun configure and all should be fine. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Albert G. <Dr....@t-...> - 2008-07-06 14:38:32
|
Libor Spacek wrote: > exectime How about timex? :) > Those C prototypes could be included by the user: > > importfns "int a(int*),long foo(baz)" from somelib; Nah, that doesn't look good IMHO, neither does it provide an advantage over having a 'using "lib:..."' clause followed by a couple of extern declarations. > I guess we will always have these two "parallel universes", Definitely. There's no safe way for the Pure interpreter to figure out what the prototypes are. But that's not much different from the FFIs of other languages. Albert -- Dr. Albert Gr"af Dept. of Music-Informatics, University of Mainz, Germany Email: Dr....@t-..., ag...@mu... WWW: http://www.musikinformatik.uni-mainz.de/ag |
|
From: Libor S. <li...@gm...> - 2008-07-06 13:38:37
|
While testing this, I found that "gettimeofday" does not return any digits after the decimal point, so it has no better resolution than time. everything else seems OK. L. |
|
From: Libor S. <li...@gm...> - 2008-07-06 12:48:11
|
I like the macros idea too. The only nearly-apt name for the timing function I can think of is: exectime On Sun, 06 Jul 2008 12:42:20 +0100, Albert Graef <Dr....@t-...> wrote: >> using "lib:somelib"; >> extern a; >> extern b; >> extern c; >> extern xyz; > > That doesn't make any sense, as 'using "lib:somelib"' is only for > linking against dynamic libraries, and Pure has no way of knowing the > prototypes of the C functions that you want to import. > > 'import purescript' is different, right now it just textually includes > the script at that point, there's no separate compilation of Pure > scripts (yet). > Those C prototypes could be included by the user: importfns "int a(int*),long foo(baz)" from somelib; translated to (this will need a macro too?): using "lib:somelib.so"; extern int a(int*); extern long foo(baz); but this will now not work for Pure defined functions. I guess we will always have these two "parallel universes", as the prototypes will also cause problems when trying to treat the C namespace in the same way as one of many Pure namespaces? Libor |
|
From: Eddie R. <er...@bm...> - 2008-07-06 12:07:33
|
On Sun 06/07/08 6:37 AM , Albert Graef Dr....@t-... sent: > Eddie Rucker wrote: > >> Yes, I have that too. Eddie, can I kindly ask you to > restrict your>> telepathy experiments to your students? ;-) > > > > Sorry, what should I do? Maybe reply to stuff in one > batch at one time of the day? > Eddie, please relax, that was a joke. ;-) Nothing wrong on your part, > itjust seems that your replies are getting through quicker than even our > posts that you reply to. :) Phew! The ML server they put us on must be close by. e.r. |
|
From: Eddie R. <er...@bm...> - 2008-07-06 11:54:49
|
On Sun 06/07/08 6:34 AM , Albert Graef Dr....@t-... sent: > That function would have to be a special form. Either it needs to be > implemented in the compiler, or we need some facility to define macro > functions to be executed at compile time (pretty much like 'def', but > for defining macros which can take arguments), then it could be defined > in terms of 'clock' above. > > I'm leaning towards the latter solution, because it's much more > general,and would be useful in lots of other situations. I've been waiting for the special forms like in Q or macros like in C or Scheme to pop up any day now! I like the latter too because that is what most people coming from C are already use to. e.r. |
6 messages has been excluded from this view by a project administrator.
