Some thoughts on the .net CLR/CLI
-
All garbage collected languages that I'm familiar with take too big a bite in that they don't let you delete things. The GC has to do all the work. I'd rather see opportunities to delete objects under programmer control via: * Stack variables that destruct when you go out of scope * Destructors in classes * Ability to 'delete' a pointer These ideas are not incompatible with GC languages but the features are conspicuously absent.
I'm retired. There's a nap for that... - Harvey
That's true, and kind of what i'm looking for, whatever form it takes. the Boehm collector let you mix, but that was C++ code there are now true value types (stack allocated) in the latest C#
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I've always been kind of bummed about the universal garbage collection in .NET because you can't do realtime coding with a GC running in the background. What I'd have liked to see, at the very least, is a segregated heap that wasn't collected, and an ability to suspend background collection. You can kind of hack something like it into there using the large object heap and also using .NET 4+'s ability to reserve heap and suspend GC but it's non-optimal. See, I'd really like to write VST plugins in C# for example, and while there are offerings to do so, they are not realtime. They are kinda realtime. Not good enough for live music performance. Instead I'm forced to do it in something like C++ or *gasp* Delphi, which is costlier/more time consuming to write solid code with. I'd be okay with C# code blocks (similar to unsafe) where realtime code could run but apparently that's too much to ask. Also, I love garbage collection. Don't get me wrong. I even used it in C++ ISAPI server apps (using Boehm collector) for my strings in order to avoid heap fragmentation - in the right areas it can even improve performance.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
User the right tool for the right job.
-
User the right tool for the right job.
That's why I use C++ for this. But it would be nice to have other options.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
That's why I use C++ for this. But it would be nice to have other options.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
C, senor.
-
I've always been kind of bummed about the universal garbage collection in .NET because you can't do realtime coding with a GC running in the background. What I'd have liked to see, at the very least, is a segregated heap that wasn't collected, and an ability to suspend background collection. You can kind of hack something like it into there using the large object heap and also using .NET 4+'s ability to reserve heap and suspend GC but it's non-optimal. See, I'd really like to write VST plugins in C# for example, and while there are offerings to do so, they are not realtime. They are kinda realtime. Not good enough for live music performance. Instead I'm forced to do it in something like C++ or *gasp* Delphi, which is costlier/more time consuming to write solid code with. I'd be okay with C# code blocks (similar to unsafe) where realtime code could run but apparently that's too much to ask. Also, I love garbage collection. Don't get me wrong. I even used it in C++ ISAPI server apps (using Boehm collector) for my strings in order to avoid heap fragmentation - in the right areas it can even improve performance.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
codewitch honey crisis wrote:
universal garbage collection in .NET
Now caught on camera[^] Somehow that was the first thing that came to mind :D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
All garbage collected languages that I'm familiar with take too big a bite in that they don't let you delete things. The GC has to do all the work. I'd rather see opportunities to delete objects under programmer control via: * Stack variables that destruct when you go out of scope * Destructors in classes * Ability to 'delete' a pointer These ideas are not incompatible with GC languages but the features are conspicuously absent.
I'm retired. There's a nap for that... - Harvey
H.Brydon wrote:
Destructors in classes
That's possible, although I've never seen them out in the wild: Finalizers - C# Programming Guide | Microsoft Docs[^]
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
H.Brydon wrote:
Destructors in classes
That's possible, although I've never seen them out in the wild: Finalizers - C# Programming Guide | Microsoft Docs[^]
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
I wasn't going to tell him. Anyone that uses Finalizers needs to be dragged into the street and summarily shot. With witnesses so nobody *ever* makes the same mistake. There's a special hell where they keep the guy who designed them. It's below building 8 on the microsoft campus.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
codewitch honey crisis wrote:
universal garbage collection in .NET
Now caught on camera[^] Somehow that was the first thing that came to mind :D
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
seems accurate. it even kinda looks like HAL
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I've always been kind of bummed about the universal garbage collection in .NET because you can't do realtime coding with a GC running in the background. What I'd have liked to see, at the very least, is a segregated heap that wasn't collected, and an ability to suspend background collection. You can kind of hack something like it into there using the large object heap and also using .NET 4+'s ability to reserve heap and suspend GC but it's non-optimal. See, I'd really like to write VST plugins in C# for example, and while there are offerings to do so, they are not realtime. They are kinda realtime. Not good enough for live music performance. Instead I'm forced to do it in something like C++ or *gasp* Delphi, which is costlier/more time consuming to write solid code with. I'd be okay with C# code blocks (similar to unsafe) where realtime code could run but apparently that's too much to ask. Also, I love garbage collection. Don't get me wrong. I even used it in C++ ISAPI server apps (using Boehm collector) for my strings in order to avoid heap fragmentation - in the right areas it can even improve performance.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
You might want to look at what Unity is doing with what they're calling High Performance C#. AIUI a big part is limiting themselves to stack allocations and language features that don't do heap allocations in the background to get C++ish equivalent performance/consistency by avoiding ever triggering GCs. You probably don't need the verifiably vectorized capabilities they've also built into their toolchain; but borrowing an off the shelf solution might be easier than doing the parts you need on your own. [C++, C# and Unity](https://lucasmeijer.com/posts/cpp\_unity/)
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
I wasn't going to tell him. Anyone that uses Finalizers needs to be dragged into the street and summarily shot. With witnesses so nobody *ever* makes the same mistake. There's a special hell where they keep the guy who designed them. It's below building 8 on the microsoft campus.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
I'm told tuples use them too :laugh:
Best, Sander sanderrossel.com Continuous Integration, Delivery, and Deployment arrgh.js - Bringing LINQ to JavaScript Object-Oriented Programming in C# Succinctly
-
You might want to look at what Unity is doing with what they're calling High Performance C#. AIUI a big part is limiting themselves to stack allocations and language features that don't do heap allocations in the background to get C++ish equivalent performance/consistency by avoiding ever triggering GCs. You probably don't need the verifiably vectorized capabilities they've also built into their toolchain; but borrowing an off the shelf solution might be easier than doing the parts you need on your own. [C++, C# and Unity](https://lucasmeijer.com/posts/cpp\_unity/)
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
what what? ooooh. I'll definitely check it out. it sounds interesting.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I've always been kind of bummed about the universal garbage collection in .NET because you can't do realtime coding with a GC running in the background. What I'd have liked to see, at the very least, is a segregated heap that wasn't collected, and an ability to suspend background collection. You can kind of hack something like it into there using the large object heap and also using .NET 4+'s ability to reserve heap and suspend GC but it's non-optimal. See, I'd really like to write VST plugins in C# for example, and while there are offerings to do so, they are not realtime. They are kinda realtime. Not good enough for live music performance. Instead I'm forced to do it in something like C++ or *gasp* Delphi, which is costlier/more time consuming to write solid code with. I'd be okay with C# code blocks (similar to unsafe) where realtime code could run but apparently that's too much to ask. Also, I love garbage collection. Don't get me wrong. I even used it in C++ ISAPI server apps (using Boehm collector) for my strings in order to avoid heap fragmentation - in the right areas it can even improve performance.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Being thoroughly experienced in C++, C#, and near-real-time programming, I've always been bemused by the complaints of performance issues related to garbage collection in .NET. I've never had a performance concern in my C# code that I could attribute to the GC taking over the machine. It's always been thread contention between resources, poorly thought-out locks, misuse of .NET facilities, or something similar. My opinion is that if your performance constraints are that tight, you shouldn't be using a garbage-collected language anyway. You need C or C++ and native threading constructs so that your control is as close to the bare metal as possible.
Software Zen:
delete this; -
Being thoroughly experienced in C++, C#, and near-real-time programming, I've always been bemused by the complaints of performance issues related to garbage collection in .NET. I've never had a performance concern in my C# code that I could attribute to the GC taking over the machine. It's always been thread contention between resources, poorly thought-out locks, misuse of .NET facilities, or something similar. My opinion is that if your performance constraints are that tight, you shouldn't be using a garbage-collected language anyway. You need C or C++ and native threading constructs so that your control is as close to the bare metal as possible.
Software Zen:
delete this;Oh if you've ever tried to realtime audio apps you'll find out real quick. You can't even play midi on your own using midiout/send at anything 96ppm or above without GC forcing you to drop frames or lag periodically. suspend the GC like 4+ allows you to, the problem disappears, but you have to reserve reams of heap to do it. I think your lack of running into the problem may be more due to the lack of trying to do anything crazy like that with C#? I wouldn't have even tried, *precisely because* of my experience with C++ and RTOS apps except i was looking into the GC issue and looking at how realistic .NET 4+ suspend GC/critical region feature was to use in practice, so i developed some realtime code to test it. something sensitive. Ears are more time sensitive than eyes, so I wrote a midi player. I've tested the results. I *could* post the project here just to settle the point, but it seems a lot of work just to do this.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I wasn't going to tell him. Anyone that uses Finalizers needs to be dragged into the street and summarily shot. With witnesses so nobody *ever* makes the same mistake. There's a special hell where they keep the guy who designed them. It's below building 8 on the microsoft campus.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Finalizers are kind of mandatory if C# object create native resource through interop. An increasingly rare occurrence those days to be sure, but it still happens. Also MS Style cop thingy complains if you don't have a finalizer on IDisposable class. I disable that silly warning... But some people chose to follow it.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Finalizers are kind of mandatory if C# object create native resource through interop. An increasingly rare occurrence those days to be sure, but it still happens. Also MS Style cop thingy complains if you don't have a finalizer on IDisposable class. I disable that silly warning... But some people chose to follow it.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I just use dispose. if you don't dispose your disposable unmanaged resources, you suck at coding. I won't make the rest of the end developers pay in GC performance for that lack of skill =D /the true bastard coder from hell
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I just use dispose. if you don't dispose your disposable unmanaged resources, you suck at coding. I won't make the rest of the end developers pay in GC performance for that lack of skill =D /the true bastard coder from hell
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
well there are case were using Dispose is not quite practical... Further if you write a class using unmanaged resource, you can't rely on your user calling Dispose. You can hope they do call Dispose, but it's even better if you can make it work regardless! ;) i.e. it's better if your class doesn't memory leak regardless whether whoever use it call Dispose or not. The whole point of .NET is that .NET class don't give headache to whoever uses them! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
what what? ooooh. I'll definitely check it out. it sounds interesting.
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
Let us know what you find. From what I've read I think they're just limiting what language features they use to control memory allocations, but I've just read a few blogs and never tried anything.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
-
Let us know what you find. From what I've read I think they're just limiting what language features they use to control memory allocations, but I've just read a few blogs and never tried anything.
Did you ever see history portrayed as an old man with a wise brow and pulseless heart, weighing all things in the balance of reason? Is not rather the genius of history like an eternal, imploring maiden, full of fire, with a burning heart and flaming soul, humanly warm and humanly beautiful? --Zachris Topelius Training a telescope on one’s own belly button will only reveal lint. You like that? You go right on staring at it. I prefer looking at galaxies. -- Sarah Hoyt
They appear to have some new syntax, among them "#include". Not sure if it's limited to a preprocessor or not, but they're talking about rendering to machine code, not IL
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
well there are case were using Dispose is not quite practical... Further if you write a class using unmanaged resource, you can't rely on your user calling Dispose. You can hope they do call Dispose, but it's even better if you can make it work regardless! ;) i.e. it's better if your class doesn't memory leak regardless whether whoever use it call Dispose or not. The whole point of .NET is that .NET class don't give headache to whoever uses them! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I mean, probably, but I don't usually code for VB developers :suss:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
-
I mean, probably, but I don't usually code for VB developers :suss:
When I was growin' up, I was the smartest kid I knew. Maybe that was just because I didn't know that many kids. All I know is now I feel the opposite.
you sound like you didn't give how to use unmanaged resource any sort of serious thought! :rolleyes: to be fair.. in the last 10 years I never had to use unmanaged resource (explicitly) in .NET! But you have to keep in mind. 1. .NET use a lot of unmanaged resource. But it's done in a lot of nicely encapsulated OS/Utility class. For example WPF use tons of them to render DirectX content. It's also very common in WinForm, all those Bitmap, Cursor, Brush, etc... all wrap unmanaged OS resources. 2. once upon a time, before .NET 3.5, one often had to use unmanaged resource explicitly to use OS class not nicely wrapped. Hence how to properly use them was much more common knowledge back then. Additionally what has unmanaged resources to do with VB? If anything, my natural prejudice against VB developers would have me say that VB developer can't properly handle unmanaged resources! ;P
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
