On the topic of Cython, the code you write in Cython compiles into a C extension module for Python. What exactly does that mean? Once the C or C++ code is obtained from compiling your Cython code, you can compile and run the module without having Cython being installed, however the module will almost always be dependent on Python as that is what Cython creates, an extension module for Python which are linked against the Python library.
My only question on Cython portability is whether the C or C++ code Cython produces depends on libraries or functions which may be unavailable on resource constrained environments.
Cython was what I wrote the liblouisxml python bindings in, so I have some experience with it.
I know little about Lua, but reading the about page indicates that the portability is little concern (it has a long list of OSs supported, including embedded and mobile platforms), see http://www.lua.org/about.html.
Michael Whapples On 26/10/2013 17:46, John Gardner wrote:
Hello all, thanks for the great feedback. Let me repeat and emphasize some points from my original proposal. One is that we use a well-known well-supported scripting language so that we can be reasonably confident that we won't have to use our time debugging our engine. I absolutely disagree with John Boyer about writing our own scripting language. That is a step backward. We must make our fundamental scripts accessible to mere mortals if we really want liblouis braille translation to be excellent for all languages and to stay that way. I am a physicist and am convinced that simple is always better. I am concerned that we are setting up "performance" as too much of a holy grail. We need performance on a human time scale, and humans are not getting faster. Computers are. So even if the new system was somewhat slower than the current liblouis, it wouldn't be slower in a couple of years. Instead of rejecting suggestions because we fear that performance will be too bad, we should set up a benchmark and insist that the new system meet that benchmark. I would suggest a benchmark based on the present speed times some factor. My question of you is whether a factor of ten slower would adversely affect any present application? A factor of 2? Mesar reports a speed of roughly 20 microseconds per word now. His test was 5 seconds on 241k words. That's about a 250 page book. Would you object to taking 50 seconds to translate that book if you had confidence that the translation was really right? And in five years the time would probably shrink to 5 seconds again. Jamie, is 200 microseconds per word gonna slow down NVDA? Of the comments made so far, I am most concerned by Jamie's comment about conflicting Python run-time engines. It seems clear to me now that if we do use Python, it would need to be compiled before final use, although the run-time environment would be used for de-bugging. I do not know Cython, so maybe my understanding is just wrong that it will compile into a C module that can then be run independently of Cython. Are there Cython experts available for advice. I do understand that algorithm design is important. In my simple mind, this is just a different way to saying that we need to build fast compiled subroutines to do the common tasks of translation. However, if we adopt Susan's long-time suggestion of translating most words from big look-up tables, the time spent on other translations would probably not be important. I claim that performance is less critical for formatting (ie liblouisutdml). Am I wrong? Finally I do strongly agree that we need to consider other scripting languages. What are the advantage of Lua? Are there other candidates? My personal acceptahnce critieria would be that the final format work on all OS, be well-established and likely to have legs into the future and that it be as humanly readable as possible. Thank you all. This is a fruitful discussion, and I hope we keep it that way. John G -----Original Message----- From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Mesar Hameed Sent: Friday, October 25, 2013 11:27 PM To: liblouis-liblouisxml@xxxxxxxxxxxxx Subject: [liblouis-liblouisxml] Re: Performance Question Hi Ken, I don't have the performance issues that you describe, but maybe thats because your test is written in bash. My python scripts that I refered to earlier, take 5 seconds to process a wordlist of 241 thousand, which seems more realistic. The reason for the slowdown in your script is because you are using a separate process call for each word being translated. Hope that helps. Mesar On Sat 26/10/13,00:13, Ken Perry wrote:Here is what I mean by performance issue. The current liblouis takes 15minutes to convert a 99,107 word file. That is too long. If this parser was generated by the same tools I have used in the past to write a compiler that spits out some pretty nasty c++ using grammers and lex files that file could be done in seconds or at most a minute or two not 15 minutes. Add the definite slow down when you use scripting languages even those which are jit compiled you will start seeing much worse than 15 minutes.Ken -----Original Message----- From: liblouis-liblouisxml-bounce@xxxxxxxxxxxxx [mailto:liblouis-liblouisxml-bounce@xxxxxxxxxxxxx] On Behalf Of Susan Jolly Sent: Friday, October 25, 2013 6:04 PM To: liblouis-liblouisxml@xxxxxxxxxxxxx Subject: [liblouis-liblouisxml] Performance Question Hi everyone, I've been lurking on this list for a long time but have now joined becauseI believe that what I've learned from my practical experience in developing braille software over the last dozen years could be helpful as far as making plans for the future.However I will need some background. My first question is why you have aconcern about performance issues. I've always written my braille software entirely in Java and even on my prevous PC running Windows XP I could translate entire books of fiction to English contracted braille in only a few seconds.Susan Jolly For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.comFor a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com
For a description of the software, to download it and links to project pages go to http://www.abilitiessoft.com
