public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* GAS
@ 2005-04-04 14:51 Stas Kiselev
  0 siblings, 0 replies; 8+ messages in thread
From: Stas Kiselev @ 2005-04-04 14:51 UTC (permalink / raw)
  To: binutils

Hello,

   I use AS for generating object files where time is
critical.
I mean I have to speed up gas as much as possible. As for
input I give AS
very big .asm files with size more than 200mb. so it works
very slow. I
tried to cut input file to several small .asm files - AS
became work more
faster but in general AS work very slow. How can I speed up
it ? What kind
of weak points can I find and fix ?

P.S. Where can I get whole description of AS architecture?
for instance I have
descriptinon for lcc compilator - "A retargetable C
compiler: design and implementation"

Thank you, Stanislav

^ permalink raw reply	[flat|nested] 8+ messages in thread
* Re[2]: GAS
  2005-04-14  9:00 ` GAS Nick Clifton
@ 2005-04-14  9:11 Stas Kiselev
  2005-04-15 10:48 ` GAS Nick Clifton
  -1 siblings, 1 reply; 8+ messages in thread
From: Stas Kiselev @ 2005-04-14  9:11 UTC (permalink / raw)
  To: Nick Clifton; +Cc: Zagorodnev, Grigory, binutils

Hi Nick,
Ok, I have already solved problems with hash. Now I am working with reading .asn
and writing .obj strategies. What can be changed in order to reduce time ?


P.S. What a dataflow of GAS ?

Thank you, Stanislav

> 
> Hi Griogry,
> 
> > Also there is a little problem with the patch: new command line option
> > has no affect on symbol table and local symbol table hashes because
> > routine parse_args gets called after symbol_begin in "as.c", where these
> > hashes allocated. 
> 
> Ah - good point.  There was also a small problem with non-BFD assemblers 
> in that the patch used the bfd_size_type.  Therefore I am applying the 
> attached patch to fix both of these problems.
> 
> I checked - moving the parse_args before the symbol_begin does not 
> appear to have any adverse effects.
> 
> Cheers
>    Nick
> 
> gas/ChangeLog
> 2005-04-14  Nick Clifton  <nickc@redhat.com>
> 
> 	* as.c (main): Move parse_args before symbol_begin and frag_init
> 	so that the hash table size can be set before it is used.
> 	* hash.c: Use an unsigned long type for the size of the hash
> 	tables.
> 	* hash.h (set_gas_hash_table_size): Update the prototype.	
> 
> 
> 
> 
> 
> Index: gas/as.c
> ===================================================================
> RCS file: /cvs/src/src/gas/as.c,v
> retrieving revision 1.59
> diff -c -3 -p -r1.59 as.c
> *** gas/as.c	12 Apr 2005 08:42:38 -0000	1.59
> --- gas/as.c	14 Apr 2005 08:56:36 -0000
> *************** the GNU General Public License.  This pr
> *** 885,891 ****
>   
>   	case OPTION_HASH_TABLE_SIZE:
>   	  {
> ! 	    bfd_size_type new_size;
>   
>               new_size = strtoul (optarg, NULL, 0);
>               if (new_size)
> --- 885,891 ----
>   
>   	case OPTION_HASH_TABLE_SIZE:
>   	  {
> ! 	    unsigned long new_size;
>   
>               new_size = strtoul (optarg, NULL, 0);
>               if (new_size)
> *************** main (int argc, char ** argv)
> *** 1114,1123 ****
>   #endif
>   
>     PROGRESS (1);
>     symbol_begin ();
>     frag_init ();
>     subsegs_begin ();
> -   parse_args (&argc, &argv);
>     read_begin ();
>     input_scrub_begin ();
>     expr_begin ();
> --- 1114,1125 ----
>   #endif
>   
>     PROGRESS (1);
> +   /* Call parse_args before any of the init/begin functions
> +      so that switches like --hash-size can be honored.  */
> +   parse_args (&argc, &argv);
>     symbol_begin ();
>     frag_init ();
>     subsegs_begin ();
>     read_begin ();
>     input_scrub_begin ();
>     expr_begin ();
> Index: gas/hash.c
> ===================================================================
> RCS file: /cvs/src/src/gas/hash.c,v
> retrieving revision 1.14
> diff -c -3 -p -r1.14 hash.c
> *** gas/hash.c	12 Apr 2005 08:42:38 -0000	1.14
> --- gas/hash.c	14 Apr 2005 08:56:36 -0000
> *************** struct hash_control {
> *** 73,92 ****
>      switch --reduce-memory-overheads, or set to other values by using
>      the --hash-size=<NUMBER> switch.  */
>   
> ! static unsigned int gas_hash_table_size = 65537;
>   
>   void
> ! set_gas_hash_table_size (unsigned int size)
>   {
>     gas_hash_table_size = size;
>   }
>   
>   /* FIXME: This function should be amalgmated with bfd/hash.c:bfd_hash_set_default_size().  */
> ! static unsigned int
>   get_gas_hash_table_size (void)
>   {
>     /* Extend this prime list if you want more granularity of hash table size.  */
> !   static const unsigned int hash_size_primes[] =
>       {
>         1021, 4051, 8599, 16699, 65537
>       };
> --- 73,92 ----
>      switch --reduce-memory-overheads, or set to other values by using
>      the --hash-size=<NUMBER> switch.  */
>   
> ! static unsigned long gas_hash_table_size = 65537;
>   
>   void
> ! set_gas_hash_table_size (unsigned long size)
>   {
>     gas_hash_table_size = size;
>   }
>   
>   /* FIXME: This function should be amalgmated with bfd/hash.c:bfd_hash_set_default_size().  */
> ! static unsigned long
>   get_gas_hash_table_size (void)
>   {
>     /* Extend this prime list if you want more granularity of hash table size.  */
> !   static const unsigned long hash_size_primes[] =
>       {
>         1021, 4051, 8599, 16699, 65537
>       };
> *************** get_gas_hash_table_size (void)
> *** 107,115 ****
>   struct hash_control *
>   hash_new (void)
>   {
> !   unsigned int size;
>     struct hash_control *ret;
> -   unsigned int alloc;
>   
>     size = get_gas_hash_table_size ();
>   
> --- 107,115 ----
>   struct hash_control *
>   hash_new (void)
>   {
> !   unsigned long size;
> !   unsigned long alloc;
>     struct hash_control *ret;
>   
>     size = get_gas_hash_table_size ();
>   
> Index: gas/hash.h
> ===================================================================
> RCS file: /cvs/src/src/gas/hash.h,v
> retrieving revision 1.7
> diff -c -3 -p -r1.7 hash.h
> *** gas/hash.h	12 Apr 2005 08:42:38 -0000	1.7
> --- gas/hash.h	14 Apr 2005 08:56:36 -0000
> *************** struct hash_control;
> *** 26,32 ****
>   
>   /* Set the size of the hash table used.  */
>   
> ! void set_gas_hash_table_size (unsigned int);
>   
>   /* Create a hash table.  This return a control block.  */
>   
> --- 26,32 ----
>   
>   /* Set the size of the hash table used.  */
>   
> ! void set_gas_hash_table_size (unsigned long);
>   
>   /* Create a hash table.  This return a control block.  */
>   
> 
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: GAS
@ 2005-04-12 13:53 Zagorodnev, Grigory
  2005-04-14  9:00 ` GAS Nick Clifton
  0 siblings, 1 reply; 8+ messages in thread
From: Zagorodnev, Grigory @ 2005-04-12 13:53 UTC (permalink / raw)
  To: Nick Clifton; +Cc: Stas Kiselev, binutils

Hi, Nick!
Hash statistics says that increasing the size we really reduce average
chain length and number of hash comparisons. However I was not able to
measure any comptime change on 1.3MB of x86 assembly source code.
Hopefully bigger sources will expose the gain. Therefore we may keep
default hash size value unchanged.

Also there is a little problem with the patch: new command line option
has no affect on symbol table and local symbol table hashes because
routine parse_args gets called after symbol_begin in "as.c", where these
hashes allocated. 

Best regards!
- Grigory

>-----Original Message-----
>From: Nick Clifton [mailto:nickc@redhat.com]
>Sent: Wednesday, April 06, 2005 3:15 PM
>To: Zagorodnev, Grigory
>Cc: Stas Kiselev; binutils@sources.redhat.com
>Subject: Re: GAS
>
>Hi Grigory,
>
>> Similar issue was reported against 'ld' 1.5 years ago. Simple change
of
>> default hash size from 4K to 64K gave 2x link time improvement.
>> http://lists.gnu.org/archive/html/bug-gnu-utils/2003-08/msg00153.html
>>
>> Thus the patch may look like this:
>>
>> $ diff gas/hash.c.org gas/hash.c
>>
>> 38c38
>> < #define DEFAULT_SIZE (4051)
>> ---
>>>#define DEFAULT_SIZE (65537)
>
>We might as well do this properly.  Please could you try the attached
>patch which as well as changing the default hash size adds two new
>switches: --hash-size=<NUMBER> and --reduce-memory-overheads which
>behave in much the same way as their linker namesakes.
>
>If the patch works for you and there are no objections then I will
apply
>it next week.
>
>Cheers
>   Nick
>
>gas/ChangeLog
>
>2005-04-06  Nick Clifton  <nickc@redhat.com>
>
>	* hash.c (DEFAULT_SIZE): Delete.  Replace with:
>	(gas_hash_table_size): New static variable.
>	(set_gas_hash_table_size): New function:  Records a requested
size
>	for the hash tables.
>	(get_gas_hash_table_size): New function: Return a prime number
>	near the requested size of the hash table.
>	(hash_new): Use get_gas_hash_table_size.
>	* hash.h: Add a prototype for set_gas_hash_table_size.
>	* as.c (show_usage): Add description of new switches:
--hash-size
>	and --reduce-memory-overheads.
>	(option_values): Add OPTION_HASH_TABLE_SIZE and
>	OPTION_REDUCE_MEMORY_OVERHEADS.
>	(std_longpopts): Add entries for the new options.
>	(parse_args): Handle the new options.
>	* Makefile.am: Add a dependency of as.c on hash.h.
>	* Makefile.in: Regenerate.
>	* doc/as.texinfo: Document the new switches.
>	* NEWS: Mention the new switches.

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: Re[2]: GAS
@ 2005-04-05  7:52 Zagorodnev, Grigory
  2005-04-06 11:17 ` GAS Nick Clifton
  0 siblings, 1 reply; 8+ messages in thread
From: Zagorodnev, Grigory @ 2005-04-05  7:52 UTC (permalink / raw)
  To: Stas Kiselev, binutils

>The idea is: huge input file implies huge symbol tables, that results
>more hash function collisions. Thus increasing the DEFAULT_SIZE of hash
>we can reduce the number of collisions and therefore speedup execution.
>Stas, would you try this on your sources, please?

Similar issue was reported against 'ld' 1.5 years ago. Simple change of
default hash size from 4K to 64K gave 2x link time improvement.
http://lists.gnu.org/archive/html/bug-gnu-utils/2003-08/msg00153.html

Thus the patch may look like this:

$ diff gas/hash.c.org gas/hash.c

38c38
< #define DEFAULT_SIZE (4051)
---
> #define DEFAULT_SIZE (65537)


- Grigory

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: GAS
@ 2005-04-04 16:03 Zagorodnev, Grigory
  0 siblings, 0 replies; 8+ messages in thread
From: Zagorodnev, Grigory @ 2005-04-04 16:03 UTC (permalink / raw)
  To: Stas Kiselev, binutils

Stas,
Have you tried profiling gas to expose hotspots? 200mb of (plain?) code
seems to be good material for this.

---
Grigory Zagorodnev
Intel Corporation

>-----Original Message-----
>From: binutils-owner@sources.redhat.com [mailto:binutils-
>owner@sources.redhat.com] On Behalf Of Stas Kiselev
>Sent: Monday, April 04, 2005 6:52 PM
>To: binutils@sources.redhat.com
>Subject: GAS
>
>Hello,
>
>   I use AS for generating object files where time is
>critical.
>I mean I have to speed up gas as much as possible. As for
>input I give AS
>very big .asm files with size more than 200mb. so it works
>very slow. I
>tried to cut input file to several small .asm files - AS
>became work more
>faster but in general AS work very slow. How can I speed up
>it ? What kind
>of weak points can I find and fix ?
>
>P.S. Where can I get whole description of AS architecture?
>for instance I have
>descriptinon for lcc compilator - "A retargetable C
>compiler: design and implementation"
>
>Thank you, Stanislav

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: GAS
@ 2004-05-05 14:09 Arun Vishwanathan
  0 siblings, 0 replies; 8+ messages in thread
From: Arun Vishwanathan @ 2004-05-05 14:09 UTC (permalink / raw)
  To: Bill Cunningham, binutils


No universal assembly language format. But it should not be difficult
to adapt to syntaxes once you learn one format. Intel one is probably
simpler so you can start with that. 

This maybe a good links to start with if you are programming on Linux.
http://linuxassembly.org/
http://www.tldp.org/HOWTO/Assembly-HOWTO/

Regards,
-------------------------------------------------------------
"Only two things are infinite, the universe and human stupidity;
and i am not sure about the former" 
					-Albert Einstein
-------------------------------------------------------------
Arun Vishwanathan 
 


> -----Original Message-----
> From: binutils-owner@sources.redhat.com [mailto:binutils-
> owner@sources.redhat.com] On Behalf Of Bill Cunningham
> Sent: Wednesday, May 05, 2004 7:19 PM
> To: binutils@sources.redhat.com
> Subject: GAS
> 
>     I all I just signed up to this list and I've been wanting to learn
> assembly as well as C. The GAS assembly format is what I want to learn
and
> Intel's IA-32 assembly language format. Is assembly language syntax
> different, or is there a universal assembly format I should learn?
> 
>     Bill
> 

^ permalink raw reply	[flat|nested] 8+ messages in thread
* GAS
@ 2004-05-05 13:49 Bill Cunningham
  0 siblings, 0 replies; 8+ messages in thread
From: Bill Cunningham @ 2004-05-05 13:49 UTC (permalink / raw)
  To: binutils

    I all I just signed up to this list and I've been wanting to learn
assembly as well as C. The GAS assembly format is what I want to learn and
Intel's IA-32 assembly language format. Is assembly language syntax
different, or is there a universal assembly format I should learn?

    Bill


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2005-04-15 10:48 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-04 14:51 GAS Stas Kiselev
  -- strict thread matches above, loose matches on Subject: below --
2005-04-14  9:11 Re[2]: GAS Stas Kiselev
2005-04-15 10:48 ` GAS Nick Clifton
2005-04-12 13:53 GAS Zagorodnev, Grigory
2005-04-14  9:00 ` GAS Nick Clifton
2005-04-05  7:52 Re[2]: GAS Zagorodnev, Grigory
2005-04-06 11:17 ` GAS Nick Clifton
2005-04-04 16:03 GAS Zagorodnev, Grigory
2004-05-05 14:09 GAS Arun Vishwanathan
2004-05-05 13:49 GAS Bill Cunningham

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).