all-in-one build

[tczene]

Hi, I've made an all-in-one build for jerryscript. With this method we can reach smaller binary size.
You can see the details below. If you want to try it you can download it from here: https://github.com/tczene/jerryscript/tree/all_in_one
This patch is only an example, not ready yet.
Do you think this is a good idea? Should I continue it?

original build:

size -A build/bin/release.mcu_stm32f4-cp/jerry
build/bin/release.mcu_stm32f4-cp/jerry :

section	size	addr
.isr_vector	392	134217728
.text	153220	134218120
.ARM	8	134371340
.init_array	4	134371348
.data	296	536870912
.bss	21952	536871232
._user_heap_stack	1024	536893184
.ARM.attributes	55	0
.debug_info	869597	0
.debug_abbrev	40949	0
.debug_loc	559999	0
.debug_aranges	1128	0
.debug_ranges	81976	0
.debug_line	115396	0
.debug_str	110440	0
.comment	112	0
.debug_frame	18700	0
Total	1975248

ls -lh build/bin/release.mcu_stm32f4-cp/jerry
2.0M build/bin/release.mcu_stm32f4-cp/jerry

ls -lh build/bin/release.mcu_stm32f4-cp/jerry.bin
151K build/bin/release.mcu_stm32f4-cp/jerry.bin

all-in-one build:

size -A build/bin/release.mcu_stm32f4-cp/jerry
build/bin/release.mcu_stm32f4-cp/jerry :

section	size	addr
.isr_vector	392	134217728
.text	150632	134218120
.ARM	8	134368752
.init_array	4	134368760
.data	260	536870912
.bss	19968	536871232
._user_heap_stack	1024	536891200
.ARM.attributes	55	0
.debug_info	791910	0
.debug_abbrev	47869	0
.debug_loc	515231	0
.debug_aranges	1112	0
.debug_ranges	81784	0
.debug_line	118910	0
.debug_str	111149	0
.comment	112	0
.debug_frame	17232	0
Total	1857652

ls -lh build/bin/release.mcu_stm32f4-cp/jerry
1.9M build/bin/release.mcu_stm32f4-cp/jerry

ls -lh build/bin/release.mcu_stm32f4-cp/jerry.bin
148K build/bin/release.mcu_stm32f4-cp/jerry.bin

[zherczeg]

Looks promising

[bzsolt]

Hi, I've tried the all-in-one Jerry build under IoT.js for NuttX.
I've ran sunspider tests on STM32F4 board (snapshot-dev), you can see the runtimes below:

Test	Original(sec)	All-in-one(sec)	Gain(%)
access-binary-trees.js	114	28	75.44
access-fannkuch.js	632	113	82.12
access-nbody.js	279	52	81.36
bitops-3bit-bits-in-byte.js	222	43	80.63
bitops-bits-in-byte.js	328	55	83.23
bitops-bitwise-and.js	246	64	73.98
math-cordic.js	317	52	83.60
math-partial-sums.js	211	73	65.40
math-spectral-norm.js	180	35	80.56
string-fasta.js	522	235	54.98

What do you think?
What will be the best way to use this? Should we create a build option or it will be the default?

[ruben-ayrapetyan]

@bzsolt, could you, please, clarify whether measurements from the first column were acquired on a LTO-enabled build?

[bzsolt]

Unfortunately we can't compile IoT.js with enabled LTO for NuttX yet.

[ruben-ayrapetyan]

@bzsolt, I see. Thank you.

[egavrin]

Great results!
Please compare Jerry w/ LTO vs Jerry w/o LTO vs Jerry w/ All-In-One on RPi2

[bzsolt]

Runtime comparison on RPi2 (140982e).

Test	Jerry with LTO (sec)	Jerry without LTO (sec)	Jerry (with LTO) all-in-one (sec)	Jerry (without LTO) all-in-one (sec)
3d-cube.js	3.76	21.62	3.84	3.92
access-binary-trees.js	1.92	8.42	1.93	2.01
access-fannkuch.js	9.83	59.76	9.88	10.07
access-nbody.js	4.55	26.41	4.57	4.82
bitops-3bit-bits-in-byte.js	2.68	18.86	2.73	2.73
bitops-bits-in-byte.js	3.73	28.86	3.87	3.83
bitops-bitwise-and.js	4.31	21.20	4.17	4.39
controlflow-recursive.js	1.73	10.29	1.78	1.82
crypto-aes.js	6.11	23.88	6.16	6.33
crypto-md5.js	35.75	52.57	36.87	35.81
crypto-sha1.js	15.55	28.83	15.86	15.46
date-format-tofte.js	4.02	14.68	4.05	4.17
date-format-xparb.js	2.11	6.23	2.14	2.27
math-cordic.js	4.02	28.82	4.13	4.20
math-partial-sums.js	2.34	12.17	2.31	2.47
math-spectral-norm.js	2.26	15.29	2.34	2.35
string-base64.js	239.28	310.77	246.02	240.17
string-fasta.js	5.86	19.02	5.87	6.19

[egavrin]

The last column stands for Jerry with LTO=OFF and all-in-one build, am I
right?

On Mon, Nov 16, 2015, 18:54 bzsolt notifications@github.com wrote:

Runtime comparison on RPi2 (140982e).
Test Jerry with LTO (sec) Jerry without LTO (sec) Jerry (with LTO)
all-in-one (sec) 3d-cube.js 3.76 21.62 3.84 access-binary-trees.js 1.92
8.42 1.93 access-fannkuch.js 9.83 59.76 9.88 access-nbody.js 4.55 26.41
4.57 bitops-3bit-bits-in-byte.js 2.68 18.86 2.73 bitops-bits-in-byte.js
3.73 28.86 3.87 bitops-bitwise-and.js 4.31 21.20 4.17
controlflow-recursive.js 1.73 10.29 1.78 crypto-aes.js 6.11 23.88 6.16
crypto-md5.js 35.75 52.57 36.87 crypto-sha1.js 15.55 28.83 15.86
date-format-tofte.js 4.02 14.68 4.05 date-format-xparb.js 2.11 6.23 2.14
math-cordic.js 4.02 28.82 4.13 math-partial-sums.js 2.34 12.17 2.31
math-spectral-norm.js 2.26 15.29 2.34 string-base64.js 239.28 310.77
246.02 string-fasta.js 5.86 19.02 5.87

—
Reply to this email directly or view it on GitHub
#626 (comment)
.

[bzsolt]

@egavrin The last column stands for Jerry all-in-one with enabled LTO, as described in table header.
I've completed the table with non-LTO all-in-one results.

[egavrin]

Hmm, suprising results.

[zherczeg]

The primary motivation of the all-in-one build is the LTO does not always work. For example it causes a link time error on Nuttx. Nuttix compiles everything into a single binary, and it seems inline assembly parts does not work with LTO. Without LTO the performance of IoT.js on STM32 is poor. I don't think we have any other choice than moving to all-in-one build, which is compatible with all exotic environments (OS, compiler, etc.).

[lemmaa]

@bzsolt , Could you shared the stripped binary size of each builds?

[bzsolt]

Of course, they are here:

	Jerry with LTO	Jerry without LTO	Jerry (with LTO) all-in-one	Jerry (without LTO) all-in-one
Binary sizes (bytes)	202 436	227 776	199 592	228 976