Thread overview | |||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
July 30, 2002 Linker | ||||
---|---|---|---|---|
| ||||
Does anyone know how to make a linker different than OPTLINK work with DMC? Thanks Federico |
July 30, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Federico | "Federico" <Federico_member@pathlink.com> wrote in message news:ai6u1h$13c6$1@digitaldaemon.com... > Does anyone know how to make a linker different than OPTLINK work with DMC? > Thanks > Federico Any linker that works with standard omf files should work. |
July 31, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | In article <ai76ug$1i17$2@digitaldaemon.com>, Walter says... > >Any linker that works with standard omf files should work. > I tried Borland Tlink 5.0, Blinker 5.1 and Alink 1.6. Each one complains or aborts with an error. Any idea? Federico |
July 31, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Federico | "Federico" <Federico_member@pathlink.com> wrote in message news:ai82eo$304b$1@digitaldaemon.com... > In article <ai76ug$1i17$2@digitaldaemon.com>, Walter says... > >Any linker that works with standard omf files should work. > I tried Borland Tlink 5.0, Blinker 5.1 and Alink 1.6. Each one complains or > aborts with an error. If optlink links the code successfully, I don't understand what the problem is. Optlink is far and away the best linker ever written. |
July 31, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | In article <ai84un$2s6$1@digitaldaemon.com>, Walter says... > >If optlink links the code successfully, I don't understand what the problem is. Optlink is far and away the best linker ever written. > I agree, but it fails as soon as the data declared at file scope exceed 40 MB total. As you maybe remember, we had this discussion a few months ago: DMC produces very fast executables, better then any competitor. However, if I use dynamic memory allocation, speed degrades by 30 percent. Still better than other compilers using dynamic allocation, but worse than other compiler on huge static data. I'm trying to find a way out of the problem. BTW. If I declare the big arrays 'static', Blinker does not complain anymore on the .obj, but has problems with SNN.LIB. The same happens with Borland Tlink. Any clue? Federico |
July 31, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Federico | "Federico" <Federico_member@pathlink.com> wrote in message news:ai9mrp$22dq$1@digitaldaemon.com... > I agree, but it fails as soon as the data declared at file scope exceed 40 MB > total. Ok, I remember now. > As you maybe remember, we had this discussion a few months ago: DMC produces > very fast executables, better then any competitor. However, if I use dynamic > memory allocation, speed degrades by 30 percent. Still better than other compilers using dynamic allocation, but worse than other compiler on huge static > data. > I'm trying to find a way out of the problem. > > BTW. If I declare the big arrays 'static', Blinker does not complain anymore on > the .obj, but has problems with SNN.LIB. The same happens with Borland Tlink. What problems with snn? |
August 01, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Federico | Federico schrieb...
> I agree, but it fails as soon as the data declared at file scope exceed 40 MB
> total.
> As you maybe remember, we had this discussion a few months ago: DMC produces
> very fast executables, better then any competitor. However, if I use dynamic
> memory allocation, speed degrades by 30 percent. Still better than other
> compilers using dynamic allocation, but worse than other compiler on huge static
> data.
> I'm trying to find a way out of the problem.
Why not allocating a big buffer on startup? It shouldn't make much difference in access time if you change
char big_buffer[big_size];
// doing something with big_buffer
to
char *big_buffer = new char[big_size]; // or malloc
// doing somthing with big_buffer
There is only one dynamic memory allocation in this case. The rest is nearly the same. Ok, the static buffer can be accessed with immediate addresses where the dynamic buffer pointer must first be loaded to a register and offset addressed. But I would expect that this isn't a big performance degradation.
- Heinz
|
August 01, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Heinz Saathoff | In article <MPG.17b2f9f4a1b121699896ae@news.digitalmars.com>, Heinz Saathoff says... >Why not allocating a big buffer on startup? It shouldn't make much difference in access time if you change Sorry, it does. I was able to reduce the problem to a simple and stupid matrix multiplication of two NxN matrices into a third one (the original code is different and much more sophisticated, but exhibits the very same pathology). Please, look at those measures (dynamic means that memory is allocated once at the very beginning): N Allocation DMC 8.28 BC++ 5.5 500 static 2.45 s 2.70 s 500 dynamic 3.17 s 3.67 s 2000 static link failed! 141.13 s 2000 dynamic 166.31 s 196.81 s Not only is DMC better than other compiler in most respects (support of accurate floating point computation is wonderful), it produces faster executables too. However, performance degradations resulting from the switch from static to dynamic memory allocation are significant (actually deadly for my application). >nearly the same. Ok, the static buffer can be accessed with immediate addresses where the dynamic buffer pointer must first be loaded to a register and offset addressed. But I would expect that this isn't a big performance degradation. No, this is not a problem. There is not much difference between accessing memory locations in an array and accessing memory locations in a malloc'ed area, not with a barely decent optimizing compiler. I can prove that easily, it is even more evident on RISC architectures and the progressive RISC-ification of x86 processors made this true for them as well. I had not time to look in detail to DMC generated assembler, but the one for the computational core is much more verbose and lenghty for the dinamic allocation version than for the static one. This usually comes from the optimizer being more aggressive with static data, as it can more easily check at compile time for aliasing problems, something cannot be done easily for dynamically allocated areas and pointers to them. With FORTRAN 77, which always assume no aliasing (if you don't use EQUIVALENCE, of course), there is no difference if you pass to a subroutine a static data area or a malloc'ed one. In FORTRAN 9X, which supports pointers, aliasing can be an issue, and performance can degrades. In FORTRAN 9X you can fine control the effect using the TARGET attribute (if the compiler takes advantage of the information), C99 introduced the restrict keyword with similar purposes, and using it can pay a lot with some compilers. To my surprise, using __restrict with DMC had no effect. Federico |
August 01, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Walter | In article <ai9qud$27he$1@digitaldaemon.com>, Walter says... > >What problems with snn? > Please, find below outputs of Alink, Blinker, Tlink. The latter gives no information, but the problem happens as soon as SNN.LIB is accessed. Moreover, if the big arrays at file scope are not declared static, both alink and blinker complains on the .obj generated from my source code. Maybe I'm stuck in a stupid problem, I apologize but I'm not an expert in linking under Win32. Federico -----------------Alink------------------------------ e:\eee\ramspeed\qq>alink -oPE -subsys con rs.obj USER32.LIB KERNEL32.LIB ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams. All Rights Reserved Loading file rs.obj Loading file USER32.LIB Loading file KERNEL32.LIB Loading file SNN.lib Error in file at 000000EE - unknown object module record type BC name count = 19 seg count = 8 extcount=10 grpcount=2 comcount=4 fixcount=18 impcount=0 expcount=0 e:\eee\ramspeed\qq> --------------------Blinker----------------------------- e:\eee\ramspeed\qq>blinker file rs.obj lib user32.lib lib kernel32.lib BLINKER : 1115 : SNN.LIB(BUILDENV) : '__IMP__MULTIBYTETOWIDECHAR@24' : unresolved external BLINKER : 1115 : SNN.LIB(CLOCK) : '__IMP__GETTICKCOUNT@0' : unresolved external BLINKER : 1115 : SNN.LIB(GETENV) : '__IMP__GETENVIRONMENTVARIABLEA@12' : unresolved external BLINKER : 1115 : SNN.LIB(ISATTY) : '__IMP__GETFILETYPE@4' : unresolved external BLINKER : 1115 : SNN.LIB(LOCTIME) : '__IMP__GETTIMEZONEINFORMATION@4' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CLOSEHANDLE@4' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CREATESEMAPHOREA@16' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__WAITFORSINGLEOBJECT@8' : unresolved external BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__RELEASESEMAPHORE@12' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETACP@0' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETOEMCP@0' : unresolved external BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETCPINFO@8' : unresolved external BLINKER : 1115 : SNN.LIB(SETNTERR) : '__IMP__GETLASTERROR@0' : unresolved external BLINKER : 1115 : SNN.LIB(TIME) : '__IMP__GETLOCALTIME@4' : unresolved external BLINKER : 1115 : SNN.LIB(TOLOWER) : '__IMP__LCMAPSTRINGA@24' : unresolved external BLINKER : 1115 : SNN.LIB(XCFILTER) : '__IMP__UNHANDLEDEXCEPTIONFILTER@4' : unresolved external BLINKER : 1115 : SNN.LIB(WCTOMB) : '__IMP__WIDECHARTOMULTIBYTE@32' : unresolved external BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALALLOC@16' : unresolved external BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALFREE@12' : unresolved external BLINKER : 1115 : SNN.LIB(ISCTYPE) : '__IMP__GETSTRINGTYPEA@20' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGW@24' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGA@24' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOW@16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOA@16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETSTRINGTYPEW@16' : unresolved external BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__LCMAPSTRINGW@24' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDNEXTFILEA@8' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDCLOSE@4' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FILETIMETODOSDATETIME@12' : unresolved external BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDFIRSTFILEA@8' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETSTDHANDLE@4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__CREATEFILEA@28' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__MOVEFILEA@8' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__DELETEFILEA@4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETHANDLECOUNT@4' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETFILEPOINTER@16' : unresolved external BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETFILEATTRIBUTESA@4' : unresolved external BLINKER : 1115 : SNN.LIB(SETARGV) : '__IMP__GETMODULEFILENAMEA@12' : unresolved external BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__WRITECONSOLEA@20' : unresolved external BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__MESSAGEBOXA@16' : unresolved external BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETMODULEHANDLEA@4' : unresolved external BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETCOMMANDLINEA@0' : unresolved external BLINKER : 0 Warning error(s), 42 Fatal error(s) RS.EXE (not created) (0.1 seconds) e:\eee\ramspeed\qq> -----------------------Tlink------------------------ e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib\ rs.obj,,,user32.lib+kernel32.lib Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Warning: Unable to perform incremental link - performing full link... Fatal: Unable to open file 'SNN.OBJ' e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib rs.obj,,,snn.lib+user32.lib+kernel32.lib Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland Fatal: Error detected (IMP1807) Fatal: Access violation. Link terminated. Warning: Unable to perform incremental link - performing full link... Fatal: Error detected (IMP1807) Fatal: Access violation. Link terminated. e:\eee\ramspeed\qq> |
August 01, 2002 Re: Linker | ||||
---|---|---|---|---|
| ||||
Posted in reply to Federico | What about the DM Linker???
It seems to me like you have to throw an option for blinker to prevent it from capitalizing the function names, that might fix one problem.
Jan
Federico wrote:
> In article <ai9qud$27he$1@digitaldaemon.com>, Walter says...
> >
> >What problems with snn?
> >
>
> Please, find below outputs of Alink, Blinker, Tlink. The latter gives no information, but the problem happens as soon as SNN.LIB is accessed.
>
> Moreover, if the big arrays at file scope are not declared static, both alink and blinker complains on the .obj generated from my source code.
>
> Maybe I'm stuck in a stupid problem, I apologize but I'm not an expert in linking under Win32.
>
> Federico
>
> -----------------Alink------------------------------
>
> e:\eee\ramspeed\qq>alink -oPE -subsys con rs.obj USER32.LIB KERNEL32.LIB ALINK v1.6 (C) Copyright 1998-9 Anthony A.J. Williams.
>
> All Rights Reserved
>
> Loading file rs.obj
>
> Loading file USER32.LIB
>
> Loading file KERNEL32.LIB
>
> Loading file SNN.lib
>
> Error in file at 000000EE - unknown object module record type BC
>
> name count = 19
>
> seg count = 8
>
> extcount=10
>
> grpcount=2
>
> comcount=4
>
> fixcount=18
>
> impcount=0
>
> expcount=0
>
> e:\eee\ramspeed\qq>
>
> --------------------Blinker-----------------------------
>
> e:\eee\ramspeed\qq>blinker file rs.obj lib user32.lib lib kernel32.lib
>
> BLINKER : 1115 : SNN.LIB(BUILDENV) : '__IMP__MULTIBYTETOWIDECHAR@24' :
> unresolved external
> BLINKER : 1115 : SNN.LIB(CLOCK) : '__IMP__GETTICKCOUNT@0' : unresolved external
> BLINKER : 1115 : SNN.LIB(GETENV) : '__IMP__GETENVIRONMENTVARIABLEA@12' :
> unresolved external
> BLINKER : 1115 : SNN.LIB(ISATTY) : '__IMP__GETFILETYPE@4' : unresolved external
> BLINKER : 1115 : SNN.LIB(LOCTIME) : '__IMP__GETTIMEZONEINFORMATION@4' :
> unresolved external
> BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CLOSEHANDLE@4' : unresolved external
> BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__CREATESEMAPHOREA@16' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__WAITFORSINGLEOBJECT@8' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(SEMLOCK) : '__IMP__RELEASESEMAPHORE@12' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETACP@0' : unresolved external
> BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETOEMCP@0' : unresolved external
> BLINKER : 1115 : SNN.LIB(SETMBCP) : '__IMP__GETCPINFO@8' : unresolved external
> BLINKER : 1115 : SNN.LIB(SETNTERR) : '__IMP__GETLASTERROR@0' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(TIME) : '__IMP__GETLOCALTIME@4' : unresolved external
> BLINKER : 1115 : SNN.LIB(TOLOWER) : '__IMP__LCMAPSTRINGA@24' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(XCFILTER) : '__IMP__UNHANDLEDEXCEPTIONFILTER@4' :
> unresolved external
> BLINKER : 1115 : SNN.LIB(WCTOMB) : '__IMP__WIDECHARTOMULTIBYTE@32' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALALLOC@16' : unresolved external
> BLINKER : 1115 : SNN.LIB(SBRK) : '__IMP__VIRTUALFREE@12' : unresolved external
> BLINKER : 1115 : SNN.LIB(ISCTYPE) : '__IMP__GETSTRINGTYPEA@20' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGW@24' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__COMPARESTRINGA@24' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOW@16' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETLOCALEINFOA@16' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__GETSTRINGTYPEW@16' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(LCAPI32) : '__IMP__LCMAPSTRINGW@24' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDNEXTFILEA@8' : unresolved external
> BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDCLOSE@4' : unresolved external
> BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FILETIMETODOSDATETIME@12' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(FIND) : '__IMP__FINDFIRSTFILEA@8' : unresolved external
> BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETSTDHANDLE@4' : unresolved external
> BLINKER : 1115 : SNN.LIB(IO) : '__IMP__CREATEFILEA@28' : unresolved external
> BLINKER : 1115 : SNN.LIB(IO) : '__IMP__MOVEFILEA@8' : unresolved external
> BLINKER : 1115 : SNN.LIB(IO) : '__IMP__DELETEFILEA@4' : unresolved external
> BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETHANDLECOUNT@4' : unresolved external
> BLINKER : 1115 : SNN.LIB(IO) : '__IMP__SETFILEPOINTER@16' : unresolved external
> BLINKER : 1115 : SNN.LIB(IO) : '__IMP__GETFILEATTRIBUTESA@4' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(SETARGV) : '__IMP__GETMODULEFILENAMEA@12' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__WRITECONSOLEA@20' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(W32FATER) : '__IMP__MESSAGEBOXA@16' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETMODULEHANDLEA@4' : unresolved
> external
> BLINKER : 1115 : SNN.LIB(CONSTART) : '__IMP__GETCOMMANDLINEA@0' : unresolved
> external
>
> BLINKER : 0 Warning error(s), 42 Fatal error(s)
>
> RS.EXE (not created) (0.1 seconds)
>
> e:\eee\ramspeed\qq>
>
> -----------------------Tlink------------------------
>
> e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib\
> rs.obj,,,user32.lib+kernel32.lib
> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
>
> Warning: Unable to perform incremental link - performing full link...
>
> Fatal: Unable to open file 'SNN.OBJ'
>
> e:\eee\ramspeed\qq>ilink32 -Lc:\progra~1\dm\lib
> rs.obj,,,snn.lib+user32.lib+kernel32.lib
> Turbo Incremental Link 5.00 Copyright (c) 1997, 2000 Borland
>
> Fatal: Error detected (IMP1807)
>
> Fatal: Access violation. Link terminated.
>
> Warning: Unable to perform incremental link - performing full link...
>
> Fatal: Error detected (IMP1807)
>
> Fatal: Access violation. Link terminated.
>
> e:\eee\ramspeed\qq>
|
Copyright © 1999-2021 by the D Language Foundation