| |
| |
| |
|
Page: 1 2
Comments:
<0> http://lambda-the-ultimate.org/node/1277 interesting (sweeney on languages 'n ****)
<1> please tell me it's not his haskell pdf
<1> yarrr
<0> mwahahaha
<1> i at least agree with the concurrency points
<2> hey.
<3> Curious, ``Erik, but I sure don't support the glorification of garbage collection
<0> hm, I do :)
<2> ugh memory managers? that's all I've been doing at work
<0> malloc() and free() are hideous, slow, and ugly
<3> Programs manage data, that's all they do, and memory is your main and most important resource. Managing it properly is the job of the programmer
<0> I'd rather manipulate data than manipulate where the data is stored
<0> *shrug*
<2> I just implemented some fixed block allocators for the many smaller allocations. Helps avoid fragmentation I guess.
<2> I wouldn't even need to if the ps3 had VMM
<2> like the Xenon
<0> uh, you use linu,x, right mal?
<3> Sure.
<0> take a look at umm, i think it's called kmalloc() in the kernel source
<0> it's an interesting fugly horrible piece of ****...
<3> That's memory allocation for kernel space, yes
<0> and it's capable of failing when onyl about half your memory is actually consumed
<0> neato, ain't it?
<2> ooh speaking of which, I just implemented a stack dump today, and I need to write a map file parser tomorrow, and I was curious if you guys know of an API function to un-decorate the functions.
<2> I have a new found respect for memory management though, that's for sure.
<3> Meh. Standard malloc() is not even enough to my taste, we should be able to remap and manage memory pages
<0> heh
<2> I don't really mind malloc really, I just wish you could specify an alignment
<3> posix_memalign()
<2> oh :D
<0> heh
<3> Or write your own wrapper that will waste a bit of memroy
<3> memory, even
<2> but, that would need to be serialized right?
<3> Serialized?
<2> Our application is multithreaded.
<2> does that only apply to the next call? I didn't look it up yet
<0> if your malloc doesn't fit inside of the 'leftover' in an existing page, it should be aligned to a new page... :)
<3> It allocates a chunk of memory with an alignment
<0> if you align in page sized chunk, it should always be page aligned
<2> oh
<2> but malloc is special since it's overloaded on the consoles.
<0> you coulda stopped at 'special' :)
<2> hehe
<3> ``Erik, I would like to build a cycling buffer that can always be read sequentialy forward. It's easy by remaping pages, but most people would find that "dirty". Besides, it's not portable
<3> Remapping memory pages can be highly efficient solutions in many cases
<0> that's how linux does realloc
<3> Yes, but realloc is not enough
<0> but it's been proven to be insecure and bug prone in research papers
<0> which is why phkmalloc does a big malloc/copy/free for every realloc
<0> not as fast as rewiring the mmu tlb, but far far far FAR less problems
<3> So instead of moving towards "garbage collection", I would rather desire to fully control my memory as I should be able to
<2> I think it's nice to write your own memory manager non-the-less if not for anything else the debugging info is worth it imo.
<0> oddly enough, most decent garbage collectors give you more low level control than libc api ****, heh
<2> I think managing buffers is the way to go.
<3> It's more than a memory manager, Return0, it's managing the addressing itself
<0> unfortunately, not too many system have a fully incremental generational compacting and sorting garbage collector... heh
<2> Isn't that like what the virtual address space is for?
<2> or does
<2> it's like a layer that can address fragmented physical memory?
<3> If I have a pointer to 3 consecutive pages of memory, I should be able to swap the last 2 instantly without copying anything
<0> fragmented or multiply-backed...
<2> ah
<3> Or make a cycling buffer, an efficient database, efficient partial copy of data into chunks of memory of different size
<0> pretty much any modern OS uses the mmu 'page not available' trap to start the swap-in code
<2> I've got a lot to learn about memory still I think.
<0> heh, join the club ;)
<3> Basically, software should be able to control the memory addressing entirely if it desires so, without relying on obscure syscalls only available when patching the kernel
<2> I know where I work, it's so screwed up how they started our NG engine.
<3> I don't think most people realize how flexible memory could be, we are stuck into our virtual addressing without being able to manage what happens under the hood
<3> Which leads to less efficient software and memory waste
<2> they basically started with new/delete overloads that just called malloc/free and then just went on planning to replace the memory management later
<2> well many of the developers needed some sort of memory manager, so many would just allocate a big buffer and make their own memory managers for each little thing
<2> so there's so much redundant code
<3> I don't think you see what I'm refering to, Return0 ; I'm talking about memory management under your virtual addressing
<0> 99% of code spends almost all its time waiting for user input, and memory management is time consuming and prone to error for the 'normal' coder....
<0> so 99% of the time, decent gc is a huge win
<2> I think I'm on the same "page" mal :P
<2> oh that was bad.
<2> anyway...
<0> the other 1% of the time, you're subverting the kernel and library facilities and implementing your own 'custom' garbage collection anyways
<2> I guess their old engine was simply scene based so they used a stack based system for everything, so when a scene switched they just popped off the whole frame and started fresh
<3> When is this OS of yours done, ``Erik, can I write the user-side interface for memory management? :)
<2> which made for some lazy programming habits
<0> heh, uh, the OS I wanna write will have no 'user' side interface for memory mgmt...
<3> *sobs* I know.
<0> I think ti's a bad thing most of the time :)
<0> no pointers, no referencing, ....
<0> (not exposed, anyways)
<2> so garbage collection is only for reference counting right?
<0> erm, reference counting is a simple form of garbage collection...
<2> err
<0> that can't handle things like circular graphs
<3> Anyway, I really think OSes should expose memory page in a clean and portable way ; I don't like relying on dirty hacks for my code to be as efficient as it should be
<2> right.
<0> paged memory is not a portable concept...
<0> archs exist with no paging, no mmu's... some are segment based, some are flat
<3> Many archs today use pages of some sort, ia32, amd64, ia64
<2> Mal, are you basically saying you want to manage the physical memory and not have to deal with the virtual layer which allows you to have more control?
<0> common desktop os's have pretty much settled on that, yes...
<0> er
<0> desktop chips
<3> Not exactly, Return0, I want to manage the virtual addressing
<0> embedded chips often have no concept of paging
<2> oh
<0> and most computers are not of the desktop/lowendserver category you're thinking, MOST are embedded :D
<3> You can't make a cyclic buffer that can always be read forward without playing with virtual addressing, you just can't ; other solutions are less efficient
<2> y'know what bugs me? I really like stl, and it's sooo taboo in the game industry =\
<0> c++ is icky :(
<3> But most programmers probably don't even see that solution, because they don't know a thing about virtual addressing
<2> lol
<2> you guys are too old skool :P
<0> is it important to always read forward? is one test a step all *THAT* horrible? or forcing page size things and tapping the page fault trap to see if it needs to rewind?
<3> ``Erik, having to jump back at the beginning of the buffer means you never can read.. X chars in a chunk, for example, always one at a time in case you hit the end
<4> is batching relevant for opengl
<3> A cyclic buffer implemented with virtual addressing would loop back smoothly just be remapping pages
<3> just by*
<4> i saw some ugly code but it ran surprisingly fast using just glvertex3f
<0> readthings(*buf, intnummaofthings){ if (**buf+nummathings>endothings) splice; ... }
<0> it'd still depend on a trap kicking
<2> ninjadan, cards these days are so fast, code old enough to be written using glVertex3f probably would run fast :P
<0> which, among other things, surrenders a context :)
<4> well this piece of code ran fast back in the day
<2> how much is it drawing?
<3> Fast, yes, ninjadan ; but not as fast as it could be
<0> heh, hw changes, ninjadan, yesterdays fast things tend to cause fits on todays hw :)
<2> glVertex stuff isn't really "slow" it's just not the fastest method.
<0> glVertex stuff is plenty fast if you dont' happen to have the fugly hack that is agp
<2> hehe
<4> AGP?
<0> if you're running old pci, or fancyarsed 3gio
<2> :)
<3> The drivers buffer the commands to flush them in batches anyawy
<0> then glVertex is about as fast as you can get
<3> But vertex arrays or VBOs are faster, definitely
<0> mal: not on straight pci or 3gio
<2> I only found out today the video memory on the 360 (probably most consoles) is actually what the system uses for everything
<2> which would be really interesting to do GPU based calculations and have quick read access
<4> any of you use d3d?
<0> heh, lots of things do that, return :) usually they have ****y busses so it's *** slow... like the intel i8xx video chipsets *uglyface*
<3> Or just just a proper chip to do m***ive calculations in parallel :)
<4> the batching in d3d is a pain in the neck, how is it in openGL
<2> ``Erik, but ... what does the chipset have to do with sharing video and system memory?
<3> By "batching", I suppose you are referring to vertex arrays and so on, very simple stuff..
<2> I mean rather the system uses video memory, not the video card chipset using system memory!
<0> the gpu itself odesn't really have anything to do with it... ti's the memory management chunk and how it's strung to the gpu...
<4> lets say I have a model of 500 triangles. How many times can I render it in OpenGL if I were just to do something like for(int i=0;i<largenumber;++i) drawmodel
<0> i810, i815, i830, those things just happen to be strung up on the mb without 'video memory', just eeking straight off of system memory...
Return to
#opengl
or
Go to some related
logs:
#computers
#microsoft
#nhl
ircstats cron script
80.89.177.25
ruud hullet
#linuxhelp
#hardware
#politics
ccnp doesnt mean shit
|
|