forums.silverfrost.com Forum Index forums.silverfrost.com
Welcome to the Silverfrost forums
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

New Topic "NET"
Goto page 1, 2, 3, 4  Next
 
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions
View previous topic :: View next topic  
Author Message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu Apr 25, 2013 12:48 pm    Post subject: New Topic "NET" Reply with quote

...should be added to this forum main topics.

Here is the question: can anyone elaborate what this examples in the create_thread1@ demonstrates ? The specific functionality i am looking for is that when i launch N threads all of them wait until they finish before continuing. Is this what create_thread1@ is made for?

Code:
EXTERNAL foo
ASSEMBLY_EXTERNAL(NAME="System.Threading.Thread.Join") T_JOIN
OBJECT("System.Threading.Thread") NEW_THREAD
CALL CREATE_THREAD1@(foo,42,NEW_THREAD)
!Do some processing...
CALL T_JOIN(NEW_THREAD)
PRINT*,'Finishing main program.'
END

SUBROUTINE foo(m)
INTEGER m
PRINT*,'In foo ',m
END
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Fri Apr 26, 2013 9:55 pm    Post subject: Reply with quote

By the way the #1 question for NET: I know how to compile simple program for NET with just one line. For example compiling some simple code produces running exe file

> ftn95 parallel4a.f95 /clr /link /multi_threaded

All done behind the scene and automatically. But how to initially compile and then link such programs in two steps using command prompt if the code has many subroutines? Can i compile NET specific part separately from x86? Or all must be made in just one or another platform?

When i compile the way we do in x86 mode

ftn95 parallel4a.f95 /clr /multi_threaded

i get the obj files for NET usual x86 linker does not understand
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Sat Apr 27, 2013 8:29 am    Post subject: Reply with quote

create_thread1@ returns immediately. The executable will run until the main process is terminated. My guess is that, terminating the main process will terminate any associated threads.

Normally (e.g. C#) .NET has a compilation stage but no linking stage but FTN95 is different. To overcome the problem of using Fortran in a garbage collecting environment, FTN95 has a "linker" that locks down the Fortran memory usage. No doubt there will be problems if you try to use either FTN95 or DBK_LINKx other than on an x86 "machine".
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sat Apr 27, 2013 1:53 pm    Post subject: Reply with quote

Thanks. My approach at this stage when i do not know all the pitfalls of NET is to apply NET multithreading parallelism in small subprograms called by the main large x86 code as a postprocessors without rebuilding the main code to be NET too (if possible).

On small testbeds parallelization using just the FTN95 NET capabilities alone looks very simple and promising, so there is no reason to jump to other NET or parallel compilers to get that. Using multi-language programming is dangerous step for code support and development (if that's not Microsoft and Intel compilers) and there must be very compelling reasons for that, i do not see any, FTN95 is completely capable of parallel computations.

To illustrate what i have and what is intended to be accomplished, imagine that the x86 code produces outputs of arrays A(i), B(i), C(i) etc (say, temperatures, densities etc as a function of coordinate) while the postptocessing NET program will use these A,B,C to make some other quantity (say, the X-ray spectrum) and work on all CPU cores. Ideally NET postprocessor can get all the A,B,C data via common block or module. Because all A,B,C are known the parallelization should be straightforward.

Of course making NET parallel postporocessor as a separate program is in principle possible but not desirable (using CISSUE etc)

So is it possible to mix x86 and NET this way? Any suggestions on compilation of x86+NET and linking together, ideally via command line compilation, will be appreciated.

Also, Paul, please consider adding "NET" to the forum's major topics!
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Sun Apr 28, 2013 11:22 pm    Post subject: Reply with quote

Am i right that the only way this could be potentially done is via wrapping NET part into DLL and call it from x86 code? And if i will use in the NET part of the code some modules created in X86 part of the code (instead of exchanging data between x86 and NET old way via common blocks) this will not work too because NET compiler does not understand modules from x86 which means that the whole code must be compiled in NET
Back to top
View user's profile Send private message
jalih



Joined: 30 Jul 2012
Posts: 196

PostPosted: Mon Apr 29, 2013 6:47 pm    Post subject: Re: Reply with quote

DanRRight wrote:
Am i right that the only way this could be potentially done is via wrapping NET part into DLL and call it from x86 code?

I think it would be more straightforward to Forget .NET and use win32 api directly. I tried to use CreateThread() function from FTN95, but always got zero as return value. Maybe Paul could help with this one?

Anyway, I ended up using a simple DLL-wrapper for win32 api multithreading functions. With some quick tests, all seems to be working fine.

Example project available here
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Mon Apr 29, 2013 8:04 pm    Post subject: Reply with quote

CREATE_THREAD@ and CREATE_THREAD1@ are for .NET only.

I cannot see any documented FTN95 Win32 thread functions.
There is an undocumented SPAWN@ that calls CreateThread but I would have to experiment with it to see how it works.

As observed, you can call CreateThread directly. You will find it in win32api.ins.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Mon Apr 29, 2013 10:15 pm    Post subject: Reply with quote

Thanks, Paul. Do you mean directly - without NET? That would be very very very interesting because i am not sure i will succeed rebuilding to NET large code versus just small demo. Any example for usage or the suggestions what are the arguments here

STDCALL CREATETHREAD 'CreateThread' (REF,VAL,REF,REF,VAL,REF) &
&:INTEGER*4

Or how about making subroutine CREATE_THREAD_x86@ not for NET ?

I used SPAWN with DOS FTN77 20 years ago, but there it crashed a lot ( everything was unstable at DOS times including DOS itself). I still see these lines in the code though they are dead and are commented out.

CALL SPAWN@ (EXIT_TO_DOS_MULTITASK2,STACK,40000L,istack)

Windows is much more stable now, and SPAWN might work. But I do not see SPAWN@ in the Help though.

Also while i am still trying to get through the forest and recompile the whole code for NET (it is very tempting to get almost an order of magnitude speedup on real code) i will share my experience for those who are interested, this may save your time in future:
- NET linker dbk_link2 does not recognize third party LIB files (used for parallel algebra... i have zero hope the developer will recompile it for NET).
- Now i see why developers mostly use INCLUDE <clearwin.ins> and not USE CLRWIN or USE MSWIN. Usual x86 modules will not work under NET.
- Bad news is that /3gb option is not recognized.
- NET linker is more strict which is good because it found me few errors of argument type mismatch or calling real*8 function as real*4.
- Compilation stopped with weird error "Array is too large" pointing on variable which was even not an array. Spreading and shuffling subroutines around - and the error disappears.
- And this is my final point after two days of rebuilding:
[DBK_LINK Ver. 2.0.0 ] *** Internal Linker Error....
Decreased all arrays to almost zero but this did not help. So that's a shutdown for today, will see what tomorrow brings.
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Tue Apr 30, 2013 6:48 am    Post subject: Reply with quote

By "directly" I meant by calling into the Microsoft Windows API using CreateThread etc. To do this you can Google "MSDN CreateThread" and work out how to pass the arguments. Jalih reports above that he has done this but I have not tried this approach myself. You can also access the same Windows API libraries via C# and this is essentially what CREATE_THREAD@ does for you.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Tue Apr 30, 2013 6:12 pm    Post subject: Reply with quote

jalih, thanks for the idea. I compiled it (one of two works) but after modifying it like in the last test in the other thread

http://forums.silverfrost.com/viewtopic.php?t=2534

don't seem code waits properly threads end. Can you reproduce this exactly test?


Last edited by DanRRight on Sat May 04, 2013 5:46 am; edited 7 times in total
Back to top
View user's profile Send private message
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed May 01, 2013 4:20 pm    Post subject: Reply with quote

By the way have anyone tried the approach of using normal x86 FTN95 compiler while wrapping multithreading part into DLL using NET? That approach should have some advantages over complete NET approach like option for /3GB, it is more stable and well checked by orders of magnitude more users. Here could be other pitfalls but right now that looks like another simple way dealing with the threads within this compiler. FTN95 should accept NET DLL like it is doing with DLLs created by many other third party compilers. I have tried this approach but because my NET experience is near zero level i still have not succeeded.

Here what i have done, all 100% are in front of you. I created file the text of which is below called parallel_NET_DLL.f95 which 100% works under NET and compiled it this way for NET
C:> ftn95 parallel_NET_DLL.f95 /clr /multi_threaded

It contains function Parallel_NET_DLL which starts threads. The analog of OBJ file for NET compiler produces is called parallel_NET_DLL.dbk

Code:
!
  integer function Parallel_NET_DLL ()
  include <clearwin.ins>
  EXTERNAL runN
  parameter (nThrMax=80)
  common /threads_/nEmployedThreads, kThreadEnded(nThrMax)


1 print*,' Enter number of parallel threads < 8'
  read(*,*)   nEmployedThreads
!  if(nEmployedThreads.lt.1.or.nEmployedThreads.gt.8) nEmployedThreads=4

  call clock@ (time_start)

!...set a flag of thread finished
  kThreadEnded(:)=1

  do i = 1, nEmployedThreads
     CALL CREATE_THREAD@(runN,20+i)
     call sleep1@(0.02)
  enddo

!...wait till all threads finish
  do while (minval(kThreadEnded)==0)
    call sleep1@(0.1)
  enddo

  call clock@ (time_finish)

  time = time_finish-time_start
  time2= time * nEmployedThreads
  print*, 'Elapsed time, total CPU time=', time, time2

  goto 1
  Parallel_NET_DLL = 1
  END function

! =====================================================================
  subroutine runN (iThrHandle)
  include <clearwin.ins>
  parameter (nThrMax=80)
  common /threads_/nEmployedThreads, kThreadEnded(nThrMax)

  ithr = iThrHandle-20
  lock;   print*,'Started thread # ', ithr ; end lock
  d      =2.22
  kThreadEnded(ithr) = 0
  do i=1,200000000/nEmployedThreads
    d=alog(exp(d))
  enddo
  lock;     print*, 'Ended   thread # ', ithr  ;     end lock
  kThreadEnded(ithr)=1
  end


Then i made DLL out of it this way
C:>dbk_link2 /multi_threaded parallel_NET_DLL.dll parallel_NET_DLL.dbk

Then i created main program file for regular x86 mode which just calls this function Parallel_NET_DLL and compiled it usual way
C:> ftn95 parallelDLLmain.f95

Code:
  integer  Parallel_NET_DLL
  external Parallel_NET_DLL
  jj   =   Parallel_NET_DLL()
  print*, 'done'
  end


At the end i linked OBJ and DLL using regular SLINK
C:> SLINK parallelDLLmain.obj parallel_NET_DLL.dll

Here is BAT file if you named files as i did above
Code:
ftn95 parallel_NET_DLL.f95 /clr /multi_threaded >zftn95NET
dbk_link2 /multi_threaded parallel_NET_DLL.dll parallel_NET_DLL.dbk >zlinkNET
ftn95 parallelDLLmain.f95 >zftn95x86
SLINK parallelDLLmain.obj parallel_NET_DLL.dll >zlinkx86


I got the error that SLINK does not find the function parallel_NET_DLL. Last thing i expected is such message which means that NET DLL is not recognized. Even compiling everything for NET by taking proper dbk_link2 instead of SLINK has the same problem. What's wrong ? Linker for NET has the problem creating readable DLL or i made some mistake somewhere?
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Wed May 01, 2013 7:57 pm    Post subject: Reply with quote

SLINK cannot link object files or DLLs compiled for .NET.

Use FTN95 (without /clr) with SLINK.
Use FTN95 (with /clr) with DBK_LINKx.
Use DLLs that match with the executable in this sense.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Wed May 01, 2013 9:01 pm    Post subject: Reply with quote

But as i wrote NET DLL does not match even with own DBK_LINK if we substitute SLINK with it! Or i am doing something wrong?

And if SLINK can not link NET DLL -- that is very pity. Why it is that? It can connect with DLLs from bunch of obscure third party compilers while can not even *start* the own NET program. Since this thread is in Suggestions i'd appreciate if developers investigate if launching of own NET DLLs from x86 could be potentially possible. That is specifically important to me since i can not get through to the end using NET with our large code, the compiler freaks out, linker gives up without much diagnostics, all reminds me stability of FTN90/95 around 15 years ago. More years and more users need to polish NET compiler. And needless to say that everyone will win from that. FTN95 for NET has excellent multithreading capabilities as a way for parallel calculations
Back to top
View user's profile Send private message
PaulLaidler
Site Admin


Joined: 21 Feb 2005
Posts: 7916
Location: Salford, UK

PostPosted: Thu May 02, 2013 8:14 am    Post subject: Reply with quote

I don't think that DLLs can be used as input on a DBK_LINKx command line.
Try using DBK_LINKx without the DLL input.

Remember that DBK_LINKx is only a psuedo linker. Normally .NET does not have a linker. Everything is automatically linked at load time. So presumably DBK_LINKx only needs the .dbk files.

SLINK cannot be made to link .NET DLL assemblies. In this case it is not a question of time or resources. It cannot be done.
Back to top
View user's profile Send private message AIM Address
DanRRight



Joined: 10 Mar 2008
Posts: 2813
Location: South Pole, Antarctica

PostPosted: Thu May 02, 2013 11:00 pm    Post subject: Reply with quote

Well, all that may sound OK to CS department folks but for others it sounds a bit perpendicular to their experience and expectations from the new language. It definitely does not encourage scientists and engineers to learn and use NET. I'd say, exactly opposite, it screams to avoid it as the multilanguage programming is always not a plus for maintainability and usability of the large codes. NET looks like a dead language which became dead among the groups using Fortran by not reaching critical mass of acceptance. And its functionality is too restrictive. I feel now that probably the devotion of resources to build the NET instead of 64bit and OpenMP/CUDA capabilities was a mistake of developers of this compiler, because former does not while latter do lie on the mainstream of computers/languages evolution. Why did i use NET, did i need it? Not at all, i needed multithreading to parallelize the code. On tiny test code NET worked, on large it failed. And without large users base there will be no chance that NET will be not a dead buggy extension of this compiler. So pity because all started to great...

So what other options are left? WinAPI...
Back to top
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic    forums.silverfrost.com Forum Index -> Suggestions All times are GMT + 1 Hour
Goto page 1, 2, 3, 4  Next
Page 1 of 4

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group