Skip to content

Commit ed78407

Browse files
msharovmsharov
committed
Update web page with current build requirements
1 parent fc0a86b commit ed78407

File tree

1 file changed

+64
-80
lines changed

1 file changed

+64
-80
lines changed

‎docs/index.html‎

Lines changed: 64 additions & 80 deletions
Original file line numberDiff line numberDiff line change
@@ -62,20 +62,17 @@ <h2><a name="Installation">Installation</a></h2>
6262
<p>
6363
To start with you'll need a decent compiler. Although uSTL will compile
6464
under gcc 2.95, some features require at least gcc 3.4 and are simply
65-
turned off with an older version. C++ support is vastly improved in
66-
the recent compiler versions, and I strongly recommend gcc 4 for best
67-
possible code.
65+
turned off with an older version. The minimum requirement to enable
66+
C++11 features is gcc 4.6 or clang 3.2.
6867
</p><p>
6968
The latest version of uSTL can always be downloaded from its SourceForge
70-
<a href="https://sourceforge.net/project/showfiles.php?group_id=76798">project files page</a>.
69+
<a href="https://sourceforge.net/projects/ustl/files/">project files page</a>.
7170
If you like living dangerously, you can pull the working branch directly from
72-
<a href="http://ustl.git.sourceforge.net/git/gitweb.cgi?p=ustl">git://ustl.git.sourceforge.net/gitroot/ustl/ustl</a>.
73-
The mainline source should build on any unix-based system, including Linux,
74-
BSD, MacOS, SunOS, and Solaris. A separate port for Symbian OS is maintained by
75-
<a href="http://www.penrillian.com/index.php?option=com_content&amp;task=view&amp;id=82&amp;Itemid=73">Penrillian</a>.
76-
Windows-based systems and weird embedded platforms, are not, and will
77-
not be supported by the mainline. However, if you make a port, I'll be
78-
happy to mention it here. After unpacking:
71+
<a href="https://sourceforge.net/p/ustl/code/?branch=ref%2Fmaster">git://git.code.sf.net/p/ustl/code</a>.
72+
The mainline source should build on any unix-based system, including
73+
Linux, BSD, MacOS, SunOS, and Solaris. Windows-based systems and embedded
74+
platforms, are not, and will not be supported by the mainline. However,
75+
if you make a port, I'll be happy to mention it here. After unpacking:
7976
</p><pre>
8077
./configure
8178
make install
@@ -122,7 +119,7 @@ <h2><a name="Containers">Containers and Iterators</a></h2>
122119
</p><pre>
123120
vector&lt;int&gt; v;
124121
v.push_back (1);
125-
v.push_back (2);
122+
v.emplace_back (2);
126123
v[1] = 0;
127124
v.erase (v.begin() + 1);
128125
v.pop_back();
@@ -328,7 +325,7 @@ <h2><a name="Algorithms">Algorithms</a></h2>
328325
considering that the above fifteen line example can be written as a
329326
three line iterative foreach loop. Finally, there is the problem of
330327
where to put the functor. It just doesn't seem to "belong" anywhere in
331-
the object-oriented world. (C++0x changes that somewhat with lambda
328+
the object-oriented world. (C++11 changes that somewhat with lambda
332329
functions) Sorry, Stepanov, I just don't see how these things can be
333330
anything but an ugly, bloated hindrance.
334331
</p>
@@ -609,107 +606,94 @@ <h2><a name="Savings">Template Bloat Be Gone</a></h2>
609606
return (EXIT_SUCCESS);
610607
}
611608
</pre><p>
612-
Feel free to compile it and see for yourself. I'm compiling on a Core
613-
i7 with gcc 4.5.2 and <kbd>-Os -DNDEBUG=1</kbd>. The libstdc++ version
614-
is linked implicitly with it, and uSTL version is linked with gcc
609+
Feel free to compile it and see for yourself. I'm compiling on a Core i7
610+
with gcc 4.7.2 and <kbd>-Os -DNDEBUG=1 -march=native</kbd>. The libstdc++
611+
version is linked implicitly with it, and uSTL version is linked with gcc
615612
(instead of g++) and <kbd>-lustl</kbd>. Both executables are stripped.
616613
The libstdc++ version looks like this:
617614
</p><pre>
618615
% ls -l std/tes
619-
7096 tes
616+
6896 tes
620617
% size std/tes
621618
text data bss dec hex filename
622-
3780 632 16 4428 114c std/tes
619+
3522 656 8 4186 105a std/tes
623620
% size -A std/tes.o
624-
std/tes.o :
621+
std/tes.o:
625622
section size
626623
.group 8
627624
.group 8
628625
.group 8
629626
.group 8
630627
.group 8
631-
.group 8
632-
.group 8
633-
.group 8
634-
.group 8
635-
.group 8
636-
.group 8
637-
.text 256
628+
.text 11
638629
.data 0
639630
.bss 0
640-
.text._ZNSt6vectorIiSaIiEED2Ev 8
641-
.text._ZNKSt6vectorIiSaIiEE12_M_check_lenEmPKc 68
642-
.text._ZNSt11__copy_moveILb0ELb1ESt26random_access_iterator_tagE8__copy_mIiEEPT_PKS3_S6_S4_ 51
643-
.text._ZSt14__copy_move_a2ILb0EN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEES6_ET1_T0_S8_S7_ 14
644-
.text._ZSt4copyIN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEES6_ET0_T_S8_S7_ 14
645-
.text._ZNSt20__copy_move_backwardILb0ELb1ESt26random_access_iterator_tagE13__copy_move_bIiEEPT_PKS3_S6_S4_ 63
631+
.text._ZNKSt6vectorIiSaIiEE12_M_check_lenEmPKc 61
632+
.text._ZNSt11__copy_moveILb0ELb1ESt26random_access_iterator_tagE8__copy_mIiEEPT_PKS3_S6_S4_ 45
633+
.text._ZNSt20__copy_move_backwardILb0ELb1ESt26random_access_iterator_tagE13__copy_move_bIiEEPT_PKS3_S6_S4_ 58
646634
.rodata.str1.1 45
647-
.text._ZNSt6vectorIiSaIiEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPiS1_EEmRKi 355
648-
.text._ZNSt6vectorIiSaIiEE6resizeEmi 64
649-
.text._ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi 195
650-
.text._ZNSt6vectorIiSaIiEE9push_backERKi 46
651-
.text._ZNSt6vectorIiSaIiEE6insertEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi 79
652-
.gcc_except_table 14
653-
.comment 40
635+
.text._ZNSt6vectorIiSaIiEE14_M_fill_insertEN9__gnu_cxx17__normal_iteratorIPiS1_EEmRKi 386
636+
.text._ZNSt6vectorIiSaIiEE13_M_insert_auxEN9__gnu_cxx17__normal_iteratorIPiS1_EERKi 232
637+
.text.startup 294
638+
.gcc_except_table 20
639+
.comment 18
654640
.note.GNU-stack 0
655-
.eh_frame 576
656-
Total 1976
641+
.eh_frame 368
642+
Total 1578
657643
</pre><p>
658644
The uSTL version looks like this:
659645
</p><pre>
660646
% ls -l ustl/tes
661-
5720 tes
647+
5704 tes
662648
% size ustl/tes
663649
text data bss dec hex filename
664-
2435 616 16 3067 bfb ustl/tes
650+
2383 640 8 3031 bd7 ustl/tes
665651
% size -A ustl/tes.o
666-
ustl/tes.o :
667-
section size addr
668-
.text 327 0
669-
.data 0 0
670-
.bss 0 0
671-
.gcc_except_table 19 0
672-
.comment 40 0
673-
.note.GNU-stack 0 0
674-
.eh_frame 88 0
675-
Total 474
652+
ustl/tes.o:
653+
section size
654+
.text 0
655+
.data 0
656+
.bss 0
657+
.text.startup 277
658+
.gcc_except_table 19
659+
.comment 18
660+
.note.GNU-stack 0
661+
.eh_frame 72
662+
Total 386
676663
</pre><p>
677-
Let's see what's going on here. The .text size in the std version is
678-
smaller, indicating less inlined functionality. This version of gcc
679-
libstdc++ instantiates additional eleven functions totalling 953 bytes
680-
just for this one vector type. These functions will become larger for
681-
containers with objects, but about 1k in savings that you see as the
682-
difference in execuable size is a good measure. The uSTL version inlines
683-
everything and calls memblock functions instead.
684-
</p><p>
685-
1k doesn't seem like much, but consider that you get it for <em>every
686-
type of container you instantiate</em>! An int vector here, a float
687-
vector here, a bunch of object containers there, and before you know it
688-
you are using half your executable just for container overhead.
664+
As you can see, the libstdc++ version instantiates quite a bit of code
665+
for just this one vector type, with out-of-line functions for copy, move,
666+
insert, and fill. Because uSTL aggregates memory management into a single
667+
location (the memblock class), all of those calls can be efficiently
668+
forwarded there, saving about a kilobyte of code. 1k doesn't seem like
669+
much, but consider that you get it for <em>every type of container you
670+
instantiate</em>! An int vector here, a float vector here, a bunch of
671+
object containers there, and before you know it you are using half your
672+
executable just for container overhead.
689673
</p><p>
690674
But wait, there is more! Let's look at the total memory footprint:
691675
</p><pre>
692676
% footprint std/tes
693677
text data bss dec hex filename
694-
3780 632 16 4428 114c tes
695-
84445 928 632 86005 14ff5 libgcc_s.so.1
696-
527390 720 72 528182 80f36 libm.so.6
697-
962481 34816 84664 1081961 108269 libstdc++.so.6
698-
1404487 18024 20032 1442543 1602ef libc.so.6
699-
2982583 55120 105416 3143119 2ff5cf (TOTALS)
678+
3522 656 8 4186 105a tes
679+
83357 968 664 84989 14bfd libgcc_s.so.1
680+
1031819 1100 72 1032991 fc31f libm.so.6
681+
935489 36200 85088 1056777 102009 libstdc++.so.6
682+
1715642 20560 17800 1754002 1ac392 libc.so.6
683+
3769829 59484 103632 3932945 3c0311 (TOTALS)
700684

701685
% footprint ustl/tes
702686
text data bss dec hex filename
703-
2435 616 16 3067 bfb tes
704-
84445 928 632 86005 14ff5 libgcc_s.so.1
705-
152800 10408 73248 236456 39ba8 libustl.so.1.5
706-
1404487 18024 20032 1442543 1602ef libc.so.6
707-
1644167 29976 93928 1768071 1afa87 (TOTALS)
687+
2383 640 8 3031 bd7 tes
688+
83357 968 664 84989 14bfd libgcc_s.so.1
689+
151398 10848 73240 235486 397de libustl.so.2
690+
1715642 20560 17800 1754002 1ac392 libc.so.6
691+
1952780 33016 91712 2077508 1fb344 (TOTALS)
708692
</pre><p>
709-
As you can see, the footprint for the uSTL version is 44% smaller,
710-
saving 1375048 bytes. If you don't count libc, measuring only the
711-
C++-specific overhead, libstdc++ loads 1696148 while libustl only 322461,
712-
<em>five times less</em>! Finally, most of uSTL's size comes from gcc's
693+
As you can see, the footprint for the uSTL version is 47% smaller,
694+
saving 1855437 bytes. If you don't count libc, measuring only the
695+
C++-specific overhead, libstdc++ loads 2178943 while libustl only 323506,
696+
<em>seven times less</em>! Finally, most of uSTL's size comes from gcc's
713697
support libraries; if you compile uSTL configured <kbd>--with-libstdc++</kbd>
714698
option, then you'll see that it only takes up 72322 bytes, of which only
715699
23350 are used by .text, meaning that only about a third of the library

0 commit comments

Comments
 (0)