On Tue, Sep 3, 2013 at 12:56 AM, David Jeske <[email protected]> wrote:
> On Mon, Sep 2, 2013 at 7:51 AM, Bennie Kloosteman <[email protected]>wrote: > >> Note the performance cost in C# strings str.SubString ( Indexof( >> lookupString) , length) requires creating a new string each time. We >> disussed a mutable ptr / length slice lookup previously ( even using a 64 >> bit pointer with the length in the high bits) which would be nice but it >> wont work with C# string as the array is private. >> > > From my perspective, the problem is not the array being private, but > string methods being non-virtual. If everything is virtual/interface-based, > then you can make your own string-slice implementation which looks just > like a normal string. With the caveat that this puts more pressure on the > JIT/inliner/polymorphic-inliner. > Its more than its private strings internal data , the data is [NonSerialized] private int length; [NonSerialized] private char start_char; thats it .. there are a stack of unsafe methods which take the address and work with it , quite a few C methods in the runtime as well for string especially InternalAllocateStr ICALL(STRING_9, "InternalAllocateStr", ves_icall_System_String_InternalAllocateStr) https://github.com/mono/mono/blob/0f2995e95e98e082c7c7039e17175cf2c6a00034/mono/metadata/string-icalls.c Even the JIT does things like this quite a few optomizations for string .. and speaking of method redirects /* * This entry point could be used later for arbitrary method * redirection. */ inline static MonoInst* mini_redirect_call (MonoCompile *cfg, MonoMethod *method, MonoMethodSignature *signature, MonoInst **args, MonoInst *this) { if (method->klass == mono_defaults.string_class) { /* managed string allocation support */ if (strcmp (method->name, "InternalAllocateStr") == 0 && !(mono_profiler_events & MONO_PROFILE_ALLOCATIONS) && !(cfg->opt & MONO_OPT_SHARED)) { MonoInst *iargs [2]; MonoVTable *vtable = mono_class_vtable (cfg->domain, method->klass); MonoMethod *managed_alloc = NULL; g_assert (vtable); /*Should not fail since it System.String*/ #ifndef MONO_CROSS_COMPILE managed_alloc = mono_gc_get_managed_allocator (method->klass, FALSE); #endif if (!managed_alloc) return NULL; EMIT_NEW_VTABLECONST (cfg, iargs [0], vtable); iargs [1] = args [0]; return mono_emit_method_call (cfg, managed_alloc, iargs, this); } } return NULL; } Agree with shap they should not be in the runtime but a good question is why are they in C .. I see some reasons .. 1) Variable length type for string - not needed for rest 2) Hacks to overcome limitations eg virt call hack in jit because its sealed etc 3) USe of faster c routines eg buffer/array copy / compare with Simd . > This is the source of a previous comment of mine that I'd like to forbid > implementation-names from appearing as type-parameters, only allowing > interface names -- or alternatively, allowing you to "implement" a type > without inheriting it's interface (like Sather, or Google-Go). > > IMO, static languages allowing type-paramaters to name concrete > class-type-implementations is one of the legitimate reasons the > dynamic-typing camp still gets to laugh and point fingers at us > static-typers, as it causes too much type inflexibility in code. > > For example, in JVM every method *is* virtual, but you still can't make a > string-compatible string-slice, because string is final, so you can't make > a new implementation of it which you can pass to existing string-paramater > types. > > In all dynamic dispatch systems (Smaltalk, SELF, Python, Ruby, > Objective-C, etc, etc), you can just implement your own string-slice which > has the same method-protocols as a string, and hand it to any string > paramater without trouble. > I agree for GP programming but it doesnt really work well with enhancing value types for better optomization eg all calls which pass a concrete struct ? As they would be boxed to an interface...Im not going to get into whether value types could be virtual and not be boxed but certainly they cant on the CLR. I think a better way is to remove unsafe and replace with #specialised or #advanced regions , in advanced regions you can use C# style ( relatively safe) pointers and concrete types. If you see it in a commercial app than you will ask questions why and for some libs it can be usefull. Ben
_______________________________________________ bitc-dev mailing list [email protected] http://www.coyotos.org/mailman/listinfo/bitc-dev
