Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #58701 > unrolled thread

gforth and shared libraries

Back to article view | Back to comp.lang.forth

Contents

  gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-05 17:01 +0200
    Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-05 17:44 +0200
      Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-06 16:24 +0000
        Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-07 10:48 +0200
          Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-07 10:03 +0000
            Re: gforth and shared libraries albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 13:40 +0200
            Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-07 22:27 +0200
              Re: gforth and shared libraries Bernd Paysan <bernd@net2o.de> - 2017-05-07 23:57 +0000
                Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 10:44 +0200
                  Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-08 11:26 +0000
                    Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 17:08 +0200
              Re: gforth and shared libraries pahihu <pahihu@gmail.com> - 2017-05-09 10:31 -0700
                Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-10 09:40 +0200
          Re: gforth and shared libraries albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-07 13:37 +0200
            Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-07 22:50 +0200
              Re: gforth and shared libraries minforth@arcor.de - 2017-05-07 14:41 -0700
                Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 10:49 +0200
                  Re: gforth and shared libraries minforth@arcor.de - 2017-05-08 02:16 -0700
                    Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 16:32 +0200
                      Re: gforth and shared libraries minforth@arcor.de - 2017-05-08 08:00 -0700
                        Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-08 17:52 +0200
                          Re: gforth and shared libraries minforth@arcor.de - 2017-05-08 09:33 -0700
                          Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-09 15:44 +0000
                            Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-10 09:51 +0200
                              Re: gforth and shared libraries anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-05-10 10:16 +0000
                                Re: gforth and shared libraries Andreas Klimas <klimas@w3group.de> - 2017-05-10 12:31 +0200
                                Re: gforth and shared libraries albert@cherry.spenarnc.xs4all.nl (Albert van der Horst) - 2017-05-10 12:51 +0200

Page 2 of 2 — ← Prev page 1 [2]

#58844

On 2017-05-08 15:00:06 +0000, minforth@arcor.de said:

> Am Montag, 8. Mai 2017 16:32:08 UTC+2 schrieb Andreas Klimas:
>> On 2017-05-08 09:16:03 +0000, minforth@arcor.de said:
>> 
>>> Am Montag, 8. Mai 2017 10:49:27 UTC+2 schrieb Andreas Klimas:
>>>>>> 
>>>>>> Or am I doing wrong if I want to access all the 64 Gigs of RAM
>>>>>> of our server with forth ?
>>>>>> 
>>>>> 
>>>>> I would say that might be true when you have to handle data objects
>>>>> persistently in memory of about > 3 gigs size. If not, 32 bits are
>>>>> sufficient for most applications. OTOH large image or video processing
>>>>> might benefit from 64 bit for good performance.
>>>>> 
>>>>> And most OS remap physical to virtual address ranges anyhow, so it is
>>>>> rather unusual to address the full physical address space.
>>>> 
>>>> the database is large, some billions records. but not all data is
>>>> used all the time, so partitioning could be possible. Is the effort
>>>> worth it ?
>>> 
>>> are you the sole user and admin on the server? no concurrent db access
>>> i.e. the db is "dormant"?
>> 
>> no, for sure not. I don't want to go to deep into detail here.
>> there are some databases and many users. And I'm not the
>> sysadmin. Data wil be synchronized in background to/from
>> Oracle server elswhere. The Software (written entirely in C)
>> is really fast, about 1000x faster than direct SQL Connect.
>> Now I want to show how far I can get with forth. Because
>> Forth is highly interactive productivity should be much better
>> then. I want to rewrite our GDV Parser (which is a simple
>> portable ASCII data format used by german insurance
>> companies for data exchange.
>> http://www.gdv-online.de/vuvm/ (german))
> 
> Okay, thanks for the insights. I'd be surprised if the parser needs
> direct access to the 64 gig physical memory address range, but it's just
> my wild guess into the blue.

oh, there some 100 billions of contracts inside the database
(which are all coming from GDV-files)
so the size is approx. 3G. to large for 32 Bit C application
and I guess too large for 32 Bit Forth either. Anyway, number
of contracts are growing, so we will reach the 4G soon.

splitting of the database would be possible and not that strange
I think. so here are my thoughts

1. Is a 32 bit forth running on a 64 bit linux without 32 bit support ?
(our sysadmin has anounced that they would see all apps running
in 64 Bit mode in the future, maybe we get some pressure in this
direction). I don't know because I have no access to a plain 64 Bit
linux now.

2. Is it worth the effort to keep databases small and with multi volumes
layout to keep 32 bit compatibility ? I don't know either. 32 bit sounds
more manageable then super large multi gig files

 

[toc] | [prev] | [next] | [standalone]

#58848

Am Montag, 8. Mai 2017 17:52:50 UTC+2 schrieb Andreas Klimas:
> On 2017-05-08 15:00:06 +0000, minforth@arcor.de said:
> 
> > Am Montag, 8. Mai 2017 16:32:08 UTC+2 schrieb Andreas Klimas:
> >> On 2017-05-08 09:16:03 +0000, minforth@arcor.de said:
> >> 
> >>> Am Montag, 8. Mai 2017 10:49:27 UTC+2 schrieb Andreas Klimas:
> >>>>>> 
> >>>>>> Or am I doing wrong if I want to access all the 64 Gigs of RAM
> >>>>>> of our server with forth ?
> >>>>>> 
> >>>>> 
> >>>>> I would say that might be true when you have to handle data objects
> >>>>> persistently in memory of about > 3 gigs size. If not, 32 bits are
> >>>>> sufficient for most applications. OTOH large image or video processing
> >>>>> might benefit from 64 bit for good performance.
> >>>>> 
> >>>>> And most OS remap physical to virtual address ranges anyhow, so it is
> >>>>> rather unusual to address the full physical address space.
> >>>> 
> >>>> the database is large, some billions records. but not all data is
> >>>> used all the time, so partitioning could be possible. Is the effort
> >>>> worth it ?
> >>> 
> >>> are you the sole user and admin on the server? no concurrent db access
> >>> i.e. the db is "dormant"?
> >> 
> >> no, for sure not. I don't want to go to deep into detail here.
> >> there are some databases and many users. And I'm not the
> >> sysadmin. Data wil be synchronized in background to/from
> >> Oracle server elswhere. The Software (written entirely in C)
> >> is really fast, about 1000x faster than direct SQL Connect.
> >> Now I want to show how far I can get with forth. Because
> >> Forth is highly interactive productivity should be much better
> >> then. I want to rewrite our GDV Parser (which is a simple
> >> portable ASCII data format used by german insurance
> >> companies for data exchange.
> >> http://www.gdv-online.de/vuvm/ (german))
> > 
> > Okay, thanks for the insights. I'd be surprised if the parser needs
> > direct access to the 64 gig physical memory address range, but it's just
> > my wild guess into the blue.
> 
> oh, there some 100 billions of contracts inside the database
> (which are all coming from GDV-files)
> so the size is approx. 3G. to large for 32 Bit C application
> and I guess too large for 32 Bit Forth either. Anyway, number
> of contracts are growing, so we will reach the 4G soon.
> 
> splitting of the database would be possible and not that strange
> I think. so here are my thoughts
> 
> 1. Is a 32 bit forth running on a 64 bit linux without 32 bit support ?
> (our sysadmin has anounced that they would see all apps running
> in 64 Bit mode in the future, maybe we get some pressure in this
> direction). I don't know because I have no access to a plain 64 Bit
> linux now.
> 
> 2. Is it worth the effort to keep databases small and with multi volumes
> layout to keep 32 bit compatibility ? I don't know either. 32 bit sounds
> more manageable then super large multi gig files

Prepare for the worst case.  ;-)

[toc] | [prev] | [next] | [standalone]

#58898

Andreas Klimas <klimas@w3group.de> writes:
>1. Is a 32 bit forth running on a 64 bit linux without 32 bit support ?

32bit applications need kernel support (usually there), and the 32-bit
libraries must be present (not by default).

But why would you use a 32-bit system?  We have fine 64-bit Forths
such as Gforth.

>2. Is it worth the effort to keep databases small and with multi volumes
>layout to keep 32 bit compatibility ? I don't know either. 32 bit sounds
>more manageable then super large multi gig files

You have to know for your application, but my feeling is that if your
data fits in your physical RAM, then sure, having it all in RAM (or at
least mapped in) is certainly an approach to be considered.  And don't
let the limitations of some Forth systems complicate your system design.

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#58937

On 2017-05-09 15:44:11 +0000, Anton Ertl said:

> Andreas Klimas <klimas@w3group.de> writes:
>> 1. Is a 32 bit forth running on a 64 bit linux without 32 bit support ?
> 
> 32bit applications need kernel support (usually there), and the 32-bit
> libraries must be present (not by default).
> 
> But why would you use a 32-bit system?  We have fine 64-bit Forths
> such as Gforth.

yes, gforth seems to be well suited .
the two most importend targets for my work are Linux and MacOS.
And it would be nice if Windows was also possible.

> 
>> 2. Is it worth the effort to keep databases small and with multi volumes
>> layout to keep 32 bit compatibility ? I don't know either. 32 bit sounds
>> more manageable then super large multi gig files
> 
> You have to know for your application, but my feeling is that if your
> data fits in your physical RAM, then sure, having it all in RAM (or at
> least mapped in) is certainly an approach to be considered.  And don't
> let the limitations of some Forth systems complicate your system design.

yes.
what I want to put in this group. 64 Bit seems useful only for Data,
not for code. So what I would have a 64 Bit datapointer.
Dictionary and Code could still remain 32 Bit. But this may be is
too complex, isnt it ?

- Andreas Klimas


> 
> - anton

[toc] | [prev] | [next] | [standalone]

#58957

Andreas Klimas <klimas@w3group.de> writes:
>On 2017-05-09 15:44:11 +0000, Anton Ertl said:
>yes, gforth seems to be well suited .
>the two most importend targets for my work are Linux and MacOS.
>And it would be nice if Windows was also possible.

Gforth also runs on Windows, and for some time, even in 64-bit:

https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth64.exe

>what I want to put in this group. 64 Bit seems useful only for Data,
>not for code. So what I would have a 64 Bit datapointer.
>Dictionary and Code could still remain 32 Bit. But this may be is
>too complex, isnt it ?

Existing 64-bit Forth systems support 64-bit xts and 64-bit return
addresses.  Limiting the code area to 4GB of address space is
possible, but has pitfalls.  And anyway, do you store so many code
pointers that you save a significant amount by compressing them to 32
bits?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2017: http://www.euroforth.org/ef17/

[toc] | [prev] | [next] | [standalone]

#58958

> 
>> what I want to put in this group. 64 Bit seems useful only for Data,
>> not for code. So what I would have a 64 Bit datapointer.
>> Dictionary and Code could still remain 32 Bit. But this may be is
>> too complex, isnt it ?
> 
> Existing 64-bit Forth systems support 64-bit xts and 64-bit return
> addresses.  Limiting the code area to 4GB of address space is
> possible, but has pitfalls.  And anyway, do you store so many code
> pointers that you save a significant amount by compressing them to 32
> bits?

you are right, there is no point.
In using gigs of data there is really no point in saving some k with 32 
bit code.

- Andreas

> 
> - anton

[toc] | [prev] | [next] | [standalone]

#58960

In article <2017May10.121651@mips.complang.tuwien.ac.at>,
Anton Ertl <anton@mips.complang.tuwien.ac.at> wrote:
>Andreas Klimas <klimas@w3group.de> writes:
>>On 2017-05-09 15:44:11 +0000, Anton Ertl said:
>>yes, gforth seems to be well suited .
>>the two most importend targets for my work are Linux and MacOS.
>>And it would be nice if Windows was also possible.
>
>Gforth also runs on Windows, and for some time, even in 64-bit:
>
>https://www.complang.tuwien.ac.at/forth/gforth/Snapshots/current/gforth64.exe
>
>>what I want to put in this group. 64 Bit seems useful only for Data,
>>not for code. So what I would have a 64 Bit datapointer.
>>Dictionary and Code could still remain 32 Bit. But this may be is
>>too complex, isnt it ?
>
>Existing 64-bit Forth systems support 64-bit xts and 64-bit return
>addresses.  Limiting the code area to 4GB of address space is
>possible, but has pitfalls.  And anyway, do you store so many code
>pointers that you save a significant amount by compressing them to 32
>bits?

4Gbyte is less than the available physical memory on modern systems.
That alone is sufficient reason to have 64-bit address pointers.

>
>- anton

Groetjes Albert
-- 
Albert van der Horst, UTRECHT,THE NETHERLANDS
Economic growth -- being exponential -- ultimately falters.
albert@spe&ar&c.xs4all.nl &=n http://home.hccnet.nl/a.w.m.van.der.horst

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.lang.forth

csiph-web