On 23 September 2015 at 14:15, Páll Haraldsson <[email protected]> wrote:
> > On Monday, September 21, 2015 at 12:18:12 AM UTC, Daniel Carrera wrote: >> >> >> On 21 September 2015 at 01:36, Páll Haraldsson <[email protected]> >> wrote: >> >>> I know about @devec but wander how close Julia is also able to match the >>> speed of its looks with more condensed code or MATLAB-like or functional >>> programming language style. What are the most interesting issue numbers to >>> look at, if you were to try to help? I'm guessing its not one of the easier >>> "up-for-grabs" issues, for relative newbies like me.. >>> >> >> Sorry, I don't understand what you are trying to ask. >> > > I really just meant, with the loop, the code goes from 2 to 6 lines. Is > three times LOC a drawback of Julia to get speed (note you do not *have to* > expand if speed isn't critical, and much code isn't). > No, I don't think there is a LOC drawback of Julia. To match MATLAB in speed, Julia code should typically be about the same length. To go faster than MATLAB, you may need to combine loops the way I did, and that will make the code a little bit longer. There are macros that will do this optimization for you without the extra lines of code. I just happen to like loops better because I feel I have more control over the detailed steps. > Compared to C/C++ that is competetive, but may not be against say MATLAB. > The code was already fast there and didn't need a loop. I assume/understand > this is a temporary situation, and maybe I or anyone can help fix it. > What is a temporary situation? Sorry, I'm not trying to be obtuse, but I'm having a hard time understanding your concerns. > Thanks for answering. I knew about abstract vs. concrete. What I meant > here, "UTF8String will be fast" yes, but if you are on Windows the API uses > UTF16 and I assume you'll be converting needlessly back and forth. > Why would Julia convert anything? A string is just a sequence of bytes in memory. There is no connection to any Windows internal. In fact, you don't even know how Windows stores strings. Just because the API uses UTF16 doesn't mean that the internal representation in Windows is UTF16. A API is just a way to talk to a library. It means almost nothing. > That might not be a problem, you are maybe I/O-limited. But if not, will > Windows always be second class platform, for code that assumes UTF8 (or > wise versa..)? Will Julia at least compete will with Python for string > handling..? > Windows *IS* *NOT* a second-class platform. You are imagining a limitation that doesn't exist. The Windows API has nothing to do with how Julia runs. Daniel.
