Re: R: GOBACK (was: Perform Thru/Go to vs. Perform - Compile Speed

From: Robert Wagner (robert.deletethis_at_wagner.net)
Date: 05/25/04 

Date: Tue, 25 May 2004 09:22:20 GMT

riplin@Azonic.co.nz (Richard) wrote:

>robert.deletethis@wagner.net (Robert Wagner) wrote
>
>> >So, you haven't demonstrated it scaling past a handful of 'paragraphs'
>> >in a toy program using a single compiler on just one platform.
>>
>> The generated code for CALL/GOBACK is nearly identical to PERFORM/return. I
>> don't see how scaling could be an issue.
>
>There may be a lot of things that you don't see. These may only
>become visible when it is actually tried in a large scale environment.

I saw that today. The code for calling is not a problem, but the code for
_receiving_ a call is.

>> Every thread requires at least one ENTRY or callable program. Converting an
>> existing Cobol program to run paragraphs in parallel requires changing at
least
>> one paragraph name to ENTRY, or breaking the program into smaller ones.
>
>So you do agree that your claim of 'Changing EVERY paragraph' was
>wrong.

It was a trial baloon. You and WK disliked it; others were silent.

>> The result is an ugly (IMO) jumble of paragraph names and ENTRY. You can see
>> what it looks like in the multithreading demo I just posted.
>
>'Ugly' is subjective. Some see all lower case as 'ugly'. Some see
>your style of full stops as 'ugly'. You seem to think that your
>standards of what is 'ugly' and what is 'beautiful' should be
>universal.

Drat. My proclivity to be a control freak has been exposed.

>I had already assumed that you hadn't actually written a Windows GUI
>API program. It was obvious from your messages.

I spent a year doing Accenture FCP (Foundation Control Program), which received
messges via callbacks.

>> There you go .. you're an old hand with multithreading.
>
>Thank you for realising that I do actually have enough of a background
>to know what I am talking about.

I never questioned your knowledge. You question mine all the time, including
areas where it should be obvious I've been. For instance, I say I wrote an OO
operating system and you talk as though I'm an OO neophyte.
 
>> Suppose the
>> file-io programs are compiled REENTRANT(2), which gives separate buffers and
>> FCBs per thread, whereas all other programs are compiled REENTRANT(1). Under
>> that scenario, it's not necessary to lock FDs.
>
>So now you are not only requiring that it be done exclusively in MF,
>but in a particular very recent version of MF that they must buy in
>order to bend to your will.

All compilers will have the equivalent of reentrant(2), where every thread is
sealed up, not sharing memory with other threads. I'm not positive they have
reentrant(1), which is true multithreading.

>> >> I haven't written OO Cobol because I don't have an OO compiler at home.
>> >> They're too expensive.
>
>But you are advocating things which require REENTRANT(n). Are these
>cheaper ? Do you have one ?

Fair comment. No, I don't have it at home but do at work. I looked at its OO
features yesterday afternoon, found the syntax easy to understand. Methods are
just nested programs. My next demo will be OO.

>> One step at a time. If I advocate OO AND multithreading, 'traditional' Cobol
>> programmers' eyes will glaze over.
>
>At least OO is modern and useful and adding multithreading to OO is
>better than your 'how assembler did it in the 60s' with hand coded
>locks (which even you acknowledge as being flakey).

I didn't say they were flaky. They're leak-proof and the ONLY way to get
expected performance. If you have to call thread functions such as mutex, you're
better off single-threaded.

>> It will seem like a new language to them.
>> Multithreading is something they could do _today_, even retrofit into
existing
>> programs, using familiar syntax and requiring only a few lines of change.
>
>You really don't get it do you. You have demonstrated that
>multi-threading is _slower_ on single CPUs and uses more machine
>resources, even when using your flakey mechanism. The reason that
>there is 50% CPU free is probably because the disk IO is the limiting
>factor. What does increasing the task numbers do to the system
>thruput ? Almost nothing when these just make the IO queue longer.

You're trying to solve today's problems with solutions you developed in the '80s
and early '90s, when programmers had to hold the machine's hand and alter their
style to cope with its inadequacies. Those days are gone. Machines now have 16G
of real memory and gobs of on-ship cache.

When I do a Cobol compilation for the first time, it takes about a second. When
I do subsequent compilations, they take milliseconds. The whole compiler is in a
cache.

>Locking is only required for _external_ data items. Ones that can be
>accessed by more than one thread. In your use of ENTRY _everything_
>in W-S is 'external' and potentially needs locking. Local-Storage is
>not external, but cannot survive EXIT PROGRAM so data must be saved in
>W-S between CALLs.

Correct, working-storage is 'shared memory'. Updates to it must be locked unless
they are thread-specific.

That's the best way to communicate between parallel threads. It's a lot faster
than IPC memory.

>RENTRANT(2) appears to create a new create a new instance of Data
>Division for each thread, which is exactly what would happen if an
>instance of an object were created for each thread. This means that
>locking only need be done for data that is really EXTERNAL.

Sounds like the thread managers you've used made every thread reentrant(2).
That's a wasteful solution

>> No high-rise building has ever collapsed as the result of fire,
>
>Typical lame consiracy theorist claim.
>
>No high-rise ever had that many tons of avgas dumped into them.

Avgas is 100 octane gasoline for reciprocating engines. Jet fuel is kerosene.

A fire's temperature doesn't increase because of fuel quantity. It does only in
the movies.

>Building have collapsed because of fire, steel frame building have
>collapsed because of fire.

Name two.

Relevant Pages

  • Re: interpreter vs. compiled
    ... a memory address to successive integers 0..9, ... Is there a reason why you're expecting c.l.p to be your personal tutor ... for Introduction to Compilers? ... Defining your own terms that don't ...
    (comp.lang.python)
  • Re: question about negative indices in fortran 77
    ... > Intel compilers for linux), but now I'm doing some modifications and I ... > subroutine where it isn't touched. ... out memory in the order arrays are declared. ...
    (comp.lang.fortran)
  • Re: If you were inventing CoBOL...
    ... > IBM mainframe culture, and compilers that mimic IBM's memory model. ... That's not what memory management is for. ...
    (comp.lang.cobol)
  • Re: C++ sucks for games
    ... Few, if any, compilers offer completely safe modes. ... Lisp programming is much more visual. ... >> objects around to make manual memory management manageable. ... Few programmers use the auto keyword in declarations because all ...
    (comp.lang.cpp)
  • Re: C++ sucks for games
    ... Few, if any, compilers offer completely safe modes. ... Lisp programming is much more visual. ... >> objects around to make manual memory management manageable. ... Few programmers use the auto keyword in declarations because all ...
    (comp.lang.lisp)