skaller wrote: >> Oddly enough, it's gcc. > > This is not odd. Gcc is a dog. What do you expect from an Open > Source project? Optimisation is particularly slow. > > However gcc 4.x does produce half way reasonable code. > It does do data flow analysis now, which is more than > Felix does. However some of the optimisations are quadratic. > This would affect large routines .. Felix can make large > main routines. > > I guess one could try to use gcc without optimisation, > or with just -O1 instead of -O2, that might speed up > building test codes .. this should work with the > bash script I think (but have a look).
Here are the times I get with and without optimization: > time env PATH=/unencrypted/erickt/Projects/felix/felix.svk/bin:$PATH /unencrypted/erickt/Projects/felix/felix.svk/bin/flxg -q --inline=10 --elkhound=/unencrypted/erickt/Projects/felix/felix.svk/bin/flx_elkhound -I/unencrypted/erickt/Projects/felix/felix.svk/lib projects/lisp/lisp env PATH=/unencrypted/erickt/Projects/felix/felix.svk/bin:$PATH -q 1.53s user 0.10s system 91% cpu 1.779 total > time g++ -fPIC -bundle -c -fno-common -Wall -Wno-invalid-offsetof -Wfatal-errors -DTARGET_BUILD -I/unencrypted/erickt/Projects/felix/felix.svk/rtl projects/lisp/lisp.cpp -o projects/lisp/lisp_dynamic.o g++ -fPIC -bundle -c -fno-common -Wall -Wno-invalid-offsetof -Wfatal-errors 3.41s user 0.47s system 60% cpu 6.407 total > time g++ -O1 -fPIC -bundle -c -fno-common -Wall -Wno-invalid-offsetof -Wfatal-errors -DTARGET_BUILD -I/unencrypted/erickt/Projects/felix/felix.svk/rtl projects/lisp/lisp.cpp -o projects/lisp/lisp_dynamic.o g++ -O1 -fPIC -bundle -c -fno-common -Wall -Wno-invalid-offsetof -o 7.90s user 0.74s system 76% cpu 11.298 total > time g++ -O2 -fPIC -bundle -c -fno-common -Wall -Wno-invalid-offsetof -Wfatal-errors -DTARGET_BUILD -I/unencrypted/erickt/Projects/felix/felix.svk/rtl projects/lisp/lisp.cpp -o projects/lisp/lisp_dynamic.o g++ -O2 -fPIC -bundle -c -fno-common -Wall -Wno-invalid-offsetof -o 10.74s user 0.90s system 38% cpu 30.421 total These times are pretty disheartening. I can't imagine trying to work with a 10k line felix program. What could we do to reduce these times, other than write our own/llvm backend? >> Heh, well, because I was cheating. I put a "print" in the code and it >> never got ran. There any way to detect if a function has side effects, >> and print out a warning/error if it does? I can see how this would be >> basically impossible, but we could at least check if any procs are >> getting called. > > It is possible to catch some cases, but that would defeat your cheats :) > > You could try using a generator, but that still will NOT work if the > result is unused.. you would have to use ignore(): > > ignore(f())); > > Ignore is a C proc which does nothing but the compiler is too > dumb to know that so the argument is always evaluated. It certainly would be interesting if our functions were actually pure functions, and didn't allow procedures to be called inside them as they may cause side effects. Then this subset of felix could become a eager haskell-lite. That might get some of those hair-shirters to come and take a look. >> Oh and one last one: the #import / #include of interdependent code. >> There any way that we could implicitly put in import guards? > > It used to have them. The problem was it didn't work right. What did you do? My first instinct would be to have some global log of all the imported files, and as we import a file, we check if it's already been imported. If so, just ignore the declaration. >> Then we can >> use the same loading mechanism, but the compiler will do the guarding >> for us. Would there ever be a reason to import a file multiple times? > > Yes. Felix has scoping rules, include doesn't propagate macros. > > EG you need #import <flx.flxh> in every file. > Oh I wasn't clear. What I meant was say you had these files: //////////////////////////////////// a.flx: var x = 1; b.flx: x += 1; c.flx: #include "a.flx" #include "b.flx" #include "b.flx" print x; endl; // prints 3 //////////////////////////////////// I'm not sure if we really want to support this. It'd just lead to confusing situations. I'd vote that this actually errors out. The main complication I see is that syntax enhancements and macros could get confused by being imported in different orders. -e ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
