Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #90461 > unrolled thread

Feedback for a malloc implementation

Back to article view | Back to comp.lang.c

Contents

  Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-16 17:45 -0700
    Re: Feedback for a malloc implementation Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 12:22 +0530
      Re: Feedback for a malloc implementation Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 17:58 +0530
        Re: Feedback for a malloc implementation BartC <bc@freeuk.com> - 2016-07-17 13:40 +0100
          Re: Feedback for a malloc implementation Udyant Wig <udyant.wig@gmail.com> - 2016-07-17 23:06 +0530
            Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-17 13:40 -0700
    Re: Feedback for a malloc implementation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-17 00:30 -0700
      Re: Feedback for a malloc implementation BartC <bc@freeuk.com> - 2016-07-17 10:54 +0100
        Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-17 04:36 -0700
      Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-17 04:31 -0700
        Re: Feedback for a malloc implementation Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-07-17 11:40 -0700
          Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-17 13:41 -0700
    Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-17 07:02 -0700
      Re: Feedback for a malloc implementation BartC <bc@freeuk.com> - 2016-07-17 20:38 +0100
        Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-17 13:44 -0700
          Re: Feedback for a malloc implementation BartC <bc@freeuk.com> - 2016-07-17 22:19 +0100
            Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-17 18:08 -0700
      Re: Feedback for a malloc implementation Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-18 09:40 -0700
        Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-18 10:48 -0700
          Re: Feedback for a malloc implementation Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-20 08:45 -0700
            Re: Feedback for a malloc implementation Keith Thompson <kst-u@mib.org> - 2016-07-20 09:28 -0700
              Re: Feedback for a malloc implementation Tim Rentsch <txr@alumni.caltech.edu> - 2016-07-21 18:25 -0700
                Re: Feedback for a malloc implementation Aaditya Kalsi <aadityakalsi@gmail.com> - 2016-07-22 16:52 -0700

Page 1 of 2  [1] 2  Next page →

#90461 — Feedback for a malloc implementation

Hello,

I have written a new implementation of malloc() and free() and sibling APIs after studying dlmalloc and other prior art.

I have written it with the goals:

1. Easy to read and maintain.
2. Be more memory conserving.
3. High efficiency and good performance.
4. Portability.

I have a (I believe) working version with some tests and documentation and am hoping for some feedback on design and implementation as well as any other constructive feedback.

Link to source:
https://github.com/akalsi87/akmalloc

Link to documentation:
https://rawgit.com/akalsi87/akmalloc/1.0.1/_layouts/index.html

The library is modeled close to dlmalloc because of its customizability but in doing so I have tried to not obfuscate too much with macros.

Aaditya

[toc] | [next] | [standalone]

#90464

[Could not decode multipart message] — view raw

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--TRKJWbsIjBnB6T2OI4c7KhRFvER49qWSL
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

--TRKJWbsIjBnB6T2OI4c7KhRFvER49qWSL
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

hQIMA9Y6JG92+/q0AQ/7BiYAHKwDTedt7rBMJom5a5GEK3sZtxhk9CApA01K3Jj2
3w2sq00O77lIbwKJsnTePTsF5atRMx1wyOdSJXmfLHO8VkmVGGhEGjhMkdWaafpS
loSNUg7ZOKLmstcBIFLgKWt+pPrnQ+702xcmw5oNAVp/SkPTMLdzlzMxfCnKl8d0
/lZX2SXmnHBK8V5NFvMrV+ygJod9n22feBeMFfFabug3ukI+WU761s1+T89o/ZJf
Wos878hQQRpQwEkyp1TBTymp62XU3L4D3Zf6NxzBGK2pKD6dvQCUpChfUu3jWr7m
hgHPpF8DCByzTfMwkqhJHQzFyLVKJv0cFU8YW2kmEvn30UIdAzU1xr23hXm1oldH
5Tt6U2COn9BwEGsqVRQcr7lBV5E5VpCXsGo63rFuGkj/HXSKn6wINhDQ3JVXLvkc
KR3gXSfp/YqoOgGAILUbBJr4MzJ6kFHxvO/uUvsDs598ytffFrxjDgLLbFhWEhyR
eTURDZj44IrXQn5lH+Kc37Gmxmx7EuvFS96CpJKe/MQpDJfi6+iTtElxGeERsOSl
pUa87HkBN9veTfjULV3XKrm8SMFYptj7qSD9FrYu/pi76r6lVHchc+HJMrIM5K0X
KQodMGwYSgr8iwyQ8KDkzemlULhBCAzst2iWiL6GR4PF319FyPinHbc/FQWJkaXS
7AGOxM6Z7RA/d4sQQ1m+p1j+rBJVHQ+3MsBJPaMQv1Q8CZABdVQFagyBTmVC7t4f
LX0ylMO7NRnKFPF4vscggFZlqZE+VvFjug49JqJwM8YQx8BGM0Wkp5jNGlFBGJP7
WE22Ywqf2qeFm36hDYxHdtgzChRj33XdjAal1ZiIPV3qic7Ni2CUGMcJm9dEuw3k
bH5/GFgtGjAr3p04HD3iyAJMYzNn20ZE1+l6wfaCnzYIO6N1gWA3P8rkEuje1dZh
9mV62WacYmjs6hlmwdSiTmlo8OXiyZ7ETB1527HFq2Z1xqU2JnHvFUAKK6q/b/+G
k/V39RH9e/f6eBLLOooikJk/iAd+WqfQ57JDGDFyY4ZH2EmiPZdRXNiFdS+OIIRC
cDMQeN8+Q0H7OhmdnOUzSMz2Rv72GxIv+Msz1V7s7RAmSkCyzNmaAUjC3nPdw/5F
fhkj8OHBYVwPSdK2906TvUHWUAAuNjjA1OoeDlJgUD13HzlpPtx2KqUc9MvPvBwV
+dkeZB2pqln/GACun3wTjs87zdo7pHDUge1A/HRglmZ7+kQYYZzhoCt83hnG8YQf
d4OL0n1c7gc2zviSsDSfZl96VfP4MHwLFt6IBSHNSkfu7fwhH6zUr8dsv8ehEqTx
dzZGhJeKMHr2OA1zf2IbH7LKsjaJXY6SYzYgOs34Nwd0/zcLZQUc65vTrnG0E7bS
TzV2afZLj/ETRLE2rwp4OLa9zPLTD9+4PbiWUuYnb6Sps5XfmLw2lCXzB1eFq9Zp
T55PWKDfzrbixx9/Ra+PVh7XN8F/kbDltKNKgbcAEcXTgfFQJYl5Ok3Obj+SlcSX
HX2oVqQ+g1avqsFMVlsqnQ9vYVW8gPp/9ROrfBTp8Kmm4jRhE0/ium3S1k3xIUX4
yRmf7ZX++juJYreo3FV8LjZUD/X5+xeNUBTj61YzlcKb2qCZaZac6VqPXaamwdgn
sthTfG2G3iLYBLnZVi/76r9udYewcX2P+H/Bvfpzy5E/toaHyDYMu9EkwnHnS2xP
erNpXH9GWYOsozinTGKMs7hcFq9jb1awV55kykIHcQ4gKU+GDNVY+7k8g41z61VO
LMWxnl9DNaRxD9q5jC4cuGb/6TlHaQdWv70V4Yc+q9kJehb+RDUkwMD9eqfDKB4n
kLv5ydCaT4cfvKj6RUGCcr3rEXUnoF/zPt7OjXY9Fb70ivw6Zz9G3DST4LMWVtfK
V65edNEEnhAC+ZGKe5Hl3wFmCgGF49dr7dUJCtNlTPwDGzshwhTimk/einbtUu+l
oxNw3egVahZddj9Il828p2qJIacwIVxjlB3QTeWfCqp/mjEoCHrkZmwj1zwg/eHH
wtK2Y+0xXyJAVSh6q1V5UqftBepMAMa9hyQln1JsZsI6bcT7DqXwWqL3oIJdOZHQ
CkbLCY5Z7r+bKAsje8VboNSPGXKXgj03GlcDhrAIPx2tyRm4dZL4pYpBkzm8JQ6H
jX3nH6ZrdwjJjHIuJRfBfc1wB5GxTahI1si37XC3iq1Lj3zDbVX9J0+ResqITZoM
vtdXxBM4JejxQZtSyvlmLLCo9pOAzIvJ6JFQVKzKiUMrS8QoUAxU3WcaBlOtI5Bv
QVVR5bkhLQktjESuI+U8uAASXES+yN9gGKwRFymWutpOz5+eObzNM9gJw1LJdwa9
naapoJ+cvCSwFRTRwvhg8tcy11cJBtNsmeacw3rNiQjjJoflRsD/dYTfX2UZnLSd
6j3a/URLBZh26N5A1imdnY00uXzaratnFqFc0c/Tt1j9a673cvL/0DSt3qdpQgMY
v7YdMb324+BncQi27LUuCQY/M4YhuMRJNnNCF+Z6XaJAZUqQJZH/j/JheAF6VrHr
rQPXVfJlh/rF7RvXKS7XsXd8D8KBFM5eLV7jD5b2/pff6PDS0GFVEHFZ+Tyfh5BI
g/rHTcz1bNPSFYyM3DxdmuX4qNgmDiUF5dd7OI38O1rwnXuFmoVNhZCc8MdLZpck
gIWyWvybDqGuzxetcI+isdHLrsUiawwSg8o8hwaBIEeF1cM0W5+Kmp8VPQv6yta+
0citb8UNEKii+3Q8dzlU7rA5yi2GzFaIQiGsI9MZsDcWJ5Xboh8udlyAs2zkizgg
31i2P7l1TWQrOKhQf/ZXV8hf0dG8tjO1fD2lc6oE0wI/9uiNP+MawSeurAAx7GOB
u/Zm0Psk0Xc/MZTnTlcoCH97MFS8sIt15nXvlexqKP+52EqLHUuUOc7wl5gtPsFz
CYq8rw8St2fYIKgg08FNsvb5OZfxL/ObPIZKM8qpzerxcl309yazu4b1zNmRj18H
P9arvMWNi5NPmyvd7IfzZx5ivhp4QlQjCQebo/txE3B4/+eqtRO30B2LtVpSYqD/
j2EooCWtlUL4GXKyk8D96nZF+CZTOgXNqSkimGL6BeTz1wS1Xxk0Pjk73qwWQeVa
YLuDxDVyMABfjf6K8uwxk0WsaBTrk4OTXMWLDTJ6stTaRFD6Sh9OowQJELUgNf1Y
6Uzk0ZA38ihDcPD1EVP6sfTF5ZstNMBOmLuoTXJ+N4OjdvriF1jaXogtYG8u1zTa
hQRlD6TBvnqf1NWoeAufX4ht6or1MlOcXf0RJJy4O9lT+E9lHCbkVEUv8pw7bZ6n
T6JAzWanPoJD0PFAV83d3yjaT1RPsW8b57iecNNCpgioA3USVZojzSe6Gu8akBmB
9VZiMVPUcZp3oYSZkWULnWIQj8tbd0LSASlebibERHaciQUlcNF4lAv1ujJzXvMw
VNM8o36rYqLriJWX6ZyaAa28YLBXPWB37Bes3gyqDsL7p2wsqtaFZ00PXV8HQexW
SU8/DQ4Bt9bQyvyDrrC2hJ7PoxwOAjdGOSYXN4hDo+spsHyVujMocnr1Vz/ZEZ+z
Ldgmn9t80BtDlMzfPWqTQ9M4Y6OSubobUdcP1xIXN63Uze8I9G+fK4Rcw18ep5bO
tjatdT3Q9Ro8PCy76O0imJO8V58ORMX++gwfjIx7mj3fiA/NI+Q9aA9ss+IHiBvG
kQidwK4Qoiv+mu0F8eoogFtk0TOBsWMCHKyl9KH2s8In07wacPeNnmmA/e5Z17gR
PBGco1zT/8JokTgDbAt8xJR87+GdtQZ0Q41+7BN99novSahn/6ynH5mXx2oNuPAz
ZtTEtynZafiDXi9zMNZdtii6VPfVTINh9U8cs/EyRQon1lNTOyQREDIBU68Khynf
zMu7eVqsSx9k0/tMhDcbCqocslwIcdMazpjtGpUgQjVn5VINAeNaOxJkkV/yR4nq
hz4MoWpXjyBYoMpnGz6XPq5FBFbqgwTWIPHckxWxxcI1Jk3vP/QImXW4zysTdJgX
a4lzoYLTiD2dl+mu3Md5rO+XckvJo7xqw7mZ2Df6nVcj5khsxtE0a4A2YQqBRVv+
qiUNJFgY60q5vZXCPZP+tmK3SiwKOeOJTyCAH84sO2Z1FBSXDM30jR2QU4mYfGMa
y/wExye5gfEOztUY2NV9aw+aMeR8S+HgAI1nyi/sdM+nbWlUnDgRneCSo7PMjQ4x
fNcD/P2IMveOCVw8KzZf1/r+8kKiHKnhpInahfCNT962X9h6eckp7o0Yw/wm9i6O
pSH4ZFZaEaiJhTAs5HzdnJ7rqlfJkGFSnNbS/0guR/lYMHG/kTK8w7mzEL3UQWua
/Zkzzm6EUqNdJsBuMVkupBwW+B3Lh8gKrgrec+/2VI/ybryfR69mMmFov/66pTfH
25ZWQ8NbnweRdYdq6pVAmuyKVoRx+sta6JiO1uWLplq/CKONDpWXPdGZTVO916kL
GVLXFWGZolBfghRkpO9TBM5CVmf4/o4/Cy5mQz8zUF7ZtVFSabHsMwHE4Z1Wn2nG
3JG8S+UQxWTqawZ9qEY0Sw4dTVNCwV0Fygf0yQMFG4xXRVkhzaHmVxRtEYOYV7C9
YPPl+ZPUFK3EYC9w0QJeaa220MFYFp03Sr0PqLLCK0RrJRgaNcPH82/HRztflGRa
hIweHrLO5XYm3Yr5T/jY5tg7y72UwSzzvLSnnUePyu2wM2wSubcDlqZj9qO4ohEk
zicyYk3GDfiwVz9/dBFcwfOdGC3RIHW3HEJJKFb2bPm7dMXy1rm7h4LDpsvbfWNe
b82vu6cNO2DzbMj6wGQKmmW3kFEuVTgw6hSCjaqlrNDBBP7mdcelEB9andXCYex8
2v30zLGJYqQuobvzc9KDkNFztirAxSCgZyaf2y7NhQPOiqoXMv135mlJ8ZmX4XfQ
NZD4olaT3BUP4LygYxNUzF2SRvTe4b2em4bnqd7hm+uW2zA6FKR11z9kZvTCYoVx
15R+bfJ8nc+WWEJgHOX+/oUr2noCtMSQjVEsnte/Yggz+2Dm/xfNHPHRZtZQiXOG
kp119UreShna9xU0nUpTmyaDMeica1uCJTp400se7iilA4tkUC3vlh20jcvZlliG
zukNhMC/dyi3YMu65jRtJD3FiURIvBB/7HnaNdrZ0NUnYrlUqYNuWrjEF8nWHW4F
PxkN4LEYKgKMB0Q68x84++M/2MmW23pxx2yMEUSumfxccXs//V2VcuUlH5SiGGfE
K9E4CRp4KC0Jw46V0uiPdenFbIgNtXzfgr5vKuD7FdzelU8gewtVI1uxHnJWFrfy
vQ79aa55by92xz/jnRF9F5AVjBc5fd4xWzsREF7cTziIhc2UdIri4xM+hX+KXfYt
ax+37JhhnLxFvRxJeKy/TAfknudA5ELRYIl/BIT/mtn/RinIkBcsShD2sSqQ0VOl
yjIq5nnqNpjHiUZxiMQ5iyQbfNFOXquorCHL4Tl+0R0hI/RfoR8bQ/x4T1tfl/tn
6x8qxZ4V8FQj9HDAATko1fWEOvAbZmKgrrYpwO+mb82TlnYWPql/QYlGs5X7VSQa
ulA56IV6TyHB0eXsOIy6xtzB3yILEn85gaL6bjeMES9kPWIcz2Hfy9N7d3JQW2KR
aD2OnCrTDQKnXsnv1okjZ5bQd4of2yd7Ah2jhNSEpZ8ET687OFXkg+6S7cHjF8k1
k7bMhvOffi/Hd5sknW8/O013eVjDyF5aV9TCfSkw2HcL6S7eDuVyzylR1oQZ3V3w
3Ja+JYFGImCrf296lEBu76WYrEmteoJox9l0J8faSZC9hyL69jiJ//3QRrKpQpul
lwRxjZZfRYqfBURBHvoOMxOpfjrzK1mIigsiyip+IyNh+QnFkGE8+/jDB1KX4oJk
KRHXEGjBKIV9Jl5TyXM8/2NjySkzEDRi2RLhQ1Z3nt9I5qK7yWX0Oeb5pPHIbCvZ
yIvPEka7NrjuiCUSb1wXGWb1TjvYYY1PL1ZL0C9AYkm2Ewv4UiUEEn7nmf3Nhgri
yJkLh7lYMLBAScaH6HYvrXgvkGooj11OCkA33AWkCVB+la4nOYXq18ELI9hBRuuS
Fw4sViRUBvWyp+W/yKQwKtiRaavYFxkOAo+mZrnwYd0ZhHEmQ+31SVcb21uMEQc9
ORJf4AGKVQv/wgF606t+0LLAZVnU1H+MfKANsWPSEPEQX84+ydnAH/X3gz0dcQk0
w7FUjewBUUjMXpuGA0trLSgFLCEWGZHonqT8vOSOSb0cXeMDriL01FUPVnFLQyVD
wMqkXXHsiYF8nYgGtRuVwT0UFwPCD2siEahb630O4ke3GgPOekw1X8kC+++BeJWl
ywCKmyuRbkAhMsKr4Jl9bZ2V8mR+h12mijMtKEIyxd7gcyddWW3CjsQBExsmmYoW
mzMTM2c5KakMeYGznYkYqy1v8pUH0c5LJRnWneJrlbJaY7wx8xVWLlZkB1SJDDew
7gb4cHrN2OjsatTuA6LrjRd5v1FnrByhx3+67TWbJW51xPeZeif8a5ScoTmbjlXA
vxESDdQSsia2J40vvm9NGKNoK/Vi8+Xh
=yJug
-----END PGP MESSAGE-----

--TRKJWbsIjBnB6T2OI4c7KhRFvER49qWSL--

[toc] | [prev] | [next] | [standalone]

#90471

[Could not decode multipart message] — view raw

This is an OpenPGP/MIME encrypted message (RFC 4880 and 3156)
--6IdN8Suwpcv72vHmUV1xRwN9PU3oCqqSS
Content-Type: application/pgp-encrypted
Content-Description: PGP/MIME version identification

Version: 1

--6IdN8Suwpcv72vHmUV1xRwN9PU3oCqqSS
Content-Type: application/octet-stream; name="encrypted.asc"
Content-Description: OpenPGP encrypted message
Content-Disposition: inline; filename="encrypted.asc"

-----BEGIN PGP MESSAGE-----
Version: GnuPG v2

hQIMA9Y6JG92+/q0AQ/9Fk/e0XpXTKFm/qDjQMgpEJ0qh0y3/2IgdtNqNz6YXo6C
xifOvcAfAeHvzbyoeNDPNj+XTh7tXn2kYfotacAxKuz7vPietqiznuGEcY1bIX36
EI0q+ssU3VfZZN/n0YdlNLxIKxJ16F/BJEyud/6Fh5dkesqRJPbwdqNIQ+FSkHfM
10ZlOV0e94GEVxsnCsx1+yHxW9Z0KT/GSuagocbd8O1HazSDQV30cN900KvtHWH7
FeZmkMvowfWnA1xeOifNAIdqiiLvXKXXcpDrGZ8lIemf3r9330JXo/cJQTvc1wOn
Yq5r3JWPNYhco/MFa04sab6tXahlBHRh6pXzKZ3606WDyw/lzBplOXchQuULqX40
utxRXgas7YIzdvWLE3QQdpi8ZKBNBVekRpDH8E+mWIs86pIyiS08y94jcvFn/XtE
5dZqwc7WXwzHzBuoOwfXrsOw956o7H+EJFmrBlk49H8xruluehgTCLOX8LSw1iGK
a7EKoB9NZw6rbvP+waAfE/CTN6kdbQXldKqSVjCk5TjBoUr3uaosJJ5fJb5e1wqP
X0er38k7S8E+RqG8ObRHVzNTKuDeY1hLUXewB3SQXb36zT25PqIRa76s2ueuOLeR
x/aMUw/HBbRYgos0wGnbazPGkDQbEoWAb/+0M5HkBAvDyKE8gV1ZN68TVeWrf8XS
7AH+nCM7uqtAhAMJKCthDYxgDvpvqITL6eQJurHLLOmx/OhgOv+TLbeT3jCa5mjf
4tSTMKRYreYRzWS1jgr8ugax46F44y+9oGzWt+l8Bx1Gf7TSZcut/W5Te5e3G9K9
an+WA+uHtvkD6exjqA7v0DJNFdguHczbg241sz5LADjtVDI1NfUBUl/RoHTA4XtS
5/7bso2jBj4A8kQBrz4FkFOINKfTzMDFsF4Sp3zGHGeFjiMO7LCEH11KwPdzj2xd
p/ayOutXr8Lc7Cj2lhjUmC/72MvH/jWNYE24QJA//4MCGvlUJrWtYr6F2svUUJms
Du7mhL4G8px1uUzZTSn3fEsNioLtvOh2KMjlnxt/yy9DEyRi5G4gDrAxioHDUV2p
1X7JSO/iJw/T7H7jHFMGF8lUQN4NcF8Zs1DAg/l9JsKvjpJFP4WklbVpc27X3l4/
71VhJ0yvcdfizsf+Jpvq1FKHAqPeCjHL82Y5pCbczZZJyVAQAtnxDzroI7be94Ed
d48VSIiXqzzuVCuLZz5nt0T2lgx0fTwg2gkx/xKWfunsUYKjgcq5Bg7oZkDpOQ5+
J99CXGF+XiUbitpkeB66Q4G/vTFvsL34I2W1/PF3nGm0cQrDiPMRqBTNHvV7nuFw
Ypqh+EBLh59dy/lecyEnkAMsUS19QuOw9LiSSJ3/txrfdtkpPZPF+Gt8PZkHG+cb
WXjvSHI4dW4SqrjfeRibc11ap6cam5b8OygeF2J8PbRAW0sfnNwBqNvY/fE+Gvdm
umy5pq+2m2QtW2+zkJ9JM8/BS/wULgvWZDr8wFaFgJBTaY9TZSY7jzfnYXuQCRsP
qBtHo2AaWZnFBeEdFceKtzI5O8kk9syPmAIQ6urHlff5YZ+35lX/aw1WZNQZ0LJW
IgryUTXgX7uiCmOqsnMXOhdWvggq+oPPHW/4DI11kxm30KRaRi4dRFVJHi1XFpHD
XwMiZrAJa0zcCaVqgrc4Otexl4TTP28g7wetBqG1ShBCUMIa2yaDnqV9r3sOeqOu
sskePle+wBvbyEreugX3pT3pWQZnI62AvflhaS5CeC4xo7bc6/ebsDM/H8ZGLu3s
ASKrhLz02YcbGFeHRNt0m2CWFPG2YcvaMa/jZurhVctemaQk9121nc3UCsQF4MU5
9YFzoFKWPjwvtg/Y6ZdIbFlD5NuHqni1MEhEi7+y4TNYsY7EDKTgt3V2RYSAEVTK
2+6OBiQ84pTHGF3BLnu+2B3BsJXhTagbtKrnv7XW8Id7z30u750qEaVYBSDCcuIX
HpFqHoNqewo13pY6NppEJsm0g6SXvgjm9gouBWwD4zq2P1x7fahsx11oOk8JPOJK
Dy0x35/PIY6rMLV9yWL4KxqpgvMefStjMY1/lSwDKa4iyPbDCox4+N3Fmoo898SZ
dlBoYGmSfGqXr+rH4C811v60w4Xxew11n4vqw2izANWFMqmyhaJMvtejOw0D7wUN
cazEw+D9oLBi4FPj7VMqZhlEZYe/bveMln515eKbfYn0O8qAMo0WSHOStgT2b4DH
YhMyuyVKl7Aqu7bIvUA1bUY7idEkG3brxgdNu/JnjGptcEMZSJZWJTiySLqmQVBE
K4Yt3xoUcnWHOgxMY02zoeWs300vdB2nPkh/GnyYxmAFHvNu6cC5JCGJaBIJtwvg
rv93OyJgmcxCsQIl6EB3NF4/LI6Aqj+OhkPTpJlKAQFp9PZ86r7v7v1maKXACJRT
uot8BdKrby74bOieetACytGiGk2pCR/2u4ZSP+wYXTGCTG4ZIxctTPpPjYsmSJVH
zGTLvqRyexYZ4xkEDxXmvATvTssTZkl1L8+HXHJzxsaPQLjnX0DxPZY2Tq5MLlfq
XMJmTV4eyWrLMZS0Tl6rL26shfr1loGWlvuHt3rTL5jgtMoUthKvjWLfSw06XCkf
TZyLrYs3Os6nlL2XUNZ/benZ63SFVo2FTlSLXv+YOuP7B/lH0nOWLh1IRxmO8OsP
W0lUrc4H+mjTMSNiD4/8+spJOt7yVTAjBnNdWLbie9BHmJce2wl/DDC6avasu64H
z47MDl7zfWeqBELTb4v+siI5CVztl4Go9PAEZ+4MgUgE40A84objBu5gt9Ua+lCd
C3OxAYHmPNKC3BQUgDuHbcVjPjtaQuRMNsFh9eJi9mjGYGRxqz+yjkG0vzrqUfow
bZlqV7INgaCb9kORYWktdPJm7TkULLUet2S6INY0rU7UIyAvjnbx8zNJIXzQS4ae
ozdm/re5jihKfWSm4wCCI4S4I8vc2Cr1Dzj7qz3RMY6HqJ1RsXeRpog3zbQdaXLn
H+whlp8DMag93uGhCA5ITxsiGjE09GNikBQe3PdcgH4ALLchx52MCiIcYFsUyTHK
98q2yekOZXgVcLCE6CLwLtd62lWcdnmOf47LCfMgqR6fPRbQ8on6Ref2VD1zKRWE
GWKwHCw3VECzO19//IAO6AUS4G0nAxSs3Pbl08al3TiIZPoB/6JNKGavTuh7nlt6
f7LM8AMMEHM3D8XUYtJxiWJUpnIItvYwfAiTGN/+dM9lcU9ZTPEiv1mTrr5SyAzu
Gu3YmZRnUpWYLe9t0dlHbY6/+jF+cH7Q0cOk7qXO0NbdDZBO3sBBLPSEXPzlUXD5
9Hy/EF98L+S/91dzcaOqka97VTdmKGlDx6pPSCSpG+mM4EEBQhg87ev8Diru056b
XkccrHK5lRQ+HvWb04e3TFXZPog8rJUqlVQVdMHJ4DcTjQiVwE5ntZ3/DWepCKnW
ODSqYPvupFUnROcIAF/jNCP4T6VmaItwiwbZ+mrp8kLP4mp24IyyA9atR1iEld6v
r4IwIJ8zfE87sEULtT1Ta0zttaDxEh3EBhxVKdu+z+PCXqt8d6imh2V12xyG6jyD
hplvlG39a03AARXGVmMmdPcJn3pJaVv0qPLHNYiFuOJP207uzQibfvBkne9VtU6H
ZtQLu9C5tO7hu57YsQRY7t6jJ5TCfF6vtsZ9ZvsytZAC68XfiDXcVUC81O4wWINl
XUSf3ayTRssCg6EjaVYNhrChbscDaTPOBQOWza3phv0GnJ8MqQr4uFTcyiqdW2M7
/IoZ+oT7uyYUsYbISCgo103z+wXt5zTnr1qiXcLfwWcC+AdfhJObRT1YJCM0iUnX
Xp3qy7AOWP0uSFchEbesLx8LraTPjRC2d7eitg2eOuso/Kwyk/Kzte7rrDV+M7Sa
8rZMDR2gPzYAZqD58Po10Bo+MhUN8yyhJVRQ1z+qSeLkY935t0k0pn3nFJ63bt1+
JvBDUJBlWyie3YRNG7q51lPZnlGSWXlhrQOeC1OXz8ChXLNfdGbq87sJoUfFlgI2
muBPTyCGlNGKkkkwqSjVNCIgbK6X9JYE1FEp8hwiGrevSWMSgHHkPOUUsfad38Ek
I42f96RnN32pPPXVzo9ZUc4TGWHseiw1u2uetBZmNInq0aMl9q0x7Tkc+HsF5Fie
cO9j+qEyixWnTZmrPo4fQTEwWDRmyMf3SjRpoJzXgw5mqBMuTPV6cHFMWJTr9vHz
lAnUDw22rdavnh8IDB9uEo0MhSuMWT4bz+BFzxWq2nXqekfOGoce4N5JLonF/S9Q
7yMiKiRLPn3MvlAh5uP7W4p/9QGXzM3KwInzATDLlPPKlxyLlhiy8H40D1EpC5YJ
CUcki+nwCxCKgXLSZUOpJGs4QDn92u2w6lkz2D0W6x3pajEIv9BsReNpl7YR93NR
3s5T/WpZnbSy1oB2TgQMJJ0zCby+28U9kHPYA0Wpwiv4ZGDYYhDm+loMSRuKwJiZ
8yJdxZRi8e7Yy74eIizjEuUtXDebtMCdK05YEQ2lM0C4Za4p3rNnRl6OHCXFMZPP
FBHQJkorTkzriav4ZQ/AKE4g/S43DNQ7FHNpctUkdNkYZL0XUn35snIVA5H/NBKA
Ij2ep9D156/nZ4pMmODKIWX+rjOcP0NDrwHnvCbFfxM44DGk9pSwW4X1Inb/KZ3h
FIJhCrJnPWnfNHt9hI2fm2efDTi4q+05MYED25oIT85X5uF08ttqGisUfn1HXoTV
7G1qlDL/+ev3T6IgkIbsZQSzTzyIBBVawRwwfD99V5wzp0Lj+Hzq5F/D4z5kpNeV
2wLocOx52A2q3kvRB0juOaF07Iru3PBFejoxntQbTGdysUogTZJcI6UuDCTO2Yl0
ZL9hgrvHQCftbDkLbMsqOi9halzXDmvi5ISXeO63DtWwCdHBGSELxHIK1UTROKgD
28XIXXbV+VzKwKl/j2eg0Kniskx6XDzl1vcC4PhJMklrg7nLc6Mmaef8twh+VVg+
hsfiO3uFRvmMQCQ5YJW6NlMdfnZ9LCLHJ9MoyE2u5jn+osbuaMt+FMmaMS/ewWSW
ovn9tKJUDy/RI+yQNzm7drkdp6F0N7d3aGIwn0+Q7ZZq/VMpIzXUNhqHJKJvGp0V
t9Ihf7u6FM+vdM1H8z1yCfM/lRSYZ8giYgocnepKR8De8XxoIFSOw1BkHwvKPyTy
7V2GsRcfqyNSZIM7O2x2BQfLg2GWIMbmLNToLoQiHmIEC3BE3d9mNaWRQevA/Rzg
/aKqC5JDEdspIYOrqWVo6iSkHfpBeqCfMa7d4Mcepo3kfLDmql+QWFeuCibLixcp
PgaJO+8FYnbs9LBejMfL+ixXook0fO/7LwMIJe9Re4/bOjgY1UwnshqKFYfK1F4F
IlPng5OnJjg6g0/HXM4j+wyIo42H4BqdQnb+zV4AEPSQurYi1CT7xL3jzHRTBs+e
cVM9oBEskU0Ujn+To59MpbG9jFEadAdIftfAGBwa6LISLAFCIbLcgDhwjbmuIJ7X
/2IXmH/w1D2hI0Da4f0BIgzRf1b92C+tBVqAhyKecUmS55NkxJOTQr2E2Y1RCX8B
wI9wwQnC3DiaiI/Sfg4KZ/dmdb7ENyBTmDhO4BsCMBfUMkT+wuJS/MKpGIztrJ1j
Wo65pdYIHdRDcEBPOF6iwimDMz6tfNDrWndrVmxpJGP3loHyv7GPvVnhxIfpL4Ve
PTLPnfF7p3PpZgk3n33FuiQil3XWWJ1Mz14Peiw9K1kqDykIMTG4n8qyucG1mOem
1/UhAbVS1pJZw9NOGDLl3fWfzN5cInaBADcuwgfnp3hNIIz1OSUDqQ8ZidDT+fXG
G+oyylEkqIakspLybbJBio3N8/P99drl58+bLfZTF7nVgzVjvc6BO00PzI26fGbl
mjk+5i+ZbIX0saLnv2WHinIL+qgltR3SN4Uc/pcxyL5+IG8ZBEwH3dfK0pE8jdyO
Q9PB1LF7t26cAAfzZkNxahRx8ihYnGgsxRB99QAhEYB3j9ApPSRCoXD5UyBf57ZO
KHlMxRHMUKpkm8fQXtZ7+SyYmY6RDKamqxLo5duhOaBSSXk5KIJxX+MHwovyLwuX
oQOFezpL8cZoX/vXpoE2PohwvHybirVphoF+JiOwIOs5h+r1HX1spOwi7w86OqgP
eF8uWBwhJsOUQKnAC6lzYSHAv+cP8aqVvmOMmw6+L2iiNjIYc9TLDqRJDOKELVtw
B3mUtWsq0QzzqZS3ffnmz/AZH+BKTVDBtCOVwjTN2VY1ilP80RrrQmhZUOZxYFwL
I+75S3H/O5zoxb6gz0L4/bQjGr3tTuYBjiFoaLCm77vcA0vnOqRzE9T7gU4hLkuz
zdVVcotJHkR5B6BPI5qQ93WO0qZ4bI0SkaK3U0CG91vu247amc6kKQBxeQta2J1L
ludQuY+rTtKBK8g3j03mGnFmQqgRgyrl+GBGWxZQEuHE9uIg5+fyQx0eoHjZJnU2
o+jEMt/LwWBLlrQSdJU/aYqZqGODlfw6pBk4S178cNehITek5gRmlsj/6Q9Jy3Pf
JPFmHgpn8Bl8UF1511Y1thHIenZdKGhkwgXugSj20GvydcoxZwuXGeSCy/fv95tT
9BACSLXkkQUkBFFivjiudFk8D1ZdQg/SZhNS//jbsUWiiFF8yf2th5NSKGnTHBcQ
sR/azo7MZoCcWuZWdyyyDqnu
=EHVA
-----END PGP MESSAGE-----

--6IdN8Suwpcv72vHmUV1xRwN9PU3oCqqSS--

[toc] | [prev] | [next] | [standalone]

#90472

On 17/07/2016 13:28, Udyant Wig wrote:
>
> This is an encrypted OpenPGP message.
> In order to decrypt this mail, you need to install an OpenPGP add-on
> <https://addons.mozilla.org/thunderbird/addon/enigmail/>.
>
>

You message appears to be encrypted.

When I tried to install the suggested add-on (a pita even if it had 
worked), it said "This add-on could not be installed because it could 
not be verified".

While in google groups, your message hasn't (yet) appeared at all. (An 
earlier message of yours in this thread is also encrypted and also not 
on google groups. However other posts you've made in other threads have 
been fine.)



-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#90476

[There was an incident with a GPG key.  The original article follows.
Again.]

On 07/17/2016 06:15 AM, Aaditya Kalsi wrote:
> Hello,
> 
> I have written a new implementation of malloc() and free() and sibling
> APIs after studying dlmalloc and other prior art.

  Excellent.
  
> I have written it with the goals:
> 
> 1. Easy to read and maintain.

  A good goal.
  
> 2. Be more memory conserving.

  As compared with dlmalloc()?
  
> 3. High efficiency and good performance.

  As compared with dlmalloc()?
  
> 4. Portability.

  Have you written to conform to a standard such as POSIX, then?  That
  can ensure maximum portability.

> I have a (I believe) working version with some tests and documentation
> and am hoping for some feedback on design and implementation as well
> as any other constructive feedback.
> 
> Link to source:
> https://github.com/akalsi87/akmalloc
> 
> Link to documentation:
> https://rawgit.com/akalsi87/akmalloc/1.0.1/_layouts/index.html
> 
> The library is modeled close to dlmalloc because of its
> customizability but in doing so I have tried to not obfuscate too much
> with macros.

  A commendable effort.  How about a README in the git repository so
  that it shows up on GitHub?  Something brief would do fine.
  
> Aaditya

-- 
Udyant Wig

[toc] | [prev] | [next] | [standalone]

#90484

On Sunday, July 17, 2016 at 1:36:51 PM UTC-4, Udyant Wig wrote:
> [There was an incident with a GPG key.  The original article follows.
> Again.]
> 
> On 07/17/2016 06:15 AM, Aaditya Kalsi wrote:
> > Hello,
> > 
> > I have written a new implementation of malloc() and free() and sibling
> > APIs after studying dlmalloc and other prior art.
> 
>   Excellent.
>   
> > I have written it with the goals:
> > 
> > 1. Easy to read and maintain.
> 
>   A good goal.
>   
> > 2. Be more memory conserving.
> 
>   As compared with dlmalloc()?

Yes. I have been comparing against dlmalloc.
   
> > 3. High efficiency and good performance.
> 
>   As compared with dlmalloc()?

Yes, again, as compared to dlmalloc, and other implementations of malloc()/free().

I do not intend to compete with tcmalloc/jemalloc and other variants simply because those are optimized for multi-threaded speed at the cost of memory use.
  
> > 4. Portability.
> 
>   Have you written to conform to a standard such as POSIX, then?  That
>   can ensure maximum portability.

I believe this conforms to POSIX.

> > I have a (I believe) working version with some tests and documentation
> > and am hoping for some feedback on design and implementation as well
> > as any other constructive feedback.
> > 
> > Link to source:
> > https://github.com/akalsi87/akmalloc
> > 
> > Link to documentation:
> > https://rawgit.com/akalsi87/akmalloc/1.0.1/_layouts/index.html
> > 
> > The library is modeled close to dlmalloc because of its
> > customizability but in doing so I have tried to not obfuscate too much
> > with macros.
> 
>   A commendable effort.  How about a README in the git repository so
>   that it shows up on GitHub?  Something brief would do fine.
>   
> > Aaditya

Thank you. I will work on adding this soon.

> -- 
> Udyant Wig

[toc] | [prev] | [next] | [standalone]

#90465

On Sunday, July 17, 2016 at 1:45:41 AM UTC+1, Aaditya Kalsi wrote:
> Hello,
> 
> I have written a new implementation of malloc() and free() and 
> sibling APIs after studying dlmalloc and other prior art.
> 
> I have written it with the goals:
> 
> 1. Easy to read and maintain.
> 2. Be more memory conserving.
> 3. High efficiency and good performance.
> 4. Portability.
> 
> I have a (I believe) working version with some tests and documentation 
> and am hoping for some feedback on design and implementation as well 
> as any other constructive feedback.
> 
> Link to source:
> https://github.com/akalsi87/akmalloc
> 
> Link to documentation:
> https://rawgit.com/akalsi87/akmalloc/1.0.1/_layouts/index.html
> 
> The library is modeled close to dlmalloc because of its customizability
> but in doing so I have tried to not obfuscate too much with macros.
> 
The code will be far more useful if you can package it as one source 
file and one associated header, the exports only the symbols ak_malloc(),
ak_realloc(), ak_free(), maybe ak_malloc_usable_size().

The there's far too much Chinese box programming. ak_malloc should
itself do most of the work. And you don't need to typedef anything
except a few basic structures.

[toc] | [prev] | [next] | [standalone]

#90466

On 17/07/2016 08:30, Malcolm McLean wrote:
> On Sunday, July 17, 2016 at 1:45:41 AM UTC+1, Aaditya Kalsi wrote:

>> I have written a new implementation of malloc() and free() and

>> I have written it with the goals:
>>
>> 1. Easy to read and maintain.
>> 2. Be more memory conserving.
>> 3. High efficiency and good performance.
>> 4. Portability.
>>
>> I have a (I believe) working version with some tests and documentation
>> and am hoping for some feedback on design and implementation as well
>> as any other constructive feedback.
>>
>> Link to source:
>> https://github.com/akalsi87/akmalloc
>>
>> Link to documentation:
>> https://rawgit.com/akalsi87/akmalloc/1.0.1/_layouts/index.html
>>
>> The library is modeled close to dlmalloc because of its customizability
>> but in doing so I have tried to not obfuscate too much with macros.
>>
> The code will be far more useful if you can package it as one source
> file and one associated header,

I agree. It took me a couple of minutes' browsing every directory to 
find the C source files. But there are also many, many more .js files, 
.html, .png, .cpp, cmake, .yml, even a .py file. What is someone 
supposed to do with all those? There also appears to be a dependency on 
Cmake, whatever that is.

So it seems to fail on point one:

 >> 1. Easy to read and maintain.

As you say, a simple library might comprise:

   akmalloc.h
   akmalloc.c

plus a couple of documentation files.

Looking at more files, there appear to be some bash scripts, which 
doesn't bode well. What is someone to do with /those/, if they are 
running Windows for example?

What does the build process do, what does it produce? Is it a .lib, .so, 
.dll, or .obj? The only .c test program I could find seemed to be for Unix.

I wonder if most of this stuff is auto-generated by the OP's development 
system?

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#90470

On Sunday, July 17, 2016 at 5:54:36 AM UTC-4, Bart wrote:

> I agree. It took me a couple of minutes' browsing every directory to 
> find the C source files. But there are also many, many more .js files, 
> .html, .png, .cpp, cmake, .yml, even a .py file. What is someone 
> supposed to do with all those? There also appears to be a dependency on 
> Cmake, whatever that is.
> 
> So it seems to fail on point one:
> 
>  >> 1. Easy to read and maintain.

All the extraneous files mentioned are for documentation and CMake (which is a meta build system, https://www.cmake.org/).

> As you say, a simple library might comprise:
> 
>    akmalloc.h
>    akmalloc.c
> 
> plus a couple of documentation files.
>

Agreed. I'm trying to get such a version and see how it looks and how it will work.

> Looking at more files, there appear to be some bash scripts, which 
> doesn't bode well. What is someone to do with /those/, if they are 
> running Windows for example?

Those are internal development tools.

> What does the build process do, what does it produce? Is it a .lib, .so, 
> .dll, or .obj? The only .c test program I could find seemed to be for Unix.

It produces a .lib + .dll on Windows and a .so on Linux if AKMALLOC_LIBRARY=1 when building.

It produces a .a when AKMALLOC_LINK_STATIC=1.

It currently produces configured headers if AKAMLLOC_INCLUDE_ONLY=1 when building.

The build script is in bash but a CMake user simply needs CMake and the source.

> I wonder if most of this stuff is auto-generated by the OP's development 
> system?

The documentation files (js, css, html, etc.) are produced by running doxygen on the source.

> -- 
> Bartc

[toc] | [prev] | [next] | [standalone]

#90469

On Sunday, July 17, 2016 at 3:30:25 AM UTC-4, Malcolm McLean wrote:
> The code will be far more useful if you can package it as one source 
> file and one associated header, the exports only the symbols ak_malloc(),
> ak_realloc(), ak_free(), maybe ak_malloc_usable_size().

I see. I am trying to cobble a version together which only has a header and source file.

I can gather the documentation from the doc/ folder and put that in line with the source code.

> The there's far too much Chinese box programming. ak_malloc should
> itself do most of the work.

I didn't quite understand the term.

> And you don't need to typedef anything
> except a few basic structures.

Agreed. I can lose a few unnecessary typedefs.

[toc] | [prev] | [next] | [standalone]

#90479

On Sunday, July 17, 2016 at 12:31:43 PM UTC+1, Aaditya Kalsi wrote:
> On Sunday, July 17, 2016 at 3:30:25 AM UTC-4, Malcolm McLean wrote:
>
> > The there's far too much Chinese box programming. ak_malloc should
> > itself do most of the work.
> 
> I didn't quite understand the term.
> 
A Chinese Box (or Russian doll) is a series of boxes nested inside
each other. The recipient opens the box, expecting a present, and
inside there's just another box. Then another. Eventually the last box
may contain a tiny gift, or sometimes it contain nothing.

The same thing in programming is where you wrap something more than
once. It's often useful to have a layer of abstraction between
a raw void * and your return from mymalloc(), or an int and your
memory size argument. But another layer of abstraction between
the abstraction and the user's source is less useful. Abstraction
of abstraction is Chinese Box programming.

[toc] | [prev] | [next] | [standalone]

#90485

On Sunday, July 17, 2016 at 2:40:47 PM UTC-4, Malcolm McLean wrote:
> On Sunday, July 17, 2016 at 12:31:43 PM UTC+1, Aaditya Kalsi wrote:
> > On Sunday, July 17, 2016 at 3:30:25 AM UTC-4, Malcolm McLean wrote:
> >
> > > The there's far too much Chinese box programming. ak_malloc should
> > > itself do most of the work.
> > 
> > I didn't quite understand the term.
> > 
> A Chinese Box (or Russian doll) is a series of boxes nested inside
> each other. The recipient opens the box, expecting a present, and
> inside there's just another box. Then another. Eventually the last box
> may contain a tiny gift, or sometimes it contain nothing.
> 
> The same thing in programming is where you wrap something more than
> once. It's often useful to have a layer of abstraction between
> a raw void * and your return from mymalloc(), or an int and your
> memory size argument. But another layer of abstraction between
> the abstraction and the user's source is less useful. Abstraction
> of abstraction is Chinese Box programming.

I now understand the reference and why it was appropriate. 

[toc] | [prev] | [next] | [standalone]

#90475

I have a simplified version of the library based on the feedback here:

https://github.com/akalsi87/akmalloc/tree/single-file

It has a single .c and a single .h file. The .h file includes the .c file if AKMALLOC_INCLUDE_ONLY is defined.

I hope this makes it easier to peruse through the code.

Aaditya

[toc] | [prev] | [next] | [standalone]

#90481

On 17/07/2016 15:02, Aaditya Kalsi wrote:
> I have a simplified version of the library based on the feedback here:
>
> https://github.com/akalsi87/akmalloc/tree/single-file
>
> It has a single .c and a single .h file. The .h file includes the .c file if AKMALLOC_INCLUDE_ONLY is defined.

That's a lot better. It seems to work, and some tests results I got are 
below.

As I used it:

* I compiled akmalloc.c (I had to define AKMALLOC_LINK_STATIC, and 
change the include path for "akmalloc.h" as my set-up was different)

* I compiled my test application as normal

* The akmalloc object file was statically linked into applicaton

Somehow, simply linking in akmalloc takes over the normal malloc() and 
free() calls (the only ones I tested). So no changes are needed in 
applications.

I tested using the 'binary tree' benchmark. The version I used is here: 
http://pastebin.com/9FA3J76b (I lost my native C version; this is 
auto-generated C.)

Tests were done on Windows with several C compilers and compared with 
normal malloc/free library versions:

                32-      64-bit

Pelles C       1.0      0.8    seconds; default malloc/free
lccwin         1.7      1.2
Digital Mars   0.9      ---
gcc/TDM        1.9      1.1
Clang          ---      1.1
Tiny C         2.2      1.4

gcc/TDM        1.3      1.3    With AK malloc/free
Clang          ---      1.4    With AK

Note this benchmark allocates and frees large numbers of the same size 
block (12 bytes or 20/24 bytes). Also, on Windows, I believe the 
OS-provided C runtime library (MSVCRT) is used by gcc, which is not fast.

(I haven't looked at the details of the source code.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#90486

On Sunday, July 17, 2016 at 3:38:20 PM UTC-4, Bart wrote:
> On 17/07/2016 15:02, Aaditya Kalsi wrote:
> > I have a simplified version of the library based on the feedback here:
> >
> > https://github.com/akalsi87/akmalloc/tree/single-file
> >
> > It has a single .c and a single .h file. The .h file includes the .c file if AKMALLOC_INCLUDE_ONLY is defined.
> 
> That's a lot better. It seems to work, and some tests results I got are 
> below.
> 
> As I used it:
> 
> * I compiled akmalloc.c (I had to define AKMALLOC_LINK_STATIC, and 
> change the include path for "akmalloc.h" as my set-up was different)
> 
> * I compiled my test application as normal
> 
> * The akmalloc object file was statically linked into applicaton
> 
> Somehow, simply linking in akmalloc takes over the normal malloc() and 
> free() calls (the only ones I tested). So no changes are needed in 
> applications.
> 
> I tested using the 'binary tree' benchmark. The version I used is here: 
> http://pastebin.com/9FA3J76b (I lost my native C version; this is 
> auto-generated C.)
> 
> Tests were done on Windows with several C compilers and compared with 
> normal malloc/free library versions:
> 
>                 32-      64-bit
> 
> Pelles C       1.0      0.8    seconds; default malloc/free
> lccwin         1.7      1.2
> Digital Mars   0.9      ---
> gcc/TDM        1.9      1.1
> Clang          ---      1.1
> Tiny C         2.2      1.4
> 
> gcc/TDM        1.3      1.3    With AK malloc/free
> Clang          ---      1.4    With AK
> 
> Note this benchmark allocates and frees large numbers of the same size 
> block (12 bytes or 20/24 bytes). Also, on Windows, I believe the 
> OS-provided C runtime library (MSVCRT) is used by gcc, which is not fast.
> 
> (I haven't looked at the details of the source code.)
> 
> -- 
> Bartc

Thank you for the excellent comparison and the source of the test.

I compiled it and compared it on my MacOS machine and it turns out to be 2x faster with AKMALLOC_USE_LOCKS and almost 3.5-4x faster with no locks (no locks is slightly unfair because default malloc/free cannot do that).

I was wondering if you also defined NDEBUG, otherwise you may be seeing longer times with as asserts are enabled, and inline functions get turned into non inline on a debug build.

Would you mind if I added the treebin code as a reference performance test in the suite I maintain?

[toc] | [prev] | [next] | [standalone]

#90488

On 17/07/2016 21:44, Aaditya Kalsi wrote:
> On Sunday, July 17, 2016 at 3:38:20 PM UTC-4, Bart wrote:

>> I tested using the 'binary tree' benchmark. The version I used is here:
>> http://pastebin.com/9FA3J76b (I lost my native C version; this is
>> auto-generated C.)

> Would you mind if I added the treebin code as a reference performance test in the suite I maintain?

You can do but there are better versions in 'proper' C. Here's a couple:

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=gcc&id=5

http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=gcc&id=1

(These take input N from the command line.)

-- 
Bartc

[toc] | [prev] | [next] | [standalone]

#90491

On Sunday, July 17, 2016 at 5:20:01 PM UTC-4, Bart wrote:
> On 17/07/2016 21:44, Aaditya Kalsi wrote:
> > On Sunday, July 17, 2016 at 3:38:20 PM UTC-4, Bart wrote:
> 
> >> I tested using the 'binary tree' benchmark. The version I used is here:
> >> http://pastebin.com/9FA3J76b (I lost my native C version; this is
> >> auto-generated C.)
> 
> > Would you mind if I added the treebin code as a reference performance test in the suite I maintain?
> 
> You can do but there are better versions in 'proper' C. Here's a couple:
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=gcc&id=5
> 
> http://benchmarksgame.alioth.debian.org/u64q/program.php?test=binarytrees&lang=gcc&id=1
> 
> (These take input N from the command line.)

Thank you.

> -- 
> Bartc

[toc] | [prev] | [next] | [standalone]

#90517

Aaditya Kalsi <aadityakalsi@gmail.com> writes:

> I have a simplified version of the library based on the feedback here:
>
> https://github.com/akalsi87/akmalloc/tree/single-file
>
> It has a single .c and a single .h file.  The .h file includes the .c
> file if AKMALLOC_INCLUDE_ONLY is defined.
>
> I hope this makes it easier to peruse through the code.

I have some other comments to make, but let me start off
with just a few.

I had no problem with the repository having lots of
other files.  I found the .[hc] files with no problem
(isn't that what 'find' is for anyway?).

It's okay to give a url that can be used with 'git clone'.  The
original url upthread presented no problem, but the "single file"
url above fails that test.  Giving a url intended for use in a
browser /in addition to/ a url that can be used with wget or
git clone is fine, but not by itself.

When asking for a review, it's important to give a reference
(eg, url) to something that is fixed, and will not change
over time.  Please figure out how to freeze a particular
version and give a url to that.  Giving a url to the
time-varying version /in addition/ is fine, but there should
be a frozen version given as the primary one.  (And it's
always possible to give a url for a later frozen version in
a followup posting.)  It's very annoying in discussions like
this to be forced to try to hit a moving target.

I was disappointed to discover that your project needs a
newer version of cmake than I had installed, especially
since I did an 'apt-get install cmake' less than two weeks
ago!  Any chance you can change the level of 'cmake' required
to be a bit lower?  (I don't remember what version of cmake
was reported when I tried building your project.)

I expect to have more to say, about the code and about
the single/multi file choice, after you have a chance
to respond to the above.

[toc] | [prev] | [next] | [standalone]

#90528

On Monday, July 18, 2016 at 12:40:41 PM UTC-4, Tim Rentsch wrote:
> Aaditya Kalsi <aadityakalsi@gmail.com> writes:
> 
> > I have a simplified version of the library based on the feedback here:
> >
> > https://github.com/akalsi87/akmalloc/tree/single-file
> >
> > It has a single .c and a single .h file.  The .h file includes the .c
> > file if AKMALLOC_INCLUDE_ONLY is defined.
> >
> > I hope this makes it easier to peruse through the code.
> 
> I have some other comments to make, but let me start off
> with just a few.
> 
> I had no problem with the repository having lots of
> other files.  I found the .[hc] files with no problem
> (isn't that what 'find' is for anyway?).

Agreed. I believe it to be very useful for debugging, testing and modularity.

As for distribution, I feel there are valid concerns in both camps, so I decided to add and maintain a single-file branch also.

> It's okay to give a url that can be used with 'git clone'.  The
> original url upthread presented no problem, but the "single file"
> url above fails that test.  Giving a url intended for use in a
> browser /in addition to/ a url that can be used with wget or
> git clone is fine, but not by itself.
> 
> When asking for a review, it's important to give a reference
> (eg, url) to something that is fixed, and will not change
> over time.  Please figure out how to freeze a particular
> version and give a url to that.  Giving a url to the
> time-varying version /in addition/ is fine, but there should
> be a frozen version given as the primary one.  (And it's
> always possible to give a url for a later frozen version in
> a followup posting.)  It's very annoying in discussions like
> this to be forced to try to hit a moving target.

I apologize for that. The single-file link was meant to be a /browser only/ link.

Let me re-specify the links:

   % git clone https://github.com/akalsi87/akmalloc
   % git checkout [1.0.1 | single-file | develop]

The develop branch is the "bleeding-edge" branch.

The single-file branch is the default distribution branch (fixed).

The 1.0.1 branch is the developer branch for the first release (fixed).

> I was disappointed to discover that your project needs a
> newer version of cmake than I had installed, especially
> since I did an 'apt-get install cmake' less than two weeks
> ago!  Any chance you can change the level of 'cmake' required
> to be a bit lower?  (I don't remember what version of cmake
> was reported when I tried building your project.)

That's unfortunate! I looked through the CMake files and I don't believe I can reduce the required version. I do not remember what feature I used for my CMake project helper file that bumped it up to v3 but I have relied on it since a while.

However, I don't believe you need CMake unless you plan to build a shared library. I use CMake to run tests and build tests against all configurations.

Unless you plan to use the tests in the repository, you could do without it. I could also suggest simply commenting out those lines to see if it works without that minimum version. I believe it might. I don't have an older CMake at hand at the moment so I cannot test this. Sorry!

> I expect to have more to say, about the code and about
> the single/multi file choice, after you have a chance
> to respond to the above.

[toc] | [prev] | [next] | [standalone]

#90662

Aaditya Kalsi <aadityakalsi@gmail.com> writes:

> On Monday, July 18, 2016 at 12:40:41 PM UTC-4, Tim Rentsch wrote:
>> Aaditya Kalsi <aadityakalsi@gmail.com> writes:
>>
>>> I have a simplified version of the library based on the feedback here:
>>>
>>> https://github.com/akalsi87/akmalloc/tree/single-file
>>>
>>> It has a single .c and a single .h file.  The .h file includes the .c
>>> file if AKMALLOC_INCLUDE_ONLY is defined.
>>>
>>> I hope this makes it easier to peruse through the code.
>>
>> I have some other comments to make, but let me start off
>> with just a few.

And once more...  (some quoted parts omitted)

> As for distribution, I feel there are valid concerns in both camps,
> so I decided to add and maintain a single-file branch also.

See below for further comments.

>> It's okay to give a url that can be used with 'git clone'.  The
>> original url upthread presented no problem, but the "single file"
>> url above fails that test.  Giving a url intended for use in a
>> browser /in addition to/ a url that can be used with wget or
>> git clone is fine, but not by itself.
>>
>> When asking for a review, it's important to give a reference
>> (eg, url) to something that is fixed, and will not change
>> over time.  Please figure out how to freeze a particular
>> version and give a url to that.  Giving a url to the
>> time-varying version /in addition/ is fine, but there should
>> be a frozen version given as the primary one.  (And it's
>> always possible to give a url for a later frozen version in
>> a followup posting.)  It's very annoying in discussions like
>> this to be forced to try to hit a moving target.
>
> I apologize for that.  The single-file link was meant to be a /browser
> only/ link.

Yeah.  IMO no sane person reviews code in a web browser.  xMMV.

> Let me re-specify the links:
>
>    % git clone https://github.com/akalsi87/akmalloc
>    % git checkout [1.0.1 | single-file | develop]
>
> The develop branch is the "bleeding-edge" branch.
>
> The single-file branch is the default distribution branch (fixed).
>
> The 1.0.1 branch is the developer branch for the first release (fixed).

Having separate branches for distribution and development
seems right.  The single file stuff should be added to
any other branches (assuming you want there to be two
versions, about which more below).

>> I was disappointed to discover that your project needs a
>> newer version of cmake than I had installed, especially
>> since I did an 'apt-get install cmake' less than two weeks
>> ago!  Any chance you can change the level of 'cmake' required
>> to be a bit lower?  (I don't remember what version of cmake
>> was reported when I tried building your project.)
>
> That's unfortunate!  I looked through the CMake files and I don't
> believe I can reduce the required version.  I do not remember what
> feature I used for my CMake project helper file that bumped it up to
> v3 but I have relied on it since a while.
>
> However, I don't believe you need CMake unless you plan to build a
> shared library.  I use CMake to run tests and build tests against all
> configurations.

If possible I routinely do a full build using what comes with
the download, for a variety of reasons.  Actually I was able
to compile the code before, but I worry that I may have missed
some important configuration setting.

The good news is I downloaded a later version of cmake and built
it from source.  Problem solved.

>> I expect to have more to say, about the code and about
>> the single/multi file choice, after you have a chance
>> to respond to the above.

I still expect to have more substantial comments on the code,
but first I need to do another round of reporting build
problems.

I followed your directions and checked out the distribution
branch.  No problem running cmake.  But then the make failed.
Here is the first error message (please excuse my wrapping the
long lines):

    [ 21%] Building CXX object test/CMakeFiles/tMallocPerfRef.dir/tMallocPerf.cpp.o
    In file included from /usr/include/c++/4.8/thread:35:0,
                     from /opt/software/git/akmalloc/test/tMallocPerf.cpp:307:
    /usr/include/c++/4.8/bits/c++0x_warning.h:32:2: error:  #error This file 
      requires compiler and library support for the ISO\
    C++ 2011 standard. This support is currently experimental, and must be
      enabled with the -std=c++11 or -std=gnu++11 compi\
    ler options.
     #error This file requires compiler and library support for the \
      ^

I also tried checking out single-file.  After that running cmake
failed:

    CMake Error: The source directory "/opt/software/git/akmalloc" does not appear to contain CMakeLists.txt.
    Specify --help for usage, or press the help button on the CMake GUI.

Last (for now) but not least, a high-level comment on organization
and structure.  It seems like you are going to a lot of effort to
allow the akmalloc code to be #include'd rather than separately
compiled.  Having that flexibility is not worth the cost in
terms of code organization and readability.  Embrace the single
file model, and dump the multi-file #include model.  It isn't
just that the multi-file model raises technical difficulties
(which it does);  it also elicits a bad reaction in the culture
of C developers.  It will be much easier to get your stuff
accepted if it doesn't buck development community cultural norms
so strongly.

To say that another way, there needs to be some VERY compelling
reasons to adopt the multi-file #include model for what you're
doing.  Unless there are such reasons, /and/ you can present
them in a way that persuade other people that they are sufficiently
compelling, then you should drop the multi-file #include approach
and go exclusively with the single-file model.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.c

csiph-web