Some thoughts on the .net CLR/CLI
-
Show me where Finalized objects get collected before proc exit in a real world scenario. Except server apps, but if you're using unmanaged resources directly from a webserver i hate you. In application code, the GC calls finalizer before proc exit. Show me where it doesn't. Contrive a scenario even. It won't slow down dramatically until reboot. The kernel keeps an slist of kernel handles by process around. Win32 does indeed clean them when the process exits. Your HBITMAP will be around until proc exit, not until reboot. And *it would anyway* - at least in my tests, because Finalize doesn't get called until proc exit anyway.
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.
this is going nowhere so I will stop trying to convince to write proper utility classes. although I will just add 2 (last) things: - for the record memory management, and even dispose, is indeed totally useless if all you have is short running processes. the issue is all about singular long running process running as long as possible. which you seem to dismiss so casually for some mysterious reason - you were asking for a sample that show if finalizer are even ever called. well run the winform app below as a console app (to see the Console.WriteLine() output), press the button a few times, tab out and in, do it again. you will see that finalizer are indeed called sometimes.
class Program { static void Main(string\[\] args) { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MyForm()); } } public class MyForm : Form { public MyForm() { var b = new Button { Text = "Click", Dock = System.Windows.Forms.DockStyle.Fill, }; b.Click += (o, e) => { new Foo(); }; this.Controls.Add(b); } } public class Foo { const int N = 100\_000; IntPtr unmanaged; public Foo() { unmanaged = Marshal.AllocHGlobal(N); GC.AddMemoryPressure(N); } ~Foo() { Console.WriteLine("in finalizer"); // not freeing any memory on purpose //Marshal.FreeHGlobal(unmanaged); //GC.RemoveMemoryPressure(N); } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
this is going nowhere so I will stop trying to convince to write proper utility classes. although I will just add 2 (last) things: - for the record memory management, and even dispose, is indeed totally useless if all you have is short running processes. the issue is all about singular long running process running as long as possible. which you seem to dismiss so casually for some mysterious reason - you were asking for a sample that show if finalizer are even ever called. well run the winform app below as a console app (to see the Console.WriteLine() output), press the button a few times, tab out and in, do it again. you will see that finalizer are indeed called sometimes.
class Program { static void Main(string\[\] args) { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MyForm()); } } public class MyForm : Form { public MyForm() { var b = new Button { Text = "Click", Dock = System.Windows.Forms.DockStyle.Fill, }; b.Click += (o, e) => { new Foo(); }; this.Controls.Add(b); } } public class Foo { const int N = 100\_000; IntPtr unmanaged; public Foo() { unmanaged = Marshal.AllocHGlobal(N); GC.AddMemoryPressure(N); } ~Foo() { Console.WriteLine("in finalizer"); // not freeing any memory on purpose //Marshal.FreeHGlobal(unmanaged); //GC.RemoveMemoryPressure(N); } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I'll try running that. But yeah for now, let's agree to disagree. I'll kick around what you wrote. You may have changed my mind if that sample pans out. The last time i actually tested this was pre .NET 3
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.
-
this is going nowhere so I will stop trying to convince to write proper utility classes. although I will just add 2 (last) things: - for the record memory management, and even dispose, is indeed totally useless if all you have is short running processes. the issue is all about singular long running process running as long as possible. which you seem to dismiss so casually for some mysterious reason - you were asking for a sample that show if finalizer are even ever called. well run the winform app below as a console app (to see the Console.WriteLine() output), press the button a few times, tab out and in, do it again. you will see that finalizer are indeed called sometimes.
class Program { static void Main(string\[\] args) { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MyForm()); } } public class MyForm : Form { public MyForm() { var b = new Button { Text = "Click", Dock = System.Windows.Forms.DockStyle.Fill, }; b.Click += (o, e) => { new Foo(); }; this.Controls.Add(b); } } public class Foo { const int N = 100\_000; IntPtr unmanaged; public Foo() { unmanaged = Marshal.AllocHGlobal(N); GC.AddMemoryPressure(N); } ~Foo() { Console.WriteLine("in finalizer"); // not freeing any memory on purpose //Marshal.FreeHGlobal(unmanaged); //GC.RemoveMemoryPressure(N); } }A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I should add, the only time I'll write a "Utility" class it's static. I use the convention a lot, but never for anything instantiated. That's just me. =) so when you said Utility class my first thought, was , where would I keep the state? :confused: At any rate, it impacts nothing I've written since .NET 2 days, but if I do write some unmanaged wrapper I'll keep this exchange in mind.
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.
-
Show me where Finalized objects get collected before proc exit in a real world scenario. Except server apps, but if you're using unmanaged resources directly from a webserver i hate you. In application code, the GC calls finalizer before proc exit. Show me where it doesn't. Contrive a scenario even. It won't slow down dramatically until reboot. The kernel keeps an slist of kernel handles by process around. Win32 does indeed clean them when the process exits. Your HBITMAP will be around until proc exit, not until reboot. And *it would anyway* - at least in my tests, because Finalize doesn't get called until proc exit anyway.
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 don't think it matters when I analyse your opinion but... I want to point out that while finalizers are unpredictable, that doesn't mean they are unreliable. Finalizers are very reliable. But they only happens once in a while.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I don't think it matters when I analyse your opinion but... I want to point out that while finalizers are unpredictable, that doesn't mean they are unreliable. Finalizers are very reliable. But they only happens once in a while.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
What I mean is you can't rely on them to close something before you run into trouble. Again, this may have changed in newer .NET renditions - since i tested which was a decade ago at least. It looks like your sample does indeed finalize on collect. Still, I question whether it would collect often enough to keep up with the leakage from not calling dispose. It never did in the past for me.
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.
-
What I mean is you can't rely on them to close something before you run into trouble. Again, this may have changed in newer .NET renditions - since i tested which was a decade ago at least. It looks like your sample does indeed finalize on collect. Still, I question whether it would collect often enough to keep up with the leakage from not calling dispose. It never did in the past for me.
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 have trouble understanding your statements... So here are some facts... Using memory pressure hint you can be sure it will suggest to the runtime enough GC that you don't run out of memory or become slow or fragmented. This is, however, something that is only marginally useful, I didn't notice any obvious improvement after using that hit. I guess I never allocated huge unmanaged memory pages. If your code is using other precious system resource, like a Window handle, or a brush handle or a socket... you might be out of luck. You might run out those without the system realizing a system GC is needed. I can't even start to guess what you mean when you wrote "finalizer keep up with the leakage from not calling dispose"
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
I have trouble understanding your statements... So here are some facts... Using memory pressure hint you can be sure it will suggest to the runtime enough GC that you don't run out of memory or become slow or fragmented. This is, however, something that is only marginally useful, I didn't notice any obvious improvement after using that hit. I guess I never allocated huge unmanaged memory pages. If your code is using other precious system resource, like a Window handle, or a brush handle or a socket... you might be out of luck. You might run out those without the system realizing a system GC is needed. I can't even start to guess what you mean when you wrote "finalizer keep up with the leakage from not calling dispose"
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
Super Lloyd wrote:
If your code is using other precious system resource, like a Window handle, or a brush handle or a socket... you might be out of luck. You might run out those without the system realizing a system GC is needed.
As it happens, this is just what I meant. If you use things like this, the GC won't necessarily keep up with your creation of objects. You can run out of GDI handles (though maybe not window handles - for other reasons) pretty quickly and Finalize won't help you, or at least that has happened to me. One of the reasons I won't use GDI handles and such in serving web pages - at least not directly, is the unpredictability of them. What if the connection gets broken and ASP.NET or whatever halts your thread? Sure your finalizers will still run, but when? Will you have enough handles left to serve the next request? (At least if you call dispose faithfully your odds are better but still)
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.
-
Super Lloyd wrote:
If your code is using other precious system resource, like a Window handle, or a brush handle or a socket... you might be out of luck. You might run out those without the system realizing a system GC is needed.
As it happens, this is just what I meant. If you use things like this, the GC won't necessarily keep up with your creation of objects. You can run out of GDI handles (though maybe not window handles - for other reasons) pretty quickly and Finalize won't help you, or at least that has happened to me. One of the reasons I won't use GDI handles and such in serving web pages - at least not directly, is the unpredictability of them. What if the connection gets broken and ASP.NET or whatever halts your thread? Sure your finalizers will still run, but when? Will you have enough handles left to serve the next request? (At least if you call dispose faithfully your odds are better but still)
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.
OIC.. you went from finalizer are not good enough to I flat out to waste time implementing them... Sure enough finalizer won't help with those sparse handle on a web server. And hey, it's really ease to dispose of things in webservice application usually. On the other hand you will run out of handle much more slowly in a user desktop application. And also some object can be very hard to track in desktop application, making finalizer really useful. And finalizer will run in a timely fashion there. And utility class are not always static. For example string, Cursor, Bitmap, Regex, etc... (many of the 21,000+ class in the .NET framework BCL) are instantiable utility classes! ;P And I also happen to love writing my own. In fact I shared DiceSet class with you, as a free custom example! ;)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Super Lloyd wrote:
If your code is using other precious system resource, like a Window handle, or a brush handle or a socket... you might be out of luck. You might run out those without the system realizing a system GC is needed.
As it happens, this is just what I meant. If you use things like this, the GC won't necessarily keep up with your creation of objects. You can run out of GDI handles (though maybe not window handles - for other reasons) pretty quickly and Finalize won't help you, or at least that has happened to me. One of the reasons I won't use GDI handles and such in serving web pages - at least not directly, is the unpredictability of them. What if the connection gets broken and ASP.NET or whatever halts your thread? Sure your finalizers will still run, but when? Will you have enough handles left to serve the next request? (At least if you call dispose faithfully your odds are better but still)
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.
using (var x = ....)is your friend! :)try {} finally {}tooA new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
using (var x = ....)is your friend! :)try {} finally {}tooA new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
can i get an amen over here?
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.
-
OIC.. you went from finalizer are not good enough to I flat out to waste time implementing them... Sure enough finalizer won't help with those sparse handle on a web server. And hey, it's really ease to dispose of things in webservice application usually. On the other hand you will run out of handle much more slowly in a user desktop application. And also some object can be very hard to track in desktop application, making finalizer really useful. And finalizer will run in a timely fashion there. And utility class are not always static. For example string, Cursor, Bitmap, Regex, etc... (many of the 21,000+ class in the .NET framework BCL) are instantiable utility classes! ;P And I also happen to love writing my own. In fact I shared DiceSet class with you, as a free custom example! ;)
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
I just meant i think we define utility differently. mine is narrow when it comes to C# and .NET has but a few. - and it's just a convention i use in my own personal style. i've just been using it so long that it impacts how i understand the word, if that makes sense. I'm not saying you're wrong. I responded a bit to your dice thread. i think we can get you from theory to code if you just explain the "meaning" of the dice syntax. I don't do tabletop gaming. i have friends that are into that stuff but i never was.
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 meant i think we define utility differently. mine is narrow when it comes to C# and .NET has but a few. - and it's just a convention i use in my own personal style. i've just been using it so long that it impacts how i understand the word, if that makes sense. I'm not saying you're wrong. I responded a bit to your dice thread. i think we can get you from theory to code if you just explain the "meaning" of the dice syntax. I don't do tabletop gaming. i have friends that are into that stuff but i never was.
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.
Nice! :D I was planning to look at it tonight.. I don't have the code here, it's personal stuff! ;) The meaning is, you can often read: roll things like "3d6+2" and I try to create an object than can roll that, i.e. a dice collection with 3 x D6 (a Dice class that roll between 1 to 6) and sum them all up and adds 2. Or maybe "D10+D4+1" which would be Dice (10) (roll between 1 to 10) + roll Dice (4) (between 1 to 4) plus 1.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
can i get an amen over here?
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.
yes! :laugh:
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
Nice! :D I was planning to look at it tonight.. I don't have the code here, it's personal stuff! ;) The meaning is, you can often read: roll things like "3d6+2" and I try to create an object than can roll that, i.e. a dice collection with 3 x D6 (a Dice class that roll between 1 to 6) and sum them all up and adds 2. Or maybe "D10+D4+1" which would be Dice (10) (roll between 1 to 10) + roll Dice (4) (between 1 to 4) plus 1.
A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
That's an expression evaluator! just look at the sample in my stuff. Oh there's a bug in the parser runtimes it both is and isn't serious but it's an 8 character long fix and it still works atm =). I can reupload and wait for reapproval but i'll do that tomorrow. The question is, can you just roll while you parse? or do you NEED an object model? because if you need an object model parsing is a two step process. (like, do you need Dice and DiceSets or can you just pass an expression to an Eval function and get your answer out? because if that's good enough your code just got cut by more than half)
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 an expression evaluator! just look at the sample in my stuff. Oh there's a bug in the parser runtimes it both is and isn't serious but it's an 8 character long fix and it still works atm =). I can reupload and wait for reapproval but i'll do that tomorrow. The question is, can you just roll while you parse? or do you NEED an object model? because if you need an object model parsing is a two step process. (like, do you need Dice and DiceSets or can you just pass an expression to an Eval function and get your answer out? because if that's good enough your code just got cut by more than half)
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.
the parsing doesn't return a number, it returns a
DiceSetobject which is a collection ofDicestructure BothDiceSetandDicehave aRoll()method and a niceToString()implementation It might be an evaluator. But it evaluate to an object, not a simple number.A new .NET Serializer All in one Menu-Ribbon Bar Taking over the world since 1371!
-
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.
The folks & Unity have been working a lot on a performance-oriented subset of C#. I don't know exactly how tailored their solution is to real-time application, but since a game engine has to draw 60 frames a second without skipping too many of them, you may find something interesting there.
-
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:
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.
Windows is not a real-time OS.
codewitch honey crisis wrote:
*gasp* Delphi, which is costlier/more time consuming to write solid code with.
I find .NET more verbose than Delphi. Want realtime, check out QNX.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
-
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 will never have true realtime. There are always unexpected delays, from cache misses to virtual memory paging operations. The systems getting closest to RT are the old ones: The first machine I laid my hands on was a 1976 design 16-bit mini (i.e. the class of PDP-11): It had 16 hardware interrupt levels - that is, 16 complete sets of hardware registers, so when an interrupt occured at a higher level than the one currently executing, the register bank was switched in an the first instruction executed 900 ns after the interrupt signal was received. That was certainly impressive in 1976, but the CPU was hard logic throughout, with no nasty pipelines to be emptied, no microcode loops that had to terminate, usually you had no paging or virtual memory. That got you close to RT. You won't see anything that compares today, even without GC. In those days, people got shivers from the though of writing any system software in any high level language. Lots of people shook their heads in disbelief over Unix written in K&R C: It could never work, could never give good enough performance. I have saved a printout of a long discussion from around 1995, when NetNews was The Social Media: This one guy who insisted, at great length, that high level languages was nothing but a fad that would soon go away; they will never give high enough performance. (In 1995, he didn't get much support from the community, but he never gave in to the pressure.) Using a high level language takes you one step away from RT. Using a machine with virtual memory is another step (even if your program is fixed in memory - the OS may be busy managing memory for other processes, with interrupts disabled). Dependency on pipelines and cache hit rates is yet another step. If you require really hard RT, you must stay away from such facilities - probably from any modern CISC CPU. You probably do not have hard RT requirements; you can live with a cache miss, or the OS updating page table for other processes. You should design your code to be able to handle as large random delays as possible. Networking guys know the techniques, like window mechanisms and elastic buffers. If you do things the right way, I am not willing to believe that a modern multi-GHz six-core CPUs ability to run a VST plugin sufficiently close to RT is ruined by the CRT GC! I grew up with high level languages, but knowing that RT "had to" be done in assembly. But soon I also learned how smart optimizing compilers can be, and gave up my belief in assembly. I much longer
-
You will never have true realtime. There are always unexpected delays, from cache misses to virtual memory paging operations. The systems getting closest to RT are the old ones: The first machine I laid my hands on was a 1976 design 16-bit mini (i.e. the class of PDP-11): It had 16 hardware interrupt levels - that is, 16 complete sets of hardware registers, so when an interrupt occured at a higher level than the one currently executing, the register bank was switched in an the first instruction executed 900 ns after the interrupt signal was received. That was certainly impressive in 1976, but the CPU was hard logic throughout, with no nasty pipelines to be emptied, no microcode loops that had to terminate, usually you had no paging or virtual memory. That got you close to RT. You won't see anything that compares today, even without GC. In those days, people got shivers from the though of writing any system software in any high level language. Lots of people shook their heads in disbelief over Unix written in K&R C: It could never work, could never give good enough performance. I have saved a printout of a long discussion from around 1995, when NetNews was The Social Media: This one guy who insisted, at great length, that high level languages was nothing but a fad that would soon go away; they will never give high enough performance. (In 1995, he didn't get much support from the community, but he never gave in to the pressure.) Using a high level language takes you one step away from RT. Using a machine with virtual memory is another step (even if your program is fixed in memory - the OS may be busy managing memory for other processes, with interrupts disabled). Dependency on pipelines and cache hit rates is yet another step. If you require really hard RT, you must stay away from such facilities - probably from any modern CISC CPU. You probably do not have hard RT requirements; you can live with a cache miss, or the OS updating page table for other processes. You should design your code to be able to handle as large random delays as possible. Networking guys know the techniques, like window mechanisms and elastic buffers. If you do things the right way, I am not willing to believe that a modern multi-GHz six-core CPUs ability to run a VST plugin sufficiently close to RT is ruined by the CRT GC! I grew up with high level languages, but knowing that RT "had to" be done in assembly. But soon I also learned how smart optimizing compilers can be, and gave up my belief in assembly. I much longer
See my other reply where i said in this case i don't care about it being technically an RTOS I care about being able to play live music with it
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:
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.
Windows is not a real-time OS.
codewitch honey crisis wrote:
*gasp* Delphi, which is costlier/more time consuming to write solid code with.
I find .NET more verbose than Delphi. Want realtime, check out QNX.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^] "If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
i should have qualified that. everyone is getting on me about that. I don't care about RTOS stuff. I care about being able to play live music. Realtime enough for that.
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.