date:20161124

Re: [Factor-talk] TYPED: Declarations

2016-11-24 Thread John Benediktsson

You can learn a lot by using ``optimized.`` from ``compiler.tree.debugger``.

You can see it does convert the literal ``2`` to a float and then use
``float+``:

IN: scratchpad [ { float } declare 2 + 10 * ] optimized.
[ 2.0 float+ 10.0 float* ]

You can also look at the "typed" variation:

TYPED: plus1 ( a: float -- b: float )
{ float } declare 1 + ;

IN: scratchpad \ plus1 optimized.
[ >float ( typed plus1 ) ]

The float coercion goes away if the compiler knows that a float is on the
stack:

IN: scratchpad [ { float } declare plus1 ] optimized.
[ ( typed plus1 ) ]

But, the way "typed" works, is it defines an outer word that converts /
checks the inputs and then calls an inner word that assumes the inputs to
be the types specified.  You can right-click on ``( typed plus1 )`` and
then push it to the stack and call ``optimized.`` on it, or you can declare
it as inline (for the sake of introspection or otherwise):

TYPED: plus1 ( a: float -- b: float )
{ float } declare 1 + ; inline

IN: scratchpad \ plus1 optimized.
[ >float 1.0 float+ ]

If the input is a float, the coercion goes away also here:

IN: scratchpad [ { float } declare plus1 ] optimized.
[ 1.0 float+ ]

Hope that helps.

Best,
John.

P.S., I think 32-bit libudis86.dll exists somewhere, and I know 32-bit
libudis86 is supported on other OS's.

On Thu, Nov 24, 2016 at 1:45 PM, Alexander Ilin  wrote:

> Hello!
>
>   In the docs of the `declare` word it says:
>
> The optimizer cannot do anything with the below code:
> `2 + 10 *`
> However, if we declare that the top of the stack is a float, then type
> checks and generic dispatch are eliminated, and the compiler can use unsafe
> intrinsics:
> `{ float } declare 2 + 10 *`
>
>   I wanted to ask: does declaring the types of parameters using the TYPED:
> word have the same effect on the optimizer (with the difference, of course,
> that it actually adds the type tests as necessary) or not? In other words,
> do these two mechanisms play well together? Would it be beneficial or
> completely superfluous to do this:
>
> TYPED: +1 ( a: float -- b: float )
> { float } declare 1 + ;
>
>   PS: I'm asking here, because there still is no x86 variant of the
> libudis86.dll at the Factor FTP, there is only the x64 version.
>
> ---=---
>  Александр
>
> 
> --
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] TYPED: Declarations

2016-11-24 Thread Alexander Ilin

Hello!

  In the docs of the `declare` word it says:

The optimizer cannot do anything with the below code:
`2 + 10 *`
However, if we declare that the top of the stack is a float, then type checks 
and generic dispatch are eliminated, and the compiler can use unsafe intrinsics:
`{ float } declare 2 + 10 *`

  I wanted to ask: does declaring the types of parameters using the TYPED: word 
have the same effect on the optimizer (with the difference, of course, that it 
actually adds the type tests as necessary) or not? In other words, do these two 
mechanisms play well together? Would it be beneficial or completely superfluous 
to do this:

TYPED: +1 ( a: float -- b: float )
{ float } declare 1 + ;

  PS: I'm asking here, because there still is no x86 variant of the 
libudis86.dll at the Factor FTP, there is only the x64 version.

---=--- 
 Александр

--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Parsing Ratios

2016-11-24 Thread Jon Harper

Hi,
the code for parsing ratios is in https://github.com/factor/
factor/blob/master/core/math/parser/parser.factor
It's called by string>number (or base>)

see ->numerator ->denominator ?make-ratio ?add-ratio

Cheers,
Jon

On Thu, Nov 24, 2016 at 6:38 PM, Alexander Ilin  wrote:

> Hello!
>
>   Ideas of some custom parsing words still intrigues me.
>
>   Could someone tell me where is the code that parses ratios?
>
> ---=---
>  Александр
>
> 
> --
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

[Factor-talk] Parsing Ratios

2016-11-24 Thread Alexander Ilin

Hello!

  Ideas of some custom parsing words still intrigues me.

  Could someone tell me where is the code that parses ratios?

---=--- 
 Александр

--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] GC - No Bug (Was: Out Of Memory)

2016-11-24 Thread Alexander Ilin

Hello again! Thank you for the replies. I can't reproduce the issue anymore, which is great news! Repeatedly calling `5 [ 25 2^ 0  ] times clear gc` does not crash Factor, even if I do it `30 [ ... ] times`. I love it when these things work, 'cause I hate debugging GCs. 24.11.2016, 19:54, "Jon Harper" :Found the discussion about 32bit array : https://github.com/factor/factor/issues/1566 Also what's happening in your case is that the heap size grows when the arrays are allocated. If you gc, you will get rid of the arrays, but the heap doesn't shrink. So you can reallocate more arrays, but the factor process still uses as much ram. Note that if the arrays are prettyprinted in the listener, you need to "restart listener" and then gc so that they can be collected. The `clear` command makes sure that listener doesn't have a chance to prettyprint. ---=---Александр --
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] GC Bug? (Was: Out Of Memory)

2016-11-24 Thread Jon Harper

Found the discussion about 32bit array :
https://github.com/factor/factor/issues/1566

Also what's happening in your case is that the heap size grows when the
arrays are allocated. If you gc, you will get rid of the arrays, but the
heap doesn't shrink. So you can reallocate more arrays, but the factor
process still uses as much ram.

Note that if the arrays are prettyprinted in the listener, you need to
"restart listener" and then gc so that they can be collected.

On my machine, I see:
8 10^ 0  ! 10% MEM
8 10^ 0  ! 20% MEM
restart listener
gc ! %20 MEM
8 10^ 0  ! 20% MEM
8 10^ 0  ! 20% MEM
8 10^ 0  ! 30% MEM


Jon

On Thu, Nov 24, 2016 at 5:33 PM, Alexander Ilin  wrote:

> Hello!
>
> OK, opening the console I also see the message "fatal_error: Out of memory
> in VirtualAlloc".
>
> I did it this way: `6 [ 25 2^ 0  ] times`
>
> Now I have some further questions.
>
> When I do `5 [ 25 2^ 0  ] times` I see the factor.com process
> eating up ~930 Mb of memory.
>
> Why is it that after restarting and doing `5 [ 25 2^ 0  ] times
> clear gc` it still remains with ~930 Mb of memory?
>
> Why didn't `gc` release the unused and unreferenced memory back to the
> system?
>
> More importantly, if I do `25 2^ 0 ` once more, it crashes, i.e.
> the allocated memory remains unavailable, even though it should have been
> collected by the GC.
>
> Is there a more aggressive version of the `gc` command?
>
> The `clear` command makes sure the empty allocated arrays don't show up in
> (and get referenced by) the UI. Or am I missing something.
>
> The question is quite practical for me, as when I work with big data sets
> I also see that GC keeps hogging the memory I don't use anymore, which
> leads to crashes in the long (and even not so long) run.
>
> 24.11.2016, 19:16, "Jon Harper" :
>
> That's because you are running a 32 bit factor. Try allocating many
> arrays, at some point your OS should return an error to factor at
> https://github.com/factor/factor/blob/master/vm/os-windows.cpp#L97
>
> Also what you are seeing is expected, the array size is limited to
> most-positive-fixnum/2, which is not a problem on 64bits (2^58-1 ~ 10^17 )
> but is kind of limiting on 32 bits (2^26-1 = 67 million ~= 10^8). There was
> discussions about this but I can't find it anymore...
>
> Jon
>
> On Thu, Nov 24, 2016 at 4:45 PM, Alexander Ilin  wrote:
>
> Hello!
>
> Unfortunately, I can't reproduce this in Win8.1 GUI listener:
>
> IN: scratchpad 50 2^ 0 
> Cannot convert to fixnum: 1125899906842624
>
> IN: scratchpad 25 2^ 0 
> (success)
>
> IN: scratchpad 26 2^ 0 
> Invalid array size: 67108864
> Maximum: 67108863
> 24.11.2016, 17:06, "Jon Harper" :
>
> Hi,
> more precisely, the process is aborted (uses the vm 'fatal_error()'
> function):
>
> $ ./factor -run=listener
> Factor 0.98 x86.64 (1781, heads/master-d4528c36da, Tue Aug 16 17:00:11
> 2016)
> [Clang (GCC 4.2.1 Compatible Ubuntu Clang 3.4 (tags/RELEASE_34/final))] on
> linux
> IN: scratchpad 50 2^ 0 
> fatal_error: Out of memory in mmap: 0x2018a82000
> [ ... ]
> Aborted (core dumped)
>
>
>
> Jon
>
> On Thu, Nov 24, 2016 at 4:15 AM, Björn Lindqvist 
> wrote:
>
> Hi,
>
> It shouldn't crash exactly, but it does terminate the process with an
> "Out of memory" error.
>
> 2016-11-23 20:43 GMT+01:00 Alexander Ilin :
> > Hello!
> >
> >   What happens if Factor is out of memory?
> >   Does it throw an exception and aborts the current operation? Or does
> it simply crash the instance?
> >   For me it simply crashes, which is not very nice.
>
>
> ---=---
> Александр
>
>
> 
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
> ,
>
> 
> --
> ,
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
>
> ---=---
> Александр
>
>
> 
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] GC Bug? (Was: Out Of Memory)

2016-11-24 Thread Alexander Ilin

Hello! OK, opening the console I also see the message "fatal_error: Out of memory in VirtualAlloc". I did it this way: `6 [ 25 2^ 0  ] times` Now I have some further questions. When I do `5 [ 25 2^ 0  ] times` I see the factor.com process eating up ~930 Mb of memory. Why is it that after restarting and doing `5 [ 25 2^ 0  ] times clear gc` it still remains with ~930 Mb of memory? Why didn't `gc` release the unused and unreferenced memory back to the system? More importantly, if I do `25 2^ 0 ` once more, it crashes, i.e. the allocated memory remains unavailable, even though it should have been collected by the GC. Is there a more aggressive version of the `gc` command? The `clear` command makes sure the empty allocated arrays don't show up in (and get referenced by) the UI. Or am I missing something. The question is quite practical for me, as when I work with big data sets I also see that GC keeps hogging the memory I don't use anymore, which leads to crashes in the long (and even not so long) run. 24.11.2016, 19:16, "Jon Harper" :That's because you are running a 32 bit factor. Try allocating many arrays, at some point your OS should return an error to factor at https://github.com/factor/factor/blob/master/vm/os-windows.cpp#L97 Also what you are seeing is expected, the array size is limited to most-positive-fixnum/2, which is not a problem on 64bits (2^58-1 ~ 10^17 ) but is kind of limiting on 32 bits (2^26-1 = 67 million ~= 10^8). There was discussions about this but I can't find it anymore... Jon On Thu, Nov 24, 2016 at 4:45 PM, Alexander Ilin  wrote:Hello! Unfortunately, I can't reproduce this in Win8.1 GUI listener: IN: scratchpad 50 2^ 0 Cannot convert to fixnum: 1125899906842624 IN: scratchpad 25 2^ 0 (success) IN: scratchpad 26 2^ 0 Invalid array size: 67108864Maximum: 6710886324.11.2016, 17:06, "Jon Harper" :Hi,more precisely, the process is aborted (uses the vm 'fatal_error()' function):$ ./factor -run=listenerFactor 0.98 x86.64 (1781, heads/master-d4528c36da, Tue Aug 16 17:00:11 2016)[Clang (GCC 4.2.1 Compatible Ubuntu Clang 3.4 (tags/RELEASE_34/final))] on linuxIN: scratchpad 50 2^ 0 fatal_error: Out of memory in mmap: 0x2018a82000[ ... ]Aborted (core dumped)  Jon On Thu, Nov 24, 2016 at 4:15 AM, Björn Lindqvist  wrote:Hi,It shouldn't crash exactly, but it does terminate the process with an"Out of memory" error.2016-11-23 20:43 GMT+01:00 Alexander Ilin :> Hello!>>   What happens if Factor is out of memory?>   Does it throw an exception and aborts the current operation? Or does it simply crash the instance?>   For me it simply crashes, which is not very nice. ---=---Александр --___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk ,--,___Factor-talk mailing listFactor-talk@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/factor-talk  ---=---Александр --
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out Of Memory

2016-11-24 Thread Jon Harper

That's because you are running a 32 bit factor. Try allocating many arrays,
at some point your OS should return an error to factor at
https://github.com/factor/factor/blob/master/vm/os-windows.cpp#L97

Also what you are seeing is expected, the array size is limited to
most-positive-fixnum/2, which is not a problem on 64bits (2^58-1 ~ 10^17 )
but is kind of limiting on 32 bits (2^26-1 = 67 million ~= 10^8). There was
discussions about this but I can't find it anymore...

Jon

On Thu, Nov 24, 2016 at 4:45 PM, Alexander Ilin  wrote:

> Hello!
>
> Unfortunately, I can't reproduce this in Win8.1 GUI listener:
>
> IN: scratchpad 50 2^ 0 
> Cannot convert to fixnum: 1125899906842624
>
> IN: scratchpad 25 2^ 0 
> (success)
>
> IN: scratchpad 26 2^ 0 
> Invalid array size: 67108864
> Maximum: 67108863
> 24.11.2016, 17:06, "Jon Harper" :
>
> Hi,
> more precisely, the process is aborted (uses the vm 'fatal_error()'
> function):
>
> $ ./factor -run=listener
> Factor 0.98 x86.64 (1781, heads/master-d4528c36da, Tue Aug 16 17:00:11
> 2016)
> [Clang (GCC 4.2.1 Compatible Ubuntu Clang 3.4 (tags/RELEASE_34/final))] on
> linux
> IN: scratchpad 50 2^ 0 
> fatal_error: Out of memory in mmap: 0x2018a82000
> [ ... ]
> Aborted (core dumped)
>
>
>
> Jon
>
> On Thu, Nov 24, 2016 at 4:15 AM, Björn Lindqvist 
> wrote:
>
> Hi,
>
> It shouldn't crash exactly, but it does terminate the process with an
> "Out of memory" error.
>
> 2016-11-23 20:43 GMT+01:00 Alexander Ilin :
> > Hello!
> >
> >   What happens if Factor is out of memory?
> >   Does it throw an exception and aborts the current operation? Or does
> it simply crash the instance?
> >   For me it simply crashes, which is not very nice.
>
>
> ---=---
> Александр
>
>
> 
> --
>
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out Of Memory

2016-11-24 Thread Alexander Ilin

Hello! Unfortunately, I can't reproduce this in Win8.1 GUI listener: IN: scratchpad 50 2^ 0 Cannot convert to fixnum: 1125899906842624 IN: scratchpad 25 2^ 0 (success) IN: scratchpad 26 2^ 0 Invalid array size: 67108864Maximum: 6710886324.11.2016, 17:06, "Jon Harper" :Hi,more precisely, the process is aborted (uses the vm 'fatal_error()' function):$ ./factor -run=listenerFactor 0.98 x86.64 (1781, heads/master-d4528c36da, Tue Aug 16 17:00:11 2016)[Clang (GCC 4.2.1 Compatible Ubuntu Clang 3.4 (tags/RELEASE_34/final))] on linuxIN: scratchpad 50 2^ 0 fatal_error: Out of memory in mmap: 0x2018a82000[ ... ]Aborted (core dumped)  Jon On Thu, Nov 24, 2016 at 4:15 AM, Björn Lindqvist  wrote:Hi,It shouldn't crash exactly, but it does terminate the process with an"Out of memory" error.2016-11-23 20:43 GMT+01:00 Alexander Ilin :> Hello!>>   What happens if Factor is out of memory?>   Does it throw an exception and aborts the current operation? Or does it simply crash the instance?>   For me it simply crashes, which is not very nice. ---=---Александр --
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] Out Of Memory

2016-11-24 Thread Jon Harper

Hi,
more precisely, the process is aborted (uses the vm 'fatal_error()'
function):

$ ./factor -run=listener
Factor 0.98 x86.64 (1781, heads/master-d4528c36da, Tue Aug 16 17:00:11 2016)
[Clang (GCC 4.2.1 Compatible Ubuntu Clang 3.4 (tags/RELEASE_34/final))] on
linux
IN: scratchpad 50 2^ 0 
fatal_error: Out of memory in mmap: 0x2018a82000
[ ... ]
Aborted (core dumped)



Jon

On Thu, Nov 24, 2016 at 4:15 AM, Björn Lindqvist  wrote:

> Hi,
>
> It shouldn't crash exactly, but it does terminate the process with an
> "Out of memory" error.
>
> 2016-11-23 20:43 GMT+01:00 Alexander Ilin :
> > Hello!
> >
> >   What happens if Factor is out of memory?
> >   Does it throw an exception and aborts the current operation? Or does
> it simply crash the instance?
> >   For me it simply crashes, which is not very nice.
> >
> > ---=---
> >  Александр
> >
> > 
> --
> > ___
> > Factor-talk mailing list
> > Factor-talk@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/factor-talk
>
>
>
> --
> mvh/best regards Björn Lindqvist
>
> 
> --
> ___
> Factor-talk mailing list
> Factor-talk@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/factor-talk
>
--
___
Factor-talk mailing list
Factor-talk@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/factor-talk

Re: [Factor-talk] TYPED: Declarations

[Factor-talk] TYPED: Declarations

Re: [Factor-talk] Parsing Ratios

[Factor-talk] Parsing Ratios

Re: [Factor-talk] GC - No Bug (Was: Out Of Memory)

Re: [Factor-talk] GC Bug? (Was: Out Of Memory)

Re: [Factor-talk] GC Bug? (Was: Out Of Memory)

Re: [Factor-talk] Out Of Memory

Re: [Factor-talk] Out Of Memory

Re: [Factor-talk] Out Of Memory

10 matches

Site Navigation

Mail list logo

Footer information