Neolander wrote:I understand the time constraint argument, but what you're proposing implies dropping ALL native code (C, C++, Pascal, Pascal object, ObjectiveC, and so on...) and switch to interpreted code everywhere in user space. Because native compiled code does not include any notion of type anymore, as you probably know. For machine code, a pointer is just an unsigned integer. No more,no less.
Not interpreted ( or even JIT ) at all ,but AOT compiled , all that is required is that the compiler can check where all memory references are going so any GC based language is fine. Cs abbility to create any memory reference makes this difficult.
Note the OS uses a compiler IR for all files and compiles it specifically for the machine upon install time. You could use LVVM IR for these but a C verifier is very difficult.
And then about that "very little performance gain". I've heard about how small it is many times. And indeed it's true when you run complex library functions and have all libraries written in native code (again, you can't get around the need of such code
), because the instruction decoding + real-time parameter checking + garbage collection + various sandboxing + call + <insert other bloat here> overhead is small compared with the execution time of the function. As an example, Pardus linux have their package manager written in python, and except through the memory footprint you just couldn't tell. But for something that requires executing a lot of simple instructions, like physics, that overhead is too high, unless you have some NASA computer. Believe me, I've tried.
Compared to assembler C is still bloat , you can argue the same thing ( eg L4) ..
re .." instruction decoding + real-time parameter checking + garbage collection + various sandboxing + call + <insert other bloat here> overhead is small compared with the execution time of the function"
None of this occurs , it will all be compiled even Python and java script , there is no param checking etc though there is additional memory checking at compile time. GC is the major issue and most of my work has been on avoiding GC pauses (esp for 3D) , concurrent GCs can do the full mark on other threads reducing the impact to about 4% ( which you get back 2-4 fold from not using kernel protection) .
In terms of memory i used to run C++ MFC and .NET well on a 200 Mhz Arm with 32 Meg of memory , the C# version of the app was more functional , about the same speed and smaller . Using a single run time will avoid most of the bloat you see at the moment with different runtimes and versions of runtimes.
Lastly I think the OO difference is the big one , OO is not suited where you need the highest performance but you can write static C like code in C# but few people have the skill, you cant use pointer arithmatic out side of trusted libs.
Im also working with allowing some trusted libs and runtimes to be native in such an environment especially for 3D.
Lastly on massive multicores , immutable data will rule , and Ocaml is a better fit. Though Ocaml is a difficult language to learn better suited to scientists.
In my opinion, the best way to do fast application development is to have a smart and rigorous compiler + some powerful code generation systems. That approach was used by Delphi for rapid GUI application development, and it worked damn well (though I may be biased since I learned how to program with delphi
). But well, now developers require the computer to do more and more of their own homework at execution time. I'm fine with that as long as I can write efficient code in pascal or C(++) myself, I just hope that OS manufacturers won't *ever* make going through that bloat a requirement, as you've written above...
PS : And, by the way, C *is* type-safe, as long as you don't cast everything without a single thought...
On the other hand, you mention OCaml, while some quick research tells me that in this language, you can put pretty much everything in a variable without declaring its type first... Maybe you should have a second look at what C really does *before* bashing it for the sake of bashing it...
It is compiled code... and such generators work fine.
I spent 1 years on asm , 10 years on C , 8 years on C# ,2 years embedded C++ , 6 months on Ocaml . I still use C for some Kernel components. Note both C# and Ocaml dont require you to declare the type as long as it can be automatically inferred ( C doesnt require this) . It is then compiled to IR ( intermediate Representive) with the type.
The problem with C is while the system
can run C code ( and does for some trusted libs which are "trusted" to be not malicious are well tested , and low in bugs) it cannot verify at compile time that the code is safe
1. You can maliciously cast structs to the wrong type or create buffer overuns ( a lot of hacks are based on these) .
2. you can assign the value of a runtime determined function to a function pointer ( or data pointer) and then execute random code or trash data. Its possible to compile it to have runtime checks for pointers and to put malloc calls to use a GC for memory but then you basically have a bad C# ( which will run slower due to runtime checks which C# doesnt need)..
Its worth noting there are libs which use smart pointers and GC tyle allocators and it is likely that these more modern C programs would run. The OS iself is language agnostic it uses an IR ( which can be CIL or something like LVVM IR) of things that are safe to do , If it can be compiled to an IR which is safe it would work , this could include a C app with such a lib but not the typical C app.
) you also allow malicious code that does exploit this. If you ban these things you eliminate whole classes of bugs and exploits . eg incorrect type , memory allocation , stray /null pointers , buffer over runs etc