NeXuS VUS (Very Unuseful Stuff) » Programming

Stackless Python vs. Go

NeXuS — Thu, 19 Nov 2009 10:17:18 +0000

Note: I did a little more research and it turns out that the gc runtime creates one OS thread only, and then adds threads as a way to avoid I/O locks. On the other hand the gccgo runtime maps goroutines and p_threads on a 1 to 1 basis (as of now).

I have been lazily following the Go language project for a while now, when it
was suddenly discussed in this post of “Appunti Digitali” (in italian), that
pointed at this post
on Dalke Scientific.

It really got me that S.Python manages to beat Go so
badly, so I decided to run my own tests on my trusty old IBM X-41 (Pentium-M 1.5
GHz).

I compiled the Go toolchain and S.Python, then ran the
test exactly as I found them on the Dalke page. The results are following
hereby:

$ time ./8.out 100000

real 0m5.197s user 0m1.508s sys 0m1.352s

$ time /usr/local/bin/python2.6 test.py 100000

real 0m3.315s user 0m1.556s sys 0m0.148s

What really struck me is that
the time spent in userland is roughly the same for both programs. What really
kills the Go execution time is that it spends almost as much time in kernel
mode. I wondered why…

Then I remembered that, in the Google Tech Talk,
Pike said something about the Go runtime managing threads for the user, and I
automatically thought that it would associate user threads with OS threads in
some way (as is the norm). In fact that is what gccgo does (uses NTPL).

On
the other hand, reading Stackless Python documentation, I found this page
regarding Tasklets. The page clearly states: “Tasklets are
characterized by being very lightweight and portable, and make great
alternatives to system threads or processes.”

So I am prone to believe
that S.Python Tasklets are managed by the Python VM itself, requiring no
user-to-kernel mode transitions and no other kernel interaction… because they
are not real threads (as opposed to Go goroutines).

This, with the fact
that Go is mainly intended to cut compile time (not so much running
time), makes me believe the comparison to be pretty unfair, and I think Go
provides quite a performance!

Regarding certain unsafe situations, they
are definitely a problem. Still, I believe that they will be taken care of
quickly: Go is a brand new language and rough edges are to be expected here and
there, but it has quite some room for growth.

Update:

I modified the test program so that each goroutine/Tasklet calls a second
function that loops 1000 times and cumulates the result of “sum = sum+1″.

The results are as expected: the compiled code is one order of magnitude faster
than Stackless Python interpreted code! I also replaced range with xrange, as suggested by Cesare
Di Mauro, but that did not change things much… nor did it when I tried psyco
(a JIT compiler for Python).

$time ./test2 && time /usr/local/bin/python test2.py 100000


real    0m4.037s

user    0m1.040s

sys     0m0.840s

100000

real 0m19.567s user 0m15.697s sys 0m0.160s

The source code for Python is:
default=100000)


def f(left, right):

    loop()

    left.send(right.receive()+1)
def loop():

    sum = 0

    for i in xrange (1,1000):

        sum=sum+1
def main():

    options, args = parser.parse_args()

    leftmost = stackless.channel()

    left, right = None, leftmost

    for i in xrange(options.num_tasklets):

        left, right = right, stackless.channel()

        stackless.tasklet(f)(left, right)

    right.send(0)

    x = leftmost.receive()

    print x

stackless.tasklet(main)() stackless.run()

And the test code for Go is:
"fmt"; )


var ngoroutine = flag.Int("n", 100000, "how many")
func f(left, right chan int) {

        loop();

        left < - 1+<-right;

}
func loop() {

        var sum int;

        sum = 0;

        for i := 0; i < 1000; i++ {

                sum = sum + 1

        }

}

func main() { flag.Parse(); leftmost := make(chan int); var left, right chan int = nil, leftmost; for i := 0; i < *ngoroutine; i++ { left, right = right, make(chan int); go f(left, right); } right <- 0; // bang! x := <-leftmost; // wait for completion fmt.Println(x); // 100000 }

Stopping Qt compilation

NeXuS — Mon, 31 Aug 2009 09:43:00 +0000

Today I tried stopping Qt complation on my Windows maching (using MS compiler).

Here are the last few lines of output.

moc_formextractor.cpp moc_mainwindow.cpp Generating Code... cl -c -nologo -Zm200 -Zc:wchar_t- -O2 -MD -GR -EHsc -W3 -w34100 -w34189 -DUNICODE -DWIN32 -DQT_LARGEFILE_SUPPORT -DQT_NO_DEBUG -DQT_WEBKIT_LIB -DQT_GUI_ LIB -DQT_CORE_LIB -DQT_THREAD_SUPPORT -I"..\..\..\include\QtCore" -I"..\..\..\in clude\QtGui" -I"..\..\..\include\QtWebKit" -I"..\..\..\include" -I"..\..\..\incl ude\ActiveQt" -I"tmp\moc\release_static" -I"." -I"." -I"..\..\..\mkspecs\win32-m svc2008" -Fotmp\obj\release_static\ @C:\DOCUME~1\MASSIM~1.CIL\LOCALS~1\Temp\nmA2 E.tmp qrc_formextractor.cpp link /LIBPATH:"c:\Qt\2009.03\qt\lib" /LIBPATH:"c:\Qt\2009.03\qt\lib" /NO LOGO /INCREMENTAL:NO /MANIFEST /MANIFESTFILE:"tmp\obj\release_static\formExtract or.intermediate.manifest" /SUBSYSTEM:WINDOWS "/MANIFESTDEPENDENCY:type='win32' n ame='Microsoft.Windows.Common-Controls' version='6.0.0.0' publicKeyToken='6595b6 4144ccf1df' language='*' processorArchitecture='*'" /OUT:release\formExtractor.e xe @C:\DOCUME~1\MASSIM~1.CIL\LOCALS~1\Temp\nmA2F.tmp NNNMMMNAAAMKKKAEEEK E::: :fff aaaftttaaaatllla leee rrrerrrrooorrrro rU UU 111U000155508885:::8 : NMAKE : fatal error U1058: ttttteeeeerrrrrmmmmmiiiii nnnnnaaaaattttteeeeeddddd bbbbbyyyyy uuuuussssseeeeerrrrr

SSSSStttttoooooppppp.....

About ComboBox and Data binding (.NET, C#)

NeXuS — Mon, 03 Apr 2006 12:36:52 +0000

So, it seems like I am not able to post about anything else than IT!

Anyway, I had this strange problem with the ComboBox control of the .NET 2.0 framework (but I guess the problem would have been manifest with version 1.0/1.1 too):
I had some ComboBoxes that I had been binding to some DataTables generated as the result of some Stored Procedure calls on a DB server. Everything seemed to be working until I tried to set the ComboBox.SelectedValue property manually: disaster happened and nothing worked as it should have.

The reason for this strange behaviour was that I did not add the ComboBoxes to the form Control list BEFORE binding the source!
The worst thing of it all is that I have not been able to find any clue about the order in which these two operations whould be done on the MSDN, nor on various developer forums!

So rememeber:

First add the controls to your form
And only then you can correctly set the DataSource