[Vm-dev] Re: primitiveDigitCompare is slow (was: Re: [squeak-dev] The Inbox: Kernel-dtl.1015.mcz)

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Apr 17 21:10:13 UTC 2016


2016-04-17 22:51 GMT+02:00 Nicolas Cellier <
nicolas.cellier.aka.nice at gmail.com>:

>
>
> 2016-04-17 22:43 GMT+02:00 Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com>:
>
>> AFAICT, cDigitCompare:with:len: is inlined by clang.
>> But the interpreterProxy messages are not inlined, but it's not really
>> amazing, these are different units of compilation.
>>
>
> Ah, and this is the purpose of -flto, link-time-optimization, sorry for
> being slow myself ;)
>
>

Hmm, I'm slow, but is -flto stable?
If I add it t CFLAGS and to LDFLAGS then I cannot compile Spur on mac, and
I cannot decode the error message easily:

0  0x108ee297e  __assert_rtn + 144
1  0x108f709d8
ld::tool::HeaderAndLoadCommandsAtom<x86>::sectionFlags(ld::Internal::FinalSection*)
const + 782
2  0x108f703a5
ld::tool::HeaderAndLoadCommandsAtom<x86>::copySegmentLoadCommands(unsigned
char*) const + 955
3  0x108f6f58c
ld::tool::HeaderAndLoadCommandsAtom<x86>::copyRawContent(unsigned char*)
const + 146
4  0x108f46e0f  ld::tool::OutputFile::writeAtoms(ld::Internal&, unsigned
char*) + 465
5  0x108f3fdda  ld::tool::OutputFile::writeOutputFile(ld::Internal&) + 822
6  0x108f39e94  ld::tool::OutputFile::write(ld::Internal&) + 178
7  0x108ee38fa  main + 1311
A linker snapshot was created at:
    /tmp/Squeak-2016-03-17-230136.ld-snapshot
ld: Assertion failed: (0 && "typeTempLTO should not make it to final linked
image"), function sectionFlags, file
/Library/Caches/com.apple.xbs/Sources/ld64/ld64-264.3.101/src/ld/HeaderAndLoadCommands.hpp,
line 780.
clang: error: linker command failed with exit code 1 (use -v to see
invocation)
make: *** [build/vm/Squeak] Error 1



> The procedure I used for checking was:
>>
>> vim ../common/Makefile.flags (add option -S to CFLAGS)
>> touch ../../src/plugins/LargeIntegers/LargeIntegers.c
>> mvm -f
>> less build/LargeIntegers/LargeIntegers.o
>>
>> And you are certainly right, compared to a few bit ops, the function
>> calls/return/stack handling are expensive.
>> So inlining should make a measurable difference for "small" large
>> integers.
>> I was biased by giant integers which is more what I'm after (tight loops)
>>
>> Nicolas
>>
>>
>> 2016-04-17 0:59 GMT+02:00 Levente Uzonyi <leves at caesar.elte.hu>:
>>
>>>
>>> Hi Nicolas,
>>>
>>> It's been a while I optimized C programs, but I'm pretty sure function
>>> calls cost a lot compared to a few direct instructions (e.g.
>>> isIntegerObject).
>>>
>>> Levente
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160417/415b5e60/attachment.htm


More information about the Vm-dev mailing list