i known it is only a problem of font under mac os ,installing Deja Vu font or other solve the problem which is quite uneasy under Mac OS, i then ran it in terminal with DrRacket because in Terminal the display of k is ok ,Terminal use the right font. But i'm surprised to get the result in 7' 50" which is even a little better than in Python with Sympy and twice faster than with Racket GUI:
my question is about the speed performance twice slower of Racket in GUI rather than in Terminal ? why? (with a program that do not do any output or graphic, a simple expression output as result)
another thing but it is more Python related, i know my Scheme program in logic manipulate big expression (10Gb for C13) when i measure Python memory it use only some Mb of memory but i'm not sure it is the size used by Python interpreter or my python code in SymPy ? (use more?)
my question is about the speed performance twice slower of Racket in GUI rather than in Terminal ? why
The program run by DrRacket and racket is not the same.
DrRacket augments your program in order to improve the debugging experience.
Look at the settings in the languge menu.
i can not find the same options as in terminal mode , i checked 'no debugging or profiling' and after 'debugging and profiling' but it change nothing in speed.
I'm am in #lang reader "racket/SRFI-105.rkt"
perheaps it does not apply.
no, i try all it change nothing, i did not use 'time' because it is uneasy and anyway there is only printing in the first minute at beginning and at end (15th minute),at the opposite in terminal it ends at 7th minute.
for sure no, instead the memory limit is pushed to 8192Mb:
Welcome to DrRacket, version 8.6 [cs].
Language: reader "racket/SRFI-105.rkt", with debugging [custom]; memory limit: 8192 MB.
because the minterms list can grow a lot in the computation, and the program halt with a 'out of memory' if not.
What is strange is that in command line there is no need for setting the memory limit and it works.
Running a Racket program at the command time doesn't impose a memory limit. DrRacket by default imposes a memory limit and other sandboxing measures around programs it runs to prevent a bug in your code from interfering with DrRacket's responsiveness. (See custodian-limit-memory and racket/sandbox if you want to do similar things.
This message says with debugging [custom], which means that you still have some debugging instrumentation enabled. That will certainly slow things down.
This could be written as just (time <compute>).
More broadly, DrRacket and the programs it runs share the same Racket process. Despite the isolation mechanisms DrRacket uses, even if you disable all of the debugging instrumentation, there will be overhead in memory use (which will change the garbage collector's behavior) and wall-clock time. It's expected for performance to be better when running a program directly than when running it under DrRacket. (Of course, how significant the difference is varies from program to program.)
I'm confused because with the advice you got in the previous comments, the time in the CLI and DrRacket should be very similar.
How are you storing the expressions internally? Are they syntax objects, or custom structs or a tree of pairs or just a string? If you are using syntaxs, they have a lot of additional properties that are useful for macros anr reporting errors, but perhaps DrRacket is adding an additional property that is dup^n-licated and cause a problem.
I recommend to run the code again using the internal time function, becaue it shows the total time and the gc time, so it may give a hint. Moreover, try to run examples of expressions of different length, so it's possible to guess an "experimental" complexity order that may give another hint.
Can you run it also in DrRacketBC? I don't expect that to be useful but some internal parts are slightly different and there is a tiny chance that the result is different.
Welcome to DrRacket, version 8.7 [cs].
> (time (compute-quiet 12 #t))
cpu time: 57,516 real time: 60,097 gc time: 12,995
Welcome to Racket v8.7 [cs].
> (time (compute-quiet 12 #t))
cpu time: 40,865 real time: 42,249 gc time: 8,992
I expected a 10% or 20% difference. This is like a 50% increase, that is more than what I expected. Can you post the numbers of (compute-quiet 13 #t)?
@robby: Is DrRacket adding a big property to syntax? Like coloring or a more detailed position. (I'm just guessing that it may cause a problem.) Is it possible to "clean" them?
About RacketBC: It's the old version of Racket, the default up to the version 7.9, like two years ago, that used a compiler written in C. The new Racket is RacketCS, the default from version 8.0, that uses a compiler written in Chez Scheme. Both versions are almost equal, so you are safe to ignore the difference unless you are using extensions in C or something. The default download is RacketCS 8.7, but from the download page you can also download RacketBC 8.7. I guess it's unrelated, so ignore this suggestion.
[Edit: fix RacketBC -> RacketCS in the middle of the last paragraph.]
I don't think so but it is hard to be sure what's going on! It should be the case that DrRacket'll be slower only because there is just more stuff loaded into the heap when the settings are as discussed above.
Welcome to DrRacket, version 8.6 [cs].
Language: reader "racket/SRFI-105.rkt" [custom]; memory limit: 14000 MB.
'()
(time (compute-quiet 12 #t))
cpu time: 81154 real time: 80916 gc time: 20873
in CLI Racket:
Welcome to Racket v8.6 [cs].
'()
> (time (compute-quiet 12 #t))
cpu time: 70456 real time: 70455 gc time: 17248
code here
temporary conclusion there is less difference between CLI an GUI under Linux Intel than MacOS M1
i will redo tests on M1 as soon as possible anyway an C13 test on Intel Linux tomorrow i think,apparently i have a few problem (proccess halted) under linux intel, possibly with memory >10 Gb which is not under MacOS (2 systems have 16Gb memory also).
thank you for your info on Racket BC.
I expect the slow down perheaps due to different graphic system between Linux (X-windows?) and Mac OS (Carbon?Cocoa?Xquartz???no this one was Xwindows too?)
approximatively 25% difference between CLI and GUI
even it is just strange for Racket but not a problem for me,
anyway i use emacs, almost never use debugger or macro expander and subscript char display better in CLI than GUI.
I understood that C13 was still x2 slower in DrRacket than in the CLI. If the difference is only a 25%, I guess it's not solvable (as someone else explained above).
I mostly run my programs in DrRacket, but I'm not using too Racket for heavy calculations.
yes 2x was with all options, what is strange is that some options are labelled 'faster loading' and 'inlining'
and i was thinking it will speed up the code but instead it is the opposite. I think too that there is nothing to do for the 25% difference.
(for the screenshot)