Some thoughts on the .net CLR/CLI
-
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.
-
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.
Nothing in windows is truly real time - and I never used heaps in realtime apps because of the fragmentation problem. When you are designing an inkjet printer that should just run for years on a conveyor belt with just the ink cartridge needing changing, you can't risk fragmentation or you'll miss product. Windows was never a choice for that! :laugh:
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
-
Nothing in windows is truly real time - and I never used heaps in realtime apps because of the fragmentation problem. When you are designing an inkjet printer that should just run for years on a conveyor belt with just the ink cartridge needing changing, you can't risk fragmentation or you'll miss product. Windows was never a choice for that! :laugh:
Sent from my Amstrad PC 1640 Never throw anything away, Griff Bad command or file name. Bad, bad command! Sit! Stay! Staaaay... AntiTwitter: @DalekDave is now a follower!
VSTs are realtime, and run in windows. I get that windows is not an RTOS. But windows is pretty good at faking it enough for games and music apps. That's what's important - not the largely academic technical category of RTOS. Otherwise people would never use Macs or PCs to write or perform music with. But yeah, I do know what you're saying. You're talking about writing little things like printer drivers. I'm talking about much larger animals where ring buffers just won't cut it. Like a vocoder VST or a quadruple osc synth with compression and analog modeling.
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.
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
-
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!
