Menu

Show posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Show posts Menu

Messages - pjot

#1
Well I found another way of solving my issue without the need for a 'SELF and never asked further...



Peter
#2
newLISP newS /
August 02, 2009, 09:09:03 AM
No, just checking how the generated Makefile looks like. It is an old habit of me to use 'vim' for every tiny task. My bad.



Peter
#3
newLISP newS /
August 02, 2009, 04:03:14 AM
Quote
Can you try using configure-alt, and then type make?


This 'configure-alt' works fine.


Quote
peter@solarstriker:~/installation/newlisp-10.1.1$ ./configure-alt



Detected Operating System LINUX

Detected memory model LP64, using memory model LP64

UTF-8 is enabled

readline support is disabled



To enable readline support, use the --enable-readline option, and specify the

proper libraries to link by setting the RLFLAGS variable when running

configure.  Also if necessary, use the INCLUDES variable to specify where the

readline header files are."





Type "make" to build your newlisp binary.



If that doesn't work, type "make help"

peter@solarstriker:~/installation/newlisp-10.1.1$ vim Makefile

peter@solarstriker:~/installation/newlisp-10.1.1$ make

make -f makefile_configure

make[1]: Entering directory `/home/peter/installation/newlisp-10.1.1'

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG newlisp.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-symbol.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-math.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-list.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-liststr.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-string.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-filesys.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-sock.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-import.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-xml.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-web.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-matrix.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-debug.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG pcre.c

gcc -m64  -Wall -pedantic -Wno-long-long -Wno-strict-aliasing -O2 -c  -DNEWCONFIG nl-utf8.c

gcc newlisp.o nl-symbol.o nl-math.o nl-list.o nl-liststr.o nl-string.o nl-filesys.o    nl-sock.o nl-import.o nl-xml.o nl-web.o nl-matrix.o nl-debug.o pcre.o nl-utf8.o -m64          -lm -ldl  -o newlisp

strip newlisp

make[1]: Leaving directory `/home/peter/installation/newlisp-10.1.1'


Thanks,

Peter
#4
newLISP newS /
August 01, 2009, 12:13:33 PM
The only thing you have to do is removing all '-m32' entries.



Peter
#5
Whither newLISP? /
August 01, 2009, 11:27:28 AM
With the 64bit newLisp
Quote
newLISP v.10.1.1 64-bit on Linux IPv4, execute 'newlisp -h' for more info.


my computer gets this result:
Quote
1124 ms on a 2.2Ghz AMD Phenom(tm) 9550 Quad-Core Processor

performance ratio:  0.5 (1.0 on Mac OS X, 1.83 GHz Intel Core 2 Duo)
#6
newLISP newS /
August 01, 2009, 11:07:49 AM
The Makefile for 64bit Linux 'makefile_linuxLP64' seems to have a problem... below an changed version so it works with my 64bit Ubuntu 9.04 Linux.
Quote
# makefile for newLISP 64bit v.10.x.x on 64 bit LINUX tested on Intel Core Duo 2

#

# Note, that readline support may require different libraries on different OSs

#



OBJS = newlisp.o nl-symbol.o nl-math.o nl-list.o nl-liststr.o nl-string.o nl-filesys.o

   nl-sock.o nl-import.o nl-xml.o nl-web.o nl-matrix.o nl-debug.o pcre.o



CFLAGS = -m64 -Wall -pedantic -Wno-uninitialized -Wno-strict-aliasing -Wno-long-long -c -O2 -g -DNEWLISP64 -DLINUX



CC = gcc



default: $(OBJS)

#   $(CC) $(OBJS) -m32 -g -lm -ldl -lreadline -o newlisp # for UBUNTU Debian

#   $(CC) $(OBJS) -m32 -g -lm -ldl -lreadline -ltermcap -o newlisp # slackware

#   $(CC) $(OBJS) -m32 -g -lm -ldl -lreadline -lncurses -o newlisp # other Linux Dist

   $(CC) $(OBJS) -g -o newlisp -ldl -lm

   strip newlisp



.c.o:

   $(CC) $(CFLAGS) $<



$(OBJS): primes.h protos.h makefile_linuxLP64


For the other targets you can see a problem as the Makfeile is using both -m32 and -m64. In that situation, linking never succeeds.



Peter
#7
Whither newLISP? /
July 31, 2009, 10:37:25 AM
Quote
If this is compiled Basic, then it looks pretty good for newLISP.

It is compiled BASIC all right and indeed, newLisp runs very well!!


Quote
But still comparing compiled vs dynamic languages is comparing apples and oranges.

In this case, I am particularly interested in newLisp versus any compiled language. I do want to see how well newLisp performs compared with a compiled binary. One of the traditional objections against interpreted languages is, that they are slow. I already observed a very good performance with newLisp programs, but how well does newLisp perform?


Quote
It is also not clear what this example really measures. Probably not floating point addition but rather internal time functions, or both.

Fully agreed. This will always be a problem of benchmarks. Maybe we should say: a similar program with the exact same functionality.


Quote
But my main point is, that languages should not be compared by just testing one or two things, in this case floating point addition and retrieval of system time.

Obviously not! This was just an example. I already was thinking of multiple tests.

In the end one never will get the exact performance. Nevertheless, some sort of global indication is sufficient for me.

Your code indeed improves the performance tremendously. If I also improve the BASIC code in a similar way, with compile optimizations (-fnative) then these are the results:



DECLARE t TYPE double

t = 0

end = NOW + 10

WHILE NOW < end DO
    t = t + 0.0001
WEND

PRINT "Result is: ", t


Result is: 10543.5752



#!/bin/newlisp

(set 't 0.0)
(set 'end (+ (time-of-day) 10000))

(while (< (time-of-day) end)
    (set 't (add t 0.0001))
)

(println "Result is: " t)
(exit)


Result is: 563.1762999



So newLisp runs 94.66% slower compared to the compiled BASIC binary with the same functionality.



Again, it is admitted that the actual test is blurry, therefore I will make more tests to see the difference. The performance on lists for example, will be much better than a similar functionality in BASIC (arrays?). Probably there are more typical Lisp aspects where even a BASIC-compiler will be beaten.



Peter
#8
Whither newLISP? /
July 31, 2009, 06:47:05 AM
So let me give an example. This compiled BASIC program runs for 10 seconds adding 0.0001 to a variable.



DECLARE t TYPE double

t = 0

start = SECOND(NOW)
end = start + 10

WHILE SECOND(NOW) NE end DO
    t = t + 0.0001
WEND

PRINT "Result is: ", t

END


Now, the equivalent of such a BASIC program in newLisp is like this (and correct me if I can implement it more efficiently):



(set 't 0.0)

(set 'start (apply date-value (now)))

(set 'end (+ start 10))

(while (not (= (apply date-value (now)) end))
    (set 't (add t 0.0001))
)

(println "Result is: " t)
(exit)


When run the compiled BASIC program, the result is:


Quote
peter@solarstriker:~/programming$ ./benchmark

Result is: 574.7542999


When I run the newLisp program, the result is:


Quote
peter@solarstriker:~/programming$ newlisp benchmark.lsp

Result is: 373.0229


Both programs run on the same machine in the same Operating System, and to me it seems the results indicate that the BASIC compiler is faster? Again, maybe there can be an optimization for the newLisp program? What do you folks say about it?



Peter
#9
Whither newLISP? /
July 31, 2009, 06:26:20 AM
Go tease some sheep, you compleat fan! ;-)



But the idea is not so difficult? Suppose we check the (add) statement. Let's run a newLisp program continuously adding 0.1 starting from 0, and let's run that program for 5 minutes.



Now, let's do the same thing in another language.



After those 5 minutes, we can see which value was reached, right?



Suppose newLisp reached 1000 and some other language X reached 500, we may safely conclude that newLisp is faster when it comes to adding floats? If we take newLisp as reference, it means language X is 50% slower?
#10
Whither newLISP? /
July 31, 2009, 05:56:31 AM
Quote
And you change the hardware it is running on, or only the OS and it puts the results on its head.

I am running all benchmarks on the same system in the same OS.
Quote
Running this under Linux on the same CPU completely changes the picture. Some functions suddenly perform double as fast or slow.

Good remark. This means that different benchmarks should run for a longer time, like 15 or 30 minutes.



So maybe we have to look at it the other way around: instead of running a program and see how long it takes to complete, run a program for some time, and then see how many actions were performed.
#11
Whither newLISP? /
July 30, 2009, 02:22:08 AM
OK my question was not specific enough. :-)



So let me rephrase: what would be the best portable code, if possible a one-liner, to benchmark the performance of newLisp?



The idea is to compare the performance of newLisp with other languages.
#12
Whither newLISP? / Benchmarking
July 30, 2009, 02:02:46 AM
newLisp guru's,



What would be the best code, if possible one-liner, to benchmark the performance of newLisp?



Greetings

Peter
#13
Whither newLISP? /
July 29, 2009, 11:20:48 AM
OK. Now let's do the same in newLisp:

(println "Hello, world!")

Looks less code to me... ;-)
#14
newLISP Graphics & Sound /
July 27, 2009, 11:01:08 AM
Quote
I'm surprised there is no Debian or Ubuntu package for gtk-server.


Well, me too ;-)



But I have access to Ubuntu nowadays, I can make a package if you like.



For newLisp this is not needed anymore, because with GTK2 you can import the functions on the fly. Not sure if it works for all functions though. Anyway, two links with other examples I made some time ago:



http://www.turtle.dds.nl/newlisp/tables.lsp">http://www.turtle.dds.nl/newlisp/tables.lsp

http://www.turtle.dds.nl/newlisp/fractal.lsp">http://www.turtle.dds.nl/newlisp/fractal.lsp



For another example, and other GTK stuff, look here: http://newlispfanclub.alh.net/forum/viewtopic.php?t=2488">http://newlispfanclub.alh.net/forum/vie ... php?t=2488">http://newlispfanclub.alh.net/forum/viewtopic.php?t=2488



Regards

Peter
#15
Whither newLISP? /
July 21, 2009, 02:26:29 PM
Well the answer maybe here:



http://www.isotton.com/devel/docs/C++-dlopen-mini-HOWTO/C++-dlopen-mini-HOWTO.html">http://www.isotton.com/devel/docs/C++-d ... HOWTO.html">http://www.isotton.com/devel/docs/C++-dlopen-mini-HOWTO/C++-dlopen-mini-HOWTO.html



It is a lot of work though, adding 'EXTERN C' to your relevant functions ;-)



Well crap, C++ is kind of a hype anyway. For small applications you're looking at, it's really useless. Do you know how many lines of code one needs for a simple 'Hello world' application in C++?



But if you're bound with your Nokia environment, it's a pain of course. I guess the only thing you can do is writing your own wrapper ;-)



Cheers

Peter