On 21 September 2015 at 01:36, Páll Haraldsson <pall.haralds...@gmail.com>
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.
Another thing I saw:
> "String is not a concrete type. Consider ASCIIString or UTF8String. "
>
> This would not apply in Python, UTF8, UTF16 etc. could be in a type (a new
> one that can hold the others through composition?) that "just works"
> [fast]? Windows uses UTF16 and then choosing UTF8String there would be bad?
>
No, that's not what it means. UTF8String will be fast too. In Julia there
are two kinds of types: concrete types, and abstract types. A concrete are
things like:
- Int32
- Int64
- Float64
- Bool
Concrete types have a specific (hence "concrete") number of bytes, and the
optimizer knows exactly how much space they take in memory and can write
optimized code for them. Every actual value in Julia always has a concrete
type. In addition, Julia has the notion of "abstract" types. Abstract types
are only there to provide a hierarchy that allows us to talk about types
with properties in common. For example:
* "Integer" includes Int16, Int32, Int64 and other integer-like types.
* "FloatingPoint" includes Float16, Float32, Float64, etc.
* "Number" includes Integer, FloatingPoint, and other numbers like Complex,
Rational, etc.
So, for example, I could write a function and say that the function only
works for numbers. I can express that in Julia with:
function add_two(x::Number)
x + 2
end
The upshot of all this is that if Julia knows exactly what concrete types a
function has to deal with, it can write optimized code for that function.
This actually includes my add_two() function because the function is so
simple that just the act of calling it will cause Julia to produce
appropriate optimized code. The problem is that in more complicated
examples, like Adam's code, the compiler cannot predict what values will be
passed to the function, so the compiler is forced to write sub-optimal code
that will work with anything.
So, to answer your question, UTF8String should work fine on Windows. What
matters is that it is a concrete type, so Julia knows how big it is, and
can write appropriate compiled code.
Cheers,
Daniel.
