August 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] optimizing primitiveFindFirstInString

by Levente Uzonyi

On Mon, 15 Aug 2011, Philippe Marschall wrote: > On 15.08.2011 00:21, Levente Uzonyi wrote: >> On Sun, 14 Aug 2011, Philippe Marschall wrote: >> >>> On 14.08.2011 22:00, Levente Uzonyi wrote: >>>> On Sun, 14 Aug 2011, Philippe Marschall wrote: >>>> >>>>> Hi >>>>> >>>>> In Seaside we get a lot of performance gains out of >>>>> primitiveFindFirstInString. One thing that always annoyed me a bit is >>>>> that it's not as optimized as it could be. >>>>> >>>>> The inclusionMap you give it are 256 consecutive boolean values (0 or >>>>> 1). There is no need for this to be a 256 element ByteArray when each >>>>> element can only be 0 or 1. We could as well make it a 32 element >>>>> ByteArray and each byte holding eight bit values. Instead of using the >>>>> asciiValue to directly index into the inclusionMap we would use the top >>>>> five bits to index into the inclusionMap and the bottom 3 bits to >>>>> "index >>>>> into the byte". >>>>> >>>>> Did that make any sense? >>>> >>>> Do you want to save space? >>> >>> I'm trying to trade memory access (which is slow) for a bit shift and >>> two bit ands (which is fast). >> >> 256 bytes + object header easily fit into the L1 cache of any recent x86 >> CPU, even the old P4's had 8kB of it. > > Sure once it's in the cache then it's in the cache. But a cache line is > only 64 bytes. So a 32 element array should fit and a 256 element > doesn't. So a 32 element array should be there in one memory access > while a 256 element array probably takes five. A 32 element array needs 1-2 cache lines, while the 256 element array needs 4-5. It's not that big difference IMHO. (Especially if you want to pass a ByteArray and convert it ot a 32 byte array in C.) > >> Moving less bytes around may make >> some difference though, but if you create your ByteArrays right before >> you use them, then it's pretty likely that your object is already in the >> cache. > > I don't of course. > >>> >>>> Are you storing lots of inclusion maps (maybe >>>> CharacterSets)? If not, then IMHO it's not worth to adding this feature >>>> to this primitive, because runtime performance will be worse on both the >>>> image side and the VM side. >>> >>> Why? >> >> Filling the contents of a compact 32 sized ByteArray in the image takes >> more time than a 256 byte ByteArray. On the VM side memory access + >> shifts + bitands cost more than just memory access. > > Uhm, it's a primitive. My understanding is this would result in "C > shifts + bitands". Hm. Are you about to change the primitive to create an array of 32 bytes from the ByteArray argument and use that during the search? > >> But (as usual) a >> benchmark can tell if it's really worth to do it or not. > > This there somewhere some documentation how one adds a primitive and > compiles a VM (Cog ideally)? This primitive is in the image, search for the method with the string 'primitiveFindFirstInString'. The same way you can add others methods to MiscPrimitivePlugin. IIRC there's a registry (an array in a method on the plugin's class' side) for these methods where you should add the new method, look for the method name (as string/symbol) to find it. There are multiple ways to build VMs, but I guess you want to follow the way developed by Igor. Levente > > Cheers > Philippe > > >

Aug. 15, 2011

Re: [Pharo-project] [Esug-list] Smalltalk lecture Saturday 20th of August at ESUG

by HwaJongOh

can i watch this via internet? Best Regards HwaJogn Oh 2011. 8. 14., ì ë 5:13, StÃ©phane Ducasse ìì±: > Hi Friends please distribute that widely > > > I will give a free lecture > > > Discovering Smalltalk > > Smalltalk is a pure and elegant object language. This lectures will cover the fundamental aspects of Smalltalk: > syntax, semantics, and key aspects of the system. Doing so we will also revise the real semantics of self/super. > We will show the power of polymorphism in action by simply learning from the system. Finally we will go into > more design aspect again based on the systems. As a bonus we will start the lecture with a 15 min presentation > of Seaside a powerful web framework for dynamic web application. > > This lecture may be followed by a lecture on more advanced object-oriented design: > law of demeter, encapsulation, multiple interface of classes, composition vs. inheritance > > Starting time: 9h30 > Closing: 16h00 > > Location: http://www.esug.org/wiki/pier/Conferences/2011/The-Venue-in-Edinburgh > > > > Bio: He is expert in object-oriented language design, dynamic languages, reflective programming, language semantics as well as reengineering, program analysis, > visualizations, software metrics. Recently he worked on traits, composable method groups, and this work got some impact. Traits have been introduced AmbiantTalk, > Pharo, Perl-6, PHP 5.4 and Squeak. They influenced Scala and Fortress SUN Microsystems. Stephane is one of the developer of Pharo (http://www.pharo.project.org/) > an open-source language inspired by Smalltalk. He is one of the core developer of Moose, an open-source reengineering environment (http://moose.unibe.ch/) > He is the president of the European Smalltalk User Group and organize a yearly international conference on Smalltalk. He wrote a couple of fun books to teach > programming and other serious topics such as dynamic web development (http://book.seaside.st) > > Stef > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org

Aug. 15, 2011

[Pharo-project] [update 1.4] #14093

by Marcus Denker

14093 ----- Issue 4645: use a bit more {} instead of Array with: http://code.google.com/p/pharo/issues/detail?id=4645 Issue 4644: subclass of ReadStreamTest to test RWBinaryOrTextStreamTest http://code.google.com/p/pharo/issues/detail?id=4644 Issue 4634: Tools menu build by code from Deprecated13 http://code.google.com/p/pharo/issues/detail?id=4634 Issue 4627: Remove deprecated from NullTextStyler http://code.google.com/p/pharo/issues/detail?id=4627 -- Marcus Denker -- http://marcusdenker.de

Aug. 15, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by laurent laffont

Hi Igor, now it works well. I've created CogOnDebian64Config but I cannot commit to VMMaker repository. So you can get it on: Gofer it squeaksource: 'LaurentLSandbox'; version: 'CMakeVMMaker-LaurentLaffont.135'; load In CogOnDebian64Config comment: Used to build 32 bit Cog on Debian 64 bits. You need to prepare Debian this way: apt-get install ia32-libs libc6-dev-i386 gcc-multilib g++-multilib ln -s /usr/lib32/libSM.so.6 /usr/lib32/libSM.so ln -s /usr/lib32/libICE.so.6 /usr/lib32/libICE.so ln -s /usr/lib32/libGL.so.1 /usr/lib32/libGL.so ln -s /usr/lib32/libX11.so.6 /usr/lib32/libX11.so Then you can go on CogOnDebian64Config generateWithSources. Laurent. On Mon, Aug 15, 2011 at 10:37 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 15 August 2011 11:34, laurent laffont <laurent.laffont(a)gmail.com> > wrote: > > > > If I edit vm-display-null/CMakeLists.txt and change: > > set_target_properties(vm-display-null PROPERTIES PREFIX "" SUFFIX "" ) > > to > > set(linkFlags "${linkFlags} -m32") > > set_target_properties(vm-display-null PROPERTIES LINK_FLAGS > "${linkFlags}" PREFIX "" SUFFIX "" ) > > then cmake. && make > > it works, right flags used. > > So it seems that generateWithSources output wrong > vm-display-null/CMakeLists.txt > > Laurent. > > > Yes. Try out CMakeVMMaker-IgorStasenko.134 > > And thanks for being persistent! :) > > -- > Best regards, > Igor Stasenko AKA sig. >

Aug. 15, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by Igor Stasenko

this stuff requires a bit of refactoring. it is a bit messy, that #linkFlags contain libs rather than flags. the libs should be added separately On 15 August 2011 11:41, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > On Mon, Aug 15, 2011 at 10:37 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 15 August 2011 11:34, laurent laffont <laurent.laffont(a)gmail.com> wrote: >> > >> > If I edit vm-display-null/CMakeLists.txt and change: >> > set_target_properties(vm-display-null PROPERTIES PREFIX "" SUFFIX "" ) >> > to >> > set(linkFlags "${linkFlags} -m32") >> > set_target_properties(vm-display-null PROPERTIES LINK_FLAGS "${linkFlags}" PREFIX "" SUFFIX "" ) >> > then cmake. && make >> > it works, right flags used. >> > So it seems that generateWithSources output wrong vm-display-null/CMakeLists.txt >> > Laurent. >> > >> Yes. Try out CMakeVMMaker-IgorStasenko.134 >> >> And thanks for being persistent! :) > > Cool ! I'll try later. Indeed, I've again learned :) Â Seriously, build process is far nicer now than it was one year ago. > Laurent. > >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2011

[Pharo-project] [update 1.4] #14092

by Marcus Denker

14092 ----- Issue 4639: Package System-SourceAndChangeFile is empty http://code.google.com/p/pharo/issues/detail?id=4639 Issue 4641: Small ImageSegments related cleanup http://code.google.com/p/pharo/issues/detail?id=4641 -- Marcus Denker -- http://marcusdenker.de

Aug. 15, 2011

[Pharo-project] [update 1.4] #14092

by Marcus Denker

14091 ----- Issue 4633: Package Graphics-Resources is dirty -- Marcus Denker -- http://marcusdenker.de

Aug. 15, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by laurent laffont

On Mon, Aug 15, 2011 at 10:37 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > On 15 August 2011 11:34, laurent laffont <laurent.laffont(a)gmail.com> > wrote: > > > > If I edit vm-display-null/CMakeLists.txt and change: > > set_target_properties(vm-display-null PROPERTIES PREFIX "" SUFFIX "" ) > > to > > set(linkFlags "${linkFlags} -m32") > > set_target_properties(vm-display-null PROPERTIES LINK_FLAGS > "${linkFlags}" PREFIX "" SUFFIX "" ) > > then cmake. && make > > it works, right flags used. > > So it seems that generateWithSources output wrong > vm-display-null/CMakeLists.txt > > Laurent. > > > Yes. Try out CMakeVMMaker-IgorStasenko.134 > > And thanks for being persistent! :) > Cool ! I'll try later. Indeed, I've again learned :) Seriously, build process is far nicer now than it was one year ago. Laurent. > > -- > Best regards, > Igor Stasenko AKA sig. >

Aug. 15, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by Igor Stasenko

On 15 August 2011 11:34, laurent laffont <laurent.laffont(a)gmail.com> wrote: > > If I edit vm-display-null/CMakeLists.txt and change: > set_target_properties(vm-display-null PROPERTIES PREFIX "" SUFFIX "" ) > to > set(linkFlags "${linkFlags} -m32") > set_target_properties(vm-display-null PROPERTIES LINK_FLAGS "${linkFlags}" PREFIX "" SUFFIX "" ) > then cmake. && make > it works, right flags used. > So it seems that generateWithSources output wrong vm-display-null/CMakeLists.txt > Laurent. > Yes. Try out CMakeVMMaker-IgorStasenko.134 And thanks for being persistent! :) -- Best regards, Igor Stasenko AKA sig.

Aug. 15, 2011

Re: [Pharo-project] [Vm-dev] building Cog on 64 bits debian

by laurent laffont

If I edit vm-display-null/CMakeLists.txt and change: set_target_properties(vm-display-null PROPERTIES PREFIX "" SUFFIX "" ) to set(linkFlags "${linkFlags} -m32") set_target_properties(vm-display-null PROPERTIES LINK_FLAGS "${linkFlags}" PREFIX "" SUFFIX "" ) then cmake. && make it works, right flags used. So it seems that generateWithSources output wrong vm-display-null/CMakeLists.txt Laurent. On Mon, Aug 15, 2011 at 9:55 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > > On Mon, Aug 15, 2011 at 9:04 AM, laurent laffont < > laurent.laffont(a)gmail.com> wrote: > >> >> Igor, >> >> I have 32bits version of needed libraries - they are installed by >> package libc6-dev-i386 in /usr/lib32 >> >> I've created CogDebian64Config and adjust linkFlags / commonCompilerFlags >> so I have: >> >> CogDebian64Config new linkFlags >> '-lSM -lICE -ldl -lGL -lpthread -lm -lnsl -lX11 -m32 -L/usr/lib32' >> >> CogDebian64Config new compilerFlags ' -DLSB_FIRST=1 -DUSE_GLOBAL_STRUCT=0 >> -DCOGMTVM=0 -m32 -L/usr/lib32 -g0 -O2 -msse2 -D_GNU_SOURCE -DNDEBUG >> -DITIMER_HEARTBEAT=1 >> -DNO_VM_PROFILE=1 -DDEBUGVM=0' >> >> >> but when I make VERBOSE=1 >> >> Linking C shared library /root/securedvm/results/vm-display-null >> cd /root/securedvm/build/vm-display-null && /usr/bin/cmake -E >> cmake_link_script CMakeFiles/vm-display-null.dir/link.txt --verbose=1 >> /usr/bin/gcc -fPIC -shared -Wl,-soname,vm-display-null -o >> /root/securedvm/results/vm-display-null >> CMakeFiles/vm-display-null.dir/root/securedvm/platforms/unix/vm-display-null/sqUnixDisplayNull.c.o >> -lm -ldl -lpthread >> collect2: ld terminated with signal 11 [Segmentation fault] >> /usr/bin/ld: i386 architecture of input file >> `CMakeFiles/vm-display-null.dir/root/securedvm/platforms/unix/vm-display-null/sqUnixDisplayNull.c.o' >> is incompatible with i386:x86-64 output >> >> >> So it seems compilerFlags are not used for building vm-display-null !!! >> > > > Be sure to remove the cache file of cmake. Sometimes it is not removed when > in fact it is necessary. So in any test you do you better remove > ../biuld/CMakeCache.txt > > Anyway, it is weird it is not using #compilerFlags. Becuase: > #addVMDrivers: does > > addDriver: 'vm-display-null' > sources: #( > '${targetPlatform}/vm-display-null/sqUnixDisplayNull' ) > generator: maker; > > addDriver: 'vm-display-X11' > sources: #( > '${targetPlatform}/vm-display-X11/sqUnixX11' > '${targetPlatform}/vm-display-X11/sqUnixMozilla' ) > generator: maker; > > > .... > > > And then #addDriver: name sources: aSources generator: cmakeGen > sends: > ... > addDefinitions: self compilerFlags; > > ...LINK_FLAGS "', self linkFlags , '"' > > > > > >> Same result if I export CC="gcc -m32" >> >> >> Flags are used for building CogVM though: >> >> [ 57%] Building C object >> JPEGReadWriter2Plugin/CMakeFiles/JPEGReadWriter2Plugin.dir/root/securedvm/platforms/Cross/plugins/JPEGReadWriter2Plugin/jquant2.c.o >> cd /root/securedvm/build/JPEGReadWriter2Plugin && /usr/bin/gcc >> -DLSB_FIRST=1 -DUSE_GLOBAL_STRUCT=0 -DCOGMTVM=0 -D_GNU_SOURCE -DNDEBUG >> -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DDEBUGVM=0 -DSQUEAK_BUILTIN_PLUGIN >> -DLSB_FIRST=1 -DUSE_GLOBAL_STRUCT=0 -DCOGMTVM=0 -D_GNU_SOURCE -DNDEBUG >> -DITIMER_HEARTBEAT=1 -DNO_VM_PROFILE=1 -DDEBUGVM=0 >> -I/root/securedvm/platforms/unix/plugins/B3DAcceleratorPlugin >> -I/root/securedvm/platforms/Cross/vm -I/root/securedvm/src/vm >> -I/root/securedvm/platforms/unix/vm -I/root/securedvm/build >> -I/root/securedvm/src/plugins/JPEGReadWriter2Plugin >> -I/root/securedvm/platforms/Cross/plugins/JPEGReadWriter2Plugin >> -I/root/securedvm/platforms/unix/plugins/JPEGReadWriter2Plugin -m32 >> -L/usr/lib32 -g0 -O2 -msse2 -m32 -L/usr/lib32 -g0 -O2 -msse2 -o >> CMakeFiles/JPEGReadWriter2Plugin.dir/root/securedvm/platforms/Cross/plugins/JPEGReadWriter2Plugin/jquant2.c.o >> -c /root/securedvm/platforms/Cross/plugins/JPEGReadWriter2Plugin/jquant2.c >> >> >> Laurent >> >> On Sun, Aug 14, 2011 at 10:10 PM, Igor Stasenko <siguctua(a)gmail.com>wrote: >> >>> >>> On 14 August 2011 18:39, laurent laffont <laurent.laffont(a)gmail.com> >>> wrote: >>> > >>> > Thanks Levente. >>> > After searching & trying finally I've passed this problem by: >>> > mv /usr/bin/gcc /usr/bin/real.gcc >>> > and then creating /usr/bin/gcc : >>> > #!/bin/sh >>> > exec real.gcc -m32 $@ >>> > and chmod +x /usr/bin/gcc >>> > >>> > Now I have: >>> > [ 94%] Built target vm-display-null >>> > Scanning dependencies of target vm-display-X11 >>> > [ 94%] Building C object >>> vm-display-X11/CMakeFiles/vm-display-X11.dir/root/securedvm/platforms/unix/vm-display-X11/sqUnixX11.c.o >>> > [ 95%] Building C object >>> vm-display-X11/CMakeFiles/vm-display-X11.dir/root/securedvm/platforms/unix/vm-display-X11/sqUnixMozilla.c.o >>> > Linking C shared library /root/securedvm/results/vm-display-X11 >>> > /usr/bin/ld: skipping incompatible >>> /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libSM.so when searching for >>> -lSM >>> > /usr/bin/ld: skipping incompatible >>> /usr/lib/gcc/x86_64-linux-gnu/4.4.5/../../../libSM.a when searching for -lSM >>> > /usr/bin/ld: skipping incompatible /usr/lib/libSM.so when searching for >>> -lSM >>> > /usr/bin/ld: skipping incompatible /usr/lib/libSM.a when searching for >>> -lSM >>> > /usr/bin/ld: cannot find -lSM >>> > collect2: ld returned 1 exit status >>> > >>> >>> looks like you don't have 32bit version of this library. >>> That's why it refusing to link. >>> >>> As for compiler options, i don't think that you need to use >>> workarounds (like creating real.gcc etc) , because the -m32 flag is >>> there: >>> >>> # This is automatically generated file using CogUnixConfig on 14 >>> August 2011 10:01:34 pm >>> ... >>> message("Adding module: vm-sound-null") >>> add_definitions( -DLSB_FIRST=1 -DUSE_GLOBAL_STRUCT=0 -DCOGMTVM=0 -m32 >>> -g0 -O2 -msse2 -D_GNU_SOURCE -DNDEBUG -DITIMER_HEARTBEAT=1 >>> -DNO_VM_PROFILE=1 -DDEBUGVM=0) >>> ... >>> >>> Try building using: >>> >>> make VERBOSE=1 >>> >>> to see what flags are passed to compiler. >>> >>> And please, create a subclass of CogUnixConfig , like >>> Cog32OnDebian64Config >>> and play with definitions there. >>> >>> In image you can do: >>> >>> Cog32OnDebian64Config generateWithSources >>> or >>> Cog32OnDebian64Config generate >>> >>> the difference that first will generate cmake files + source files, >>> while second one is only cmake files (takes less than second) >>> >>> I suspecting that problem with linker flags, which tries to link >>> 32-bit output with 64-bit binary. >>> It seems that we're missing the flag there that it should use 32-bit >>> binary for output. >>> >>> > Laurent >>> > >>> > On Sat, Aug 13, 2011 at 4:36 PM, Levente Uzonyi <leves(a)elte.hu> wrote: >>> >> >>> >> On Sat, 13 Aug 2011, laurent laffont wrote: >>> >> >>> >> (no quotes thx to gmail...) >>> >> >>> >> This issue was discussed several times. The simplest solution is to >>> define CC as "gcc -m32" (and optionally CXX as "g++ -m32" if you need g++). >>> Another solution is to check how cmake supports cross compilation. IIRC >>> autotools has some flags for this. >>> >> >>> >> >>> >> Levente >>> > >>> > >>> > >>> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > >

Aug. 15, 2011