Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Malloc Challenge

vicsydev.blogspot.com

Post reply on HN
Print view View original

91–100 of 109 posts

Re: Malloc Challenge

#91

Post by kjdal2001 »

tedkalaw wrote: post #6

at UIUC, there's a project in the systems class (CS241) that is exactly this. there's a leaderboard with projects and how it compares to the system malloc for a variety of metrics this is definitely one of the best projects i ever did in school and a great coming of age project. worst case, there's always an implementation at the back of K&R ;)

I agree. That assignment was one of my favorites. It was a lot of fun because it was fairly easy to get something that functioned, and as you came up with ideas for making it better (or just got ideas from reference implementations), you could watch your metrics get better or worse.

Re: Malloc Challenge

#92

Post by codr4life »

wfunction wrote: post #65
codr4life wrote: post #46

Earlier quoted context omitted.

The pool reference allocator does just that internally. It prefixes each allocation with a block containing the size among other things. Either base your implementation on top of that or take the idea and run with it.

You totally missed the point of my question. I was NOT asking "I have an allocator that doesn't store the buffer size; how can I use it?" I was asking, "I don't think an allocator should need to store the buffer size internally; why not formulate the challenge so that the block size doesn't need to be stored?"

That's a pretty nasty requirement on top of an allocator protocol; I wouldn't want to use it, or debug it for that matter, yikes.

And you don't need to store the size. The slab allocator doesn't store any information except how far into the current slab it's already dished out memory.

Re: Malloc Challenge

#93

Post by codr4life »

david-given wrote: post #66
nujabes wrote: post #63

I'm trying to build it in MacOS but I'm inundated with errors. For example malloc_perf.c:39:3: error: implicit declaration of function 'clock_gettime' is invalid in C99 [-Werror,-Wimplicit-function-declaration] BENCHMARK("basic", &c4malloc); ^

Looking at the implementation of libc4life, I think it's full of gcc-isms. C4DEFER() is this: #define _C4DEFER(code, _def) \ void _def() code; \ bool _def_trigger __attribute__((cleanup(_def))) \ #define C4DEFER(code) \ _C4DEFER(code, C4GSYM(def)) \ So, nested functions and gcc attributes. Nested functions awesome, but they're a gcc extension, and only supported on some architectures anyway, and AFAIK only work if yo…

I had to draw a line somewhere, and C99 with GNU extensions is where it is. Cleanup attributes and anonymous functions are just too useful to leave behind. And since I'm using clang to develop this, I'm pretty sure it supports nested functions just fine.

Re: Malloc Challenge

#94

Post by codr4life »

zzzcpan wrote: post #85
jheriko wrote: post #83

its an interesting exercise for learning but the code style is awful. freel instead of freelist? ffs. abbreviating memory to mem is enough of a mistake in the standard library without going further to m like malloc does and some of the examples here. still, much respect, to the coder4life for making such a good effort and having such an awesome name...

Coding style never saved anyone's C code from being insecure. So it's not something to be concerned about, C code is generally awful on its own.

What's awful with C on it's own? You can write all sorts of code in C.

Re: Malloc Challenge

#95

Post by codr4life »

kjdal2001 wrote: post #91
tedkalaw wrote: post #6

at UIUC, there's a project in the systems class (CS241) that is exactly this. there's a leaderboard with projects and how it compares to the system malloc for a variety of metrics this is definitely one of the best projects i ever did in school and a great coming of age project. worst case, there's always an implementation at the back of K&R ;)

I agree. That assignment was one of my favorites. It was a lot of fun because it was fairly easy to get something that functioned, and as you came up with ideas for making it better (or just got ideas from reference implementations), you could watch your metrics get better or worse.

Exactly the experience I'm trying to provide with the challenge. For the price of forking the repository you get a framework for trying out and comparing your own allocation strategies.

Re: Malloc Challenge

#96

Post by codr4life »

mprovost wrote: post #84
nujabes wrote: post #63

I'm trying to build it in MacOS but I'm inundated with errors. For example malloc_perf.c:39:3: error: implicit declaration of function 'clock_gettime' is invalid in C99 [-Werror,-Wimplicit-function-declaration] BENCHMARK("basic", &c4malloc); ^

MacOS doesn't provide clock_gettime in its libc. You have to use a Mach specific timer. There are some libraries that abstract this but obviously the author never built it on a Mac, which is their choice.

I just don't have the patience for anything but Linux these days, sorry about that.

Re: Malloc Challenge

#98

Post by greenshackle2 »

Beltiras wrote: post #79
greenshackle2 wrote: post #34

Earlier quoted context omitted.

That's a minor detail. I'm talking about writing in a procedural style. Rewriting a for..in as a for with counters is relatively trivial, compared to re-implementing a complex class hierarchy in C. You can write procedural Python, and it will look kinda like C if you squint. Cython even lets you use C types directly, with a simple syntax. As I said, maybe not the sanest thing to do, everything is an object in Python…

Python is not really object oriented. To get information hiding you have to wrap your class in a closure and that closure has to track the individual instances. It's not clean code and it's horribly inefficient. Python is also not a functional language. Python provides language structures that allow you to use both styles of programming OOP and functional as-if-it-was.

Right, it's not pure OOP. It's "only" missing strong encapsulation. Trying to implement really private properties in Python doesn't work too well, the language isn't designed for it and it's not considered 'Pythonic'.

All I meant is that everything is an object. It doesn't have strong encapsulation, but you can't get away from its weak encapsulation, since the basic types are objects.

Re: Malloc Challenge

#99

Post by mprovost »

codr4life wrote: post #96
mprovost wrote: post #84

Earlier quoted context omitted.

MacOS doesn't provide clock_gettime in its libc. You have to use a Mach specific timer. There are some libraries that abstract this but obviously the author never built it on a Mac, which is their choice.

I just don't have the patience for anything but Linux these days, sorry about that.

I totally agree, when I'm working on my OS project I just assume Linux/GCC. These days you're only about 30 seconds away from having a brand new Linux machine up and running in AWS/Google. Porting across systems is just too time consuming. As this example shows you can't even count on basic POSIX stuff working everywhere.

Re: Malloc Challenge

#100

Post by greenshackle2 »

xenadu02 wrote: post #23
greenshackle2 wrote: post #21

>[libc4life] is aiming for simplicity and leverage; and it makes a real effort to get there by playing on C's strengths, rather than just inventing yet another buggy Lisp. Ouch, right in the feels, I've been working on https://buildyourownlisp.com in my spare time. (EDIT: I was looking for a name for the repo, YABLisp it is.) > coding in C is a welcome therapy after seemingly wasting years exploring various ways of p…

I'm sure it inflates one's ego but the chances that they've avoided writing any exploitable security vulnerabilities is almost zero.

I didn't mean to make the point so C-centric. I'm not just talking about C programmers. I don't think we should all write C all the time.

I went back to C and Lisp in my spare time because I'm already invested in those languages, between C itself, and CPython.

The common feeling I've seen repeated is doing OOP for a while then getting tired of it, and casting it off.

> I'm sure it inflates one's ego

I'm sure that's true for some, but it would be shortsighted to think all programmers who dislike OOP are just full of themselves and don't have any valid insights.

Post reply on HN