Hi Ben,

On Wed., 19 Sep. 2018, 16:50 Ben Coman, btc@openinworld.com wrote:

Well spotted. But next puzzle... Where do "those" numbers come from? i.e... Appveyor defines... -DFILEVERSIONVALUES=2018,8,29,1622 My build defines... -DFILEVERSIONVALUES=,,,

Yeah, sorry, I had to run for other things, but hoped it would provide enough of a clue.

Ahh, found it... common/Makefile.tools:RCFLAGS:= --include-dir $(PLATDIR)/win32/misc -D_WIN32 -DFILEVERSIONVALUES=$(SVNMAJOR),$(SVNMINOR),$(SVNREV),$(SVNBUILD) '-DFILEVERSIONSTRING="$(SVNMAJOR).$(SVNMINOR).$(SVNREV).$(SVNBUILD)\0"'

Damn! Forgetting to run ```updateSCCSversions``` on a fresh clone bites me again! :( :(

I have a script that I always use to run the compilation. :-) (I don't care about the overhead of repeatedly executing ```updateSCCSversions``)

Cheers, Alistair

Better now, thx Alistair.

cheers -ben

On Wed, 19 Sep 2018 at 21:25, Alistair Grant akgrant0710@gmail.com wrote:

...

Hi Ben,

I've never built squeak.cog.spur on windows (or any other platform :-)), but if you look at the appveyor log you can see that FILEVERSIONVALUES being defined:

https://ci.appveyor.com/project/OpenSmalltalk/vm/build/job/a6x5mg5uw7p8c882?...

hth, Alistair

On Wed, 19 Sep 2018 at 15:17, Ben Coman btc@openinworld.com wrote:

...

I tried to build via "build.win32x86/squeak.cog.spur/mvm" but got an

error with the resource file...

...

i686-w64-mingw32-windres \
    --include-dir ../../platforms/win32/misc \
    -D_WIN32 \
    -DFILEVERSIONVALUES=,,, '-DFILEVERSIONSTRING=\"...\\0\"'  \
    -i Squeak.rc \
    -o builddbg/vm/Squeak.res
==>
i686-w64-mingw32-windres: Squeak.rc:7: syntax error
make[1]: *** [../common/Makefile:296: Squeak.res] Error 1

I see a reference at the top of [1] to this for Pharo but no direct

resolution is mentioned.

...

[1]

http://forum.world.st/Compiling-the-windows-32-bits-vm-td5072691.html

...

[Squeak.rc:7](

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/sq...) is...

...

FILEVERSION FILEVERSIONVALUES

and the value ",,," supplied for FILEVERSIONVALUES on the command line

seems invalid.

...

I see Pharo has hardcoded the value... https://www.diffchecker.com/O36vXV5b

https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/build.win32x86/ph...

...

 FILEVERSION 5,0,0,0

and if I do the same in Squeak.rc the build completes. So should I submit a PR for that, or does anyone know how the command

line "FILEVERSIONVALUES"

...

is supposed to be supplied a proper value? Searching the repo doesn't

give any hints...

...

https://github.com/OpenSmalltalk/opensmalltalk-vm/search?q=FILEVERSIONVALUES

...

cheers -ben

I'm curious if anyone has seen this writeup on VM performance

https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_o...

I found the article very insightful and was curious how we stacked up.

Have written the author to ask about including us in future research.

Cheers. -Todd Blanchard

Tobias,

That's excellent to know... I wasn't aware that this was being looked at. Something that's been in the back of my mind for a while is trying to measure JIT performance vs. JIT code cache size, architecture being run on, and workload. As I understand it, the JIT code cache is a fixed size (~1meg iirc) which doesn't make a lot of sense to me given the variance in CPU cache size (generally in the range of 512k-4m depending on whether you're running on Intel/AMD/ARM, desktop/server, low/high end, HT enabled/disabled, and oddball/extreme CPU configurations like the Intel 5775C with it's 128meg LLC) and then there's the cost of potentially thrashing the JIT cache vs maintaining a larger cache despite the fact that it might exceed the capacity of the CPU cache. (However to measure this I think a few new VM params would be needed: a r/w JIT cache size, JIT cache code evictions (since last full gc?), JIT cache code additions (since last full gc?), Avg cache code size... the current machine code method/compaction counts are a good start but a bit coarse). Just thought I'd throw this out there since it seemed apropos...

Thanks, Phil

On Thu, Sep 20, 2018, 5:02 AM Tobias Pape Das.Linux@gmx.de wrote:

Hi Todd,

...

On 20.09.2018, at 10:28, Todd Blanchard tblanchard@mac.com wrote:

I'm curious if anyone has seen this writeup on VM performance

https://tratt.net/laurie/blog/entries/why_arent_more_users_more_happy_with_o...

...

I found the article very insightful and was curious how we stacked up.

Have written the author to ask about including us in future research.

Cheers. -Todd Blanchard

I know the author and share similar concerns. In fact, for stuff we do here with RSqueak/VM and GraalSqueak, we pay attention to at least some of the concerns Laurie mentions.

Have a look at SMark, which tries to give a reasonable benchmark set set.

http://smalltalkhub.com/#!/~StefanMarr/SMark

also, there's our benchmark runner that builds on SMark

http://www.hpi.uni-potsdam.de/hirschfeld/squeaksource/BenchmarkRunner.html

We also have a codespeed up here: http://speed.squeak.org/

Yea that does not all address the authors issues, but we try :D

Best regards -Tobias